[davikr]

It's nice using Brave because you have Chromium's better performance, without having to worry about Manifest V2 dying and taking adblocking down with it. I have uBlock Origin enabled, but it has barely caught anything that slipped past the browser filters.

[croes]

Brave"s support of Manifest V3 is totally dependent on Google and Chrome

>Brave will support uBO and uMatrix so long as Google doesn’t remove underlying V2 code paths (which seem to be needed for Chrome for enterprise support, so should stay in the Chromium open source)

https://twitter.com/BrendanEich/status/1534893414579249152

[steve_rambo]

It doesn't really matter much in practice. The built-in adblocker (which does not rely on extension APIs) has excellent performance, about as effective as ublock origin, and supports the same filter lists.

[croes]

It does matter if you use other extensions that require Manifest V2

[guipsp]

The built-in adblocker still relies on a large amount of extension APIs.

[davikr]

Yeah, but the Brave adblocker is built-in, it's not an extension.

[croes]

There are more extensions than just ad blockers

[Diti]

If by performance you mean browser performance, you have more performance with Firefox nowadays. https://news.ycombinator.com/item?id=36770883

[soundnote]

One genuine performance edge Firefox has is that it can handle giant YouTube comments sections better than Chromium browsers in part because it accepts larger maximum page size.

[FoodWThrow]

I use firefox because it has the most hassle-free hardware decoding in linux. However, everything basically feels better with Brave, even with the same amount of plug-ins.

[kristianp]

I found the snap update notifications too annoying on Ubuntu, so I tried the ppa. But it the video plugin would crash. So back to Chrome for me.

[1xdevnet]

Curious whether you've tried with the new (non-PPA) repo directly from Mozilla as of v122 [1]. I think the old PPA was also Mozilla, so I don't know what may have changed aside from being more publicly acknowledged. Might be worth a try?

I don't have an Ubuntu VM at-hand but on Debian bookworm it installed fine, and (after tweaking one line in profiles.ini to point to my old ESR profile) it loaded and played Widevine-protected videos without any issues.

[1]: https://support.mozilla.org/en-US/kb/install-firefox-linux#w...

[kristianp]

Thanks, I'll give that a try.

[jacooper]

While still not being as secure as chromium and still not supporting many advanced features like WebGpu.

[danShumway]

This has come up a few times, but as far as I know Gorhill is planning to full-on drop support for Chromium browsers outside of uBO Lite. Does Brave keeping Manifest V2 matter if developers stop maintaining the Chromium version of those extensions?

I also still can't really find if Brave has an extension store or if it's connecting to Chrome's. If it's the latter, then it seems like V2 extensions are going away for Brave regardless of what API decisions it makes, because short of sideloading them the addons won't be on the Chrome web store anymore and won't be getting updates. I assume Brave supports sideloading extensions, and maybe developers would maintain extensions for Chromium that can't actually be used in Chrome? Although that seems a little optimistic. But not having a way to search for V2 extensions or get ratings/reviews seems like it will still be a problem for users.

[Departed7405]

Brave indeed use the Chrome Web Store.

[srid]

> I have uBlock Origin enabled, but it has barely caught anything that slipped past the browser filters.

I have been completely satisfied with Brave's builtin ad-blocker. Does uBlock Origin catch anything in particular that the builtin one does not?

[rozab]

I couldn't see Brave being able to counter, say, the recent YouTube anti-adblock push as quickly as the open source community did. I could see that kind of stunt becoming more common as Google tries to nail the coffin shut and deny their competitors this USP

[SparkyMcUnicorn]

Brave's ad blocking is compatible (and uses) the uBlock Origin lists, so you shouldn't really notice a difference between having uBO enabled or disabled in brave.

[charcircuit]

MV3 doesn't prevent adblockers from existing.

[rpastuszak]

It makes them almost useless in practice.

[HeatrayEnjoyer]

Because the filter list is capped, right? Is there a reason the Brave team cannot just remove or increase the cap?

[gkbrk]

Not just because of the filter list cap. It also reduces ad blockers to static filter lists instead of powerful dynamic filters.

MV3 makes it impossible for ad-blockers to inspect requests with code and then allow/deny dynamically.

[charcircuit]

