Procedural filtering for better adblocking
Starting with version 1.73, Brave is significantly improving its adblocking capabilities by adding support for procedural cosmetic filtering of page elements.
Read this article →By the Brave Privacy Team
Update June 9, 2023: Brave now applies cookie banner blocking by default. This change was made to avoid user confusion, frustration, and more broadly ensure Brave provides the best protections for users by default. Cookie consent banner blocking can be disabled on desktop by unchecking “EasyList Cookie” at brave://settings/shields/filters, and on Android and iOS through in the settings panel.
This is the twenty-first post in an ongoing, regular series describing new and upcoming privacy features in Brave. This post describes work done by (in alphabetical order): Filter List Enginer Ryan Brown, Principal Engineer Brian Johnson, Android Engineering Manager Deep Pandya, Senior Product Designer Agustín Ruiz, and iOS Privacy Engineer Jacob Sikorski. This post was written by Senior Director of Privacy Peter Snyder.
Starting with the current Brave Nightly, and in version 1.45 when it releases in October, the Brave browser will block cookie consent notifications on Android and Desktop (and, soon after, on iOS). Cookie consent notifications are an infamous and near-constant annoyance on the Web. They break and disrupt one of the main benefits of the Web: the ability to browse content across many sites and publishers conveniently and easily. And, what is ironic, many cookie consent systems actually track users, introducing the exact harm the consent systems were supposed to prevent.
New versions of Brave will hide—and, where possible, completely block—cookie consent notifications. Brave’s approach is distinct and more privacy-preserving than similar systems used in other browsers (such as the “auto-consent” systems used in other browsers), and helps keep the Web user-first.
On start up, the Brave browser will ask if you’d like to block cookie banners. If you choose to enable this feature, Brave will download a set of rules designed to block and hide cookie consent notifications. The browser will start applying the rules as quickly as possible, within a minute or less of enabling the feature on most devices.
If you accidentally choose not to enable cookie banner blocking (or you enabled it but then changed your mind), you can update the setting at any time. Just visit brave://settings/shields/filters in the Brave browser and enable / disable the EasyList-Cookie List option.
Note: If you’re not prompted to block cookie dialogs, you may need to restart your browser and update to Brave version 1.45.
There are several ways browsers and extensions try to block cookie banners. Brave’s method maximizes the privacy benefit to users, while still blocking as many banners and annoyances as possible.
Broadly speaking, there are two general ways to block cookie banners.
One approach (which Brave uses) is to block cookie banners, and to hide and to modify pages to remove any additional annoyance such systems include (such as overlays, preventing scrolling, etc.). Other Web-privacy tools (such as uBlock Origin) can be configured to use this same approach. This approach provides the strongest privacy guarantees: it doesn’t require trusting that the cookie consent systems will respect your choice, and prevents your browser from needing to communicate with consent-tracking systems at all.
The other approach is to trust and work with cookie banners. Instead of blocking these systems (as Brave does), this alternate approach automates the process of clicking “no” in cookie-banner systems. While this approach may reduce the number of cookies sent and the overall nuisance of banners, it still records your preference with the cookie banner providers. This creates a situation of requiring the browser or extension to repeatedly ask the cookie banner provider to leave you alone. Worse, researchers have found that many cookie-and-consent systems still track people, even when users reject all cookies.
Brave’s approach to blocking cookie banners requires Brave to stay one step ahead of trackers and the companies that run the (nightmarishly titled) “consent-management systems.1” Brave keeps ahead of trackers in several ways, including supporting crowd-sourced filter lists such as EasyList, and conducting research to help privacy activists stay one step ahead of trackers.
Unfortunately, Google has been pushing changes to the Web that would make it more difficult to block cookie banners and, more generally, to filter out unwanted Web content (such as intrusive images, videos, ads, and tracking scripts). Google’s WebBundles proposal, for example, will make it easier for sites to evade content blockers. Their Manifest v3 changes remove vital capabilities from privacy-protecting browser extensions. And many aspects of Google’s sprawling Privacy Sandbox proposal would generally give users less control–and sites more control–over how people use and experience the Web.
Ironically, cookie banners (a universally-despised Web annoyance) shows both i) the Web’s uniquely democratic, user-first platform, and ii) what will be lost if the Web continues in the direction Google is pushing it.
The Web is built to be open. On the one hand, that’s great: It means privacy-protecting Web tools like Brave can act on behalf of users, and protect them from Web abuses and annoyances. On the other hand, cookie banners highlight how much worse the Web will get if Google (and others) succeed in weakening users’ ability to block such annoyances.
Sometimes called “preference management systems”. ↩︎
Starting with version 1.73, Brave is significantly improving its adblocking capabilities by adding support for procedural cosmetic filtering of page elements.
Read this article →Starting with iOS version 1.71, Brave is rolling out a way to quickly delete browsing data that sites can use to identify you across visits. It's called Shred.
Read this article →Starting with version 1.68, Brave will become the first iOS Web browser to try to upgrade all sites to HTTPS by default.
Read this article →