This is the ninth in a series of blog posts on new Brave privacy features. Author: Peter Snyder, Director of Privacy and Senior Privacy Researcher. Implementation: Anton Lazarev, Research Engineer.
In order to improve privacy and Web compatibility, Brave will by default not apply network level filter list blocking to same-site
1 subresources, starting in version 1.30, or the Beta and Nightly versions at time of this posting
2. Brave will continue blocking third-party requests as it currently does, using the crowdsourced information gathered by EasyList, EasyPrivacy, uBlock Origin and similar projects. This change is being made for two reasons. First, recent privacy protections in Brave protect users from the kinds of tracking first-party subresources can carry out (e.g. fingerprinting). Second, this change aims to reduce how often Brave users have to “drop shields” (i.e. disable Brave’s privacy protections) to use certain sites, leaving those Brave users exposed to the worst kinds of privacy harm.
This change affects only the default settings; Brave users who wish to retain current, more aggressive but occasionally-website-breaking behavior can do so by setting the “trackers and ads blocked” setting in Shields to the “aggressive” setting. Brave’s goal is to create the best-in-class privacy protecting browser, to provide defaults we think best suit most users, and to leave the user in full control if they want to block more content. Finally, Brave will still selectively block first-party subrequests when we know they are user-harmful or unwanted. The policy change described in this post describes only a change in the default policy.
As with all changes, we’d appreciate your feedback. The best place to provide feedback is at
Brave Community. Any notes or observations you have about whether this change seems to decrease (or increase) how often you need to drop shields when using Brave would be particularly appreciated.
Changing Shields Behavior Will Improve Privacy
Brave is disabling filter list blocking for first-party subresources to improve privacy for typical Brave users. Advanced users still have the ability to deploy more aggressive privacy protections, even those that might break sites. This change disables blocking in cases where privacy risk is the smallest, in order to improve Web compatibility and reduce the frequency of the worst case privacy outcomes. By default, Brave blocks network requests for tracking and Web annoyance resources, as determined by
popular, crowd sourced filter lists. Filter list based blocking has many benefits; blocking improves performance, saves battery life, and (in the absence of other protections) improves privacy. However, Brave features such as blocking third party cookies,
ephemeral third-party storage and
browser fingerprint randomization provide platform wide defenses against the kinds of privacy harms other browsers need filter lists to protect against.
Because of these other privacy features in Brave, some added more recently, the largest privacy gain from filter-list blocking is in preventing third-parties from learning your IP address; there is much less privacy benefit in blocking first party requests, because the first party already knows your IP address. While there can be some privacy benefit in blocking some first-party subrequests, such cases are ad hoc and depend on developer implementation decisions, instead of fundamental aspects of the Web. Filter list based blocking comes with significant downsides too. For example,
filter lists can fall out of date causing performance and compatibility problems. More significantly, filter list blocking can break sites requiring users to disable Brave’s privacy protections (i.e. “dropping shields”) to use a site. Dropping shields is the last resort for trading user privacy against site compatibility, as it disables all of Brave’s privacy protections on the site, to maximize the chance of un-breaking the page. Users who drop shields may wish they re-raised them at a later date, but often won’t remember to do so.
And while advanced users can use Brave Shield’s more advanced settings to apply narrower, more surgical interventions to unbreak sites, doing so is beyond what most users can do and should have to do, to use the Web.
Differences Between Standard and Aggressive Blocking
Brave offers users three levels of tracking protection, configurable through Brave Shields:
- Trackers & and ads blocked (aggressive): Apply all Brave blocking and filtering tools, even those with an increased risk of breaking sites.
- Trackers & and ads blocked (standard): This is the default policy in Brave. Apply the blocking and filtering approaches Brave thinks provides the best privacy for most Brave users.
- Allow all trackers & ads: Apply no blocking or filtering tools.
The below table details the differences between the aggressive and standard blocking levels.
How to Maintain the Current Shields Behavior
Advanced Brave users who wish to maintain the existing blocking behavior can do so in two ways.
The first option is to change Brave’s blocking settings to
Trackers & and ads blocked (aggressive). This can be done for all, or specific, sites
by configuring Shields. The second option is by visiting brave://flags and disabling the #brave-adblock-default-1p-blocking setting.
1 Same-site, or first party, subresources here refers to requests for images, scripts, or other page elements that come from the same site as the page requesting those subresources. If you are on
Welcome to cats.com Created in 1991 15,000+ visitors per month,
https://cats.com/logo.png and
https://food.cats.com/kibble.js are both examples of same-site subresource requests, while
https://dogs.com/logo.png would be a third-party sub resource request.
2 These changes are being rolled out to users over the next 24 hours, and should be live on Nightly and Beta releases by end-of-day on Sept 2, 2021.
community.brave.com
brave.com