>It also reduces ad blockers to static filter lists instead of powerful dynamic filters.

This is very outdated information and borderline misinformation by representing it as how it currently works. It allows for 30,000 dynamic rules and 5,000 session rules (session rules only persist until the browser is closed).

>MV3 makes it impossible for ad-blockers to inspect requests with code and then allow/deny dynamically.

Giving this ability to extensions can slow down the browser for the user. These ads can still be blocked through other means.

[danShumway]

> It allows for 30,000 dynamic rules

That is not what we mean by dynamic filters. From https://developer.chrome.com/blog/improvements-to-content-fi...

> However, to support more frequent updates and user-defined rules, extensions can add rules dynamically too, without their developers having to upload a new version of the extension to the Chrome Web Store.

What Chrome is talking about is the ability to specify rules at runtime. What critics of Manifest V3 are talking about is not the ability to dynamically add rules (although that can be an issue), it is the ability to add dynamic rules -- ie rules that analyze and rewrite requests in the style of the blockingWebRequest permission.

It's a little deceptive to claim that the concerns here are outdated and to point to vague terminology that sounds like it's correcting the problem, but on actual inspection turns out to be entirely separate functionality from what the GP was talking about. It's almost like the Chrome team deliberately decided to call these "dynamic rules" so they could claim that Chrome supported them and muddy the issue, even though Chromes "dynamic rules" have nothing to do with support for a blockingWebRequest API. But I don't want to be conspiratorial.

> Giving this ability to extensions can slow down the browser for the user. These ads can still be blocked through other means.

This is the debate; most of the adblocking community disagrees with your assertion. Chrome has been saying this for ages, but saying it doesn't make it true.

uBO maintains a list of some common features that are already not possible to support in Chrome (https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...) and has written about features that are not able to be supported via Chrome's current V3 API (https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-as...). Of particular note are filtering for large media elements (I use this a lot on mobile Firefox, it's great for reducing page size), and top-level filtering of domains/fonts.

Chrome could of course add support for some of this -- Chrome could implement more filter controls for analyzing headers and request sizes, but as far as I know that support hasn't been added yet. And even if that support does eventually get added, this all glosses over the bigger issue that devs have been saying from the beginning, which is that it's ridiculous to make every innovation in adblocking dependent on Chrome explicitly adding new APIs to support each individual use-case. The model that Chrome is moving towards is one where every new kind of filtering metric that devs want to use requires asking Google for permission to use it and waiting for Chrome to implement it.

[charcircuit]

>Because the filter list is capped, right?

The limits are 300,000 static rules [1] + 30,000 dynamic rules [2] + 5,000 session rules [3]. For reference easylist is about 35k rules. The Chrome team has been constantly tweaking these limits themselves and Brave could set their own limits if they wish. The API is designed such that extensions can query to see how many rules they can use.

[1] https://source.chromium.org/chromium/chromium/src/+/main:ext...

[2] https://source.chromium.org/chromium/chromium/src/+/main:out...

[3] https://source.chromium.org/chromium/chromium/src/+/main:out...

[danShumway]

Note that "dynamic rules" as specified here are not the same as what GP was talking about. The API does not support dynamic rules in the way that Firefox/V2 users use that term.

[charcircuit]

GP did not mention dynamic rules.

[charcircuit]

That is a baseless statement. It doesn't make them useless as they can still block ads.

[deely3]

Is this submarine comment?

[thebruce87m]

What is the definition of a submarine comment? Google fails and ChatGPT says:

> A "submarine comment" on social media refers to a comment that is made on an old post or thread, long after the conversation has died down. This term derives from the idea of a submarine which remains submerged and out of sight for long periods before suddenly surfacing. In the context of social media, it's when someone delves deep into someone else's posts or timeline, finds an old post, and leaves a comment, bringing the old post back to attention. This can sometimes surprise the original poster and other participants, as the conversation was thought to have been concluded.

Which doesn’t make sense in this context

[mcbuilder]

I think GP is trying to coin a term for stealth marketing Hacker News comments, except the analogy doesn't really make sense.

[deely3]

Definition: https://paulgraham.com/submarine.html

[freediver]

Seen on HN first!

[deely3]

Definition: https://paulgraham.com/submarine.html