antonok

I've been using Llama models to identify cookie notices on websites, for the purpose of adding filter rules to block them in EasyList Cookie. Otherwise, this is normally done by, essentially, manual volunteer reporting.

Most cookie notices turn out to be pretty similar, HTML/CSS-wise, and then you can grab their `innerText` and filter out false positives with a small LLM. I've found the 3B models have decent performance on this task, given enough prompt engineering. They do fall apart slightly around edge cases like less common languages or combined cookie notice + age restriction banners. 7B has a negligible false-positive rate without much extra cost. Either way these things are really fast and it's amazing to see reports streaming in during a crawl with no human effort required.

Code is at https://github.com/brave/cookiemonster. You can see the prompt at https://github.com/brave/cookiemonster/blob/main/src/text-cl....

It wouldn't get passed on. Without land value tax, holding real estate is a good enough investment on its own that rent prices can be left artificially inflated. LVT puts pressure on landlords to actually earn back the value of the property to avoid losing money. In practice, that means offering competitive pricing.

This is a solid in-depth explanation, if you're interested: https://www.gameofrent.com/content/can-lvt-be-passed-on-to-t...

Can you be more specific? There are admittedly lots of settings menus, but to my knowledge there are no ads inside the settings menus.

Brave's built-in adblocker will not be affected, since it doesn't rely on any extension APIs.

We'll also be continuing support for Mv2, in case you prefer to use uBO or other pre-Mv3 adblock extensions.

Why not, I'll make a pitch for Brave here too. We have the only EasyList-compatible adblocker that isn't based on an extension platform.

Yes, there is in-browser private advertising with user revenue share, but all of it can be disabled too if you prefer.

Nothing coordinated so far, but keep in mind Mv2 code will still exist behind a policy flag in Chromium until at least June 2025; there's still quite some time.

I work on adblocking at Brave.

1. Brave, Vivaldi, and Opera have all announced they'd maintain support for Mv2 past Google's deprecation date [1].

2. Your guess is correct - one of Google's stated motivations is to make the extension review process easier and less error-prone; having a way to opt-out would be counterproductive in that regard. I strongly doubt they'd accept the PR upstream; there is a chance other players could maintain patches to modify Mv3 but the effort of designing and implementing a new spec around the Mv3 spec and convincing extensions to maintain yet another platform means this is unlikely to happen in practice. Keeping Mv2 around is a more reasonable approach (and one that is compatible with Firefox, as well).

[1] https://www.zdnet.com/article/opera-brave-vivaldi-to-ignore-...

Brave's adblocker is written in Rust [0] and compiled to native code; it's not affected by the Mv3 transition because it doesn't use extension APIs. Brave also publicly committed [1] to continuing support for Mv2 through patches.

[0] https://github.com/brave/adblock-rust [1] https://twitter.com/brave/status/1574822799700541446

Beeper [1] is built on Matrix, and their bridges to all the other messaging platforms are open source too if you wanted to self-host.

[1] https://www.beeper.com/

FWIW, in Brave you can create cosmetic filters using the right-click context menu. `Brave > Block element`. There's a shortcut to the page where you can manage your custom filters in that menu, too.

What exactly do you mean by "modify Mv3"? Brave committed to continuing support for Mv2 [1]. Adding native adblocking capabilities is also definitely a more complex change than just bundling an adblocking extension.

Brave maintains patches in a very specific way [2] to ensure maintainability. My impression is that Kiwi's patches are structured in a way that technically works but isn't easy to keep rebasing on top of upstream changes. Kiwi's been chronically outdated compared to upstream Chromium whereas Brave generally gets updated within a day of a corresponding Chromium release.

[1] https://twitter.com/brave/status/1574822799700541446 [2] https://github.com/brave/brave-browser/wiki/Patching-Chromiu...

congrats! Helicone provides one of the biggest missing pieces from the the AI tool dev experience today, thanks for building this and sharing it with the rest of us!

Brave Search has its own independent index too - https://brave.com/brave-search-beta/

Brave's been blocking third-party cookies from the beginning; Firefox and Safari followed in 2019 and 2020 respectively. Third party cookies might not have been on the way out if Brave hadn't taken that first step already.

