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

And it's still only half as effective as uBO on Firefox. The amount of pop-ups that manage to get through is absurd and it's one of the main reasons why Firefox remains my daily driver.

While uBlock inside Brave suffers from the same limitations as uBlock within Chrome, the more interesting question is if Brave's native blocking makes that irrelevant or not.

Brave does have a few intriguing privacy features, like plugging WebRTC IP leaks while still allowing use of WebRTC (Firefox is off or on while Safari's always on AFAIK), so that's not excluded.

The main problem with Brave is that they're building on a browser which is designed to leak privacy like a sieve. It seems that they're being careful and monitoring all the anti-features Google's adding, but who knows.

It doesn't make it irrelevant. For example, sponsored Tweets on the Twitter web app aren't blocked in Brave (at least the last time I checked).

Brave even openly admits this in that blog post announcing their support for native CNAME uncloaking-

> In version 1.25.0, uBlock Origin gained the ability to detect and block CNAME-cloaked requests using Mozilla’s terrific browser.dns API. However, this solution only works in Firefox, as Chromium does not provide the browser.dns API. To some extent, these requests can be blocked using custom DNS servers. However, no browsers have shipped with CNAME-based adblocking protection capabilities available and on by default.