Hacker News Reader

I can give some context here (I work on Brave's adblock engine).

> Brave has been in the business of blocking ads for a long time. Surprisingly it took them years to come up with cookie banner blocking, even though all they do is include a list maintained for free by easylist maintainers.

Brave has been sponsoring Fanboy's work as an Easylist maintainer since early 2019 via an employment contract. This "list maintained for free" you're talking about was originally "Fanboy's Cookie List" and was promoted into Easylist as of November 2019 [1].

> This could have been implemented already 2 years ago without much effort.

Indeed, it was available through the brave://adblock settings menu 2 years ago. Building a new filter list is really difficult though - not only do you have to cover enough websites for it to be useful, but you have to make sure that important functionality doesn't break when it's applied. Multiply that by approximately every website on the internet and you'll have some idea of how difficult it is.

The list is finally comprehensive enough to be rolled out to a much wider audience - which is exactly what we're doing.

> People have asked to have the uBO-functionality ported to the built-in Brave Shields, including cosmetic filtering, and granular control.

Not sure what you are referring to here, but we do have cosmetic filtering and the ability to add custom filters or subscribe to anyone else's list with auto-updates. Procedural filtering is the main missing feature, but I'm actively working on that.

[1]: https://github.com/easylist/easylist/commit/f479000932294df0...

> you have to make sure that important functionality doesn't break when it's applied.

This feels unnecessarily conservative for a browser trying to achieve literally any market share; nobody's got only Brave installed and those who have it at all are those most likely to understand if a site is broken because of its blocking measures.

If Brave isn't going to be the one to push privacy features over compatibility, who is? I mean, you didn't name it "Caution".

We generally try to expose these kinds of things for the more technical users who are interested in finding them - again, the cookie list has been available in brave://adblock for years now, we have "aggressive" blocking mode, "strict" fingerprinting protection mode, etc. But ultimately we want to change the standards of privacy on the web for everyone, not just those who can tolerate frequent breakage (or those who will switch to a less private browser when something isn't working).

Honestly, building any browser software that relies on filter lists takes some appetite for risk. By definition, the lists are reactive and so there's always going to be a gap in compatibility in sites which have updated recently enough.

I'm not sure why you think firefox solution is better (it seems worse) nor why you think highly of firefox in this case, or at least higher than brave.

Firefox at least develops their own browser engine.

How is this relevant to the topic at hand?

They're asking why people think highly of Firefox when compared to Brave, I'm giving them an answer.

> "nor why you think highly of firefox in this case"

Emphasis added. They're asking in the context of cookie banner blocking. You didn't answer the question rat asked.

Oh, I thought they were already aware that Firefox had cookie banner blocking too. My bad.

>plans to auto-reject based on intelligent patterns

Not sure what you mean with that. Checking code[1] it apparently uses a rules list (can be found in [1]) to function on site-by-site basis. This is the same approach utilized by popular "I don't care about cookies" add-on.

[0]: https://searchfox.org/mozilla-central/source/toolkit/compone... [1]: https://github.com/mozilla/cookie-banner-rules-list

> In this case, it should be obvious that even Firefox is more innovative than Brave - Firefox plans to auto-reject based on intelligent patterns.

Was Firefox's plan publicly documented before Brave's feature was publicly announced? I heard about them in the opposite order; Brave first. It seems to me that Firefox is reacting, not innovating.

FWIW since these conversations are often tribal, I use Firefox.

I see haters in the surrounding replies and agree on tribal aspect, so to defuse that, I'll say Firefox is doing something interesting and different from what we're shipping. It is worth having browsers try different approaches, no matter who is "first" (Brave likely will be, for stable release channel distribution).

It seems Firefox’s cookie consent blocker automates clicking Reject after letting consent-management-provider(CMP)-scripts load.

https://searchfox.org/mozilla-central/source/toolkit/compone... (shared above already)

It looks like the code also injects opt-out cookies too, may sometimes do both click and cookie injection. Session cookie, so has to inject recurrently.

The Brave approach blocks the CMP scripts that pose these bono-consent dialogs in the first place. One reason we favor this approach beyond simplicity: many consent frameworks, besides being found illegal already in EU courts (going to top court soon), do dark deeds: extort from publishers, lie to and track users no matter what the user clicks. See

https://twitter.com/nataliabielova/status/157038509625910886...