Brave Browser has some Rust components too (e.g. the adblocking engine). Rust in C++ works very well for components with a small, well-defined API surface that involve a lot of logic. You only need to build a small FFI layer for the direct interfaces between the two languages. CXX [1] makes this even easier, too.

Brave is definitely not aiming to convert the entire browser to Rust, but it's increasingly chosen for new development.

[1] https://cxx.rs/

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 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...

Brendan Eich has committed to supporting the Manifest V2 version of uBlock Origin in Brave [1].

Brave's built-in native adblocker also definitely won't be affected, as it doesn't use any webextension APIs at all.

[1]: https://github.com/uBlockOrigin/uAssets/discussions/14544#di...

Great suggestions. The "third party buys popular extension and quietly adds malware" approach is also a huge attack vector. There really ought to be some way to prevent an extension from updating until you've had a chance to review and approve that change, especially if it requests a lot of sensitive permissions.

Google actually is allowing MV2 extensions to work under enterprise policy for much longer than anyone else: https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/

> V3 has gotten better at blocking ads over time, not worse.

That may be true, but it's still significantly limited compared to MV2. And at the current rate, that is unlikely to change by the time Manifest V2 support is removed.

What's important is that MV3 adblocker developers no longer have full control over how they're allowed to modify pages. Given how adversarial the relationship between adblockers and websites is, that lack of control will be exploited almost immediately.

That's exactly what Brave is doing. Chromium fork with a built-in native adblocker that doesn't depend on MV2 at all, and plans to continue supporting MV2 even when it is removed from Chromium entirely.

If you own hundreds of domains, you're welcome to try, but there's no good reason to. Fingerprinting scripts rely on a canvas being identical between sessions to identify that the same user is even there in the first place. If you can already single out one user's activity across a hundred domains, you don't need to fingerprint them any further.

This totally works as an approach! Brave does it for canvas data and a bunch of other web APIs as well. The "farbling" noise is deterministic per profile/origin combo to prevent being able to average it out across multiple page loads, but otherwise random.

https://brave.com/privacy-updates/4-fingerprinting-defenses-...

Here's a few:

- performance gains from optimized machine code

- CNAME adblocking, which is otherwise not possible on Chromium-based browsers

- robustness against potential changes from upstream (i.e. Manifest v3)

And, not exactly adblocking, but other privacy protections that are only possible with a deep level of control over browser APIs:

- advanced fingerprinting protections, including subtle randomized perturbations of canvas reads, fonts, user agent, etc.

- ephemeral storage sandboxing for third-party content

You're right, I just realized my VPS doesn't provide a public IPv6 address :(

I've removed that record at least; thanks for the heads up!

I recommend checking out this issue [1] if you want to get your feet wet. Attempting to build a new Rust program and documenting what prevented it from working is a great way to understand how everything is implemented. Pretty satisfying if you can get a program working, too.

[1] https://github.com/sunfishcode/mustang/issues/22

> It is the user's agent, and as the user, I want the control. I want to make the decisions.

What kind of decisions do you want to be able to make? Unless you're writing all your own filters (in which case, kudos to you!), you're still ultimately delegating these decisions primarily to a handful of filter list maintainers you've probably never met. Brave's source code and filter lists are all developed in the open and are heavily customizable, as well.

Brave on iOS does inject JS into YouTube and other sites. It uses exactly the same `+js(...)` injections as Brave on desktop and Android, as well as uBlock Origin, which is really helpful.

Unfortunately, JS can't solve everything... the WKWebView restrictions are definitely a huge frustration. Brave for Android and desktop both build from a single codebase, but everything has to be reimplemented to work on iOS too.

> Brave is Chromium-based and suffers from all of the limitations stated in the parent article.

Only for extensions. Brave Shields is implemented in natively compiled Rust and C++ (which is even more efficient than WebAssembly), is able to load rules before making any network requests, uses a compressed filter list data representation, and prefetching is disabled entirely in Brave. The only thing currently missing from that list is HTML filtering, which is fairly rare in practice and generally has fallback rules in popular lists anyways.