|Originally deployed in||0.55.18|
|Latest update deployed in||v1.30.86|
|Latest update includes||No longer block requests to filtered origins if the requests are same-site with the site the user is browsing.|
|User controls||Site-specific and global controls for:
Brave classifies tracking domains using input from multiple lists:
Brave matches each outgoing request from the web browser against these lists (using various methods for achieving optimized performance), and if a match is made, the request is blocked.
Note! If the resource that should be blocked is same-site to the site the user is browsing, the request will not be blocked. Thus if the user is browsing
www.domain.com and the browser sends a request to
blocked-tracker.domain.com (which is in Brave’s filter lists), the request will not be blocked.
https://www.google-analytics.com/analytics.js. This URL (and the entire domain, in fact), is listed in the EasyPrivacy list. Thus Brave blocks the request, preventing the browser from downloading the library and executing the Google Analytics tracking code in the web browser.
All third-party cookies are blocked by default in subresource requests (e.g. CDN loads, pixel pings).
In frames (e.g.
<iframe>), access is partitioned and set to site-length expiration.
Partitioned access means that the
document.cookie API will work in a cross-site
<iframe>, but the storage will be unique between the site embedding the frame and the frame itself. Another site embedding the same frame would have a different storage profile.
Site-length expiration means that as soon as the last page of the site embedding the cross-site frame is closed, the partitioned storage is cleared. This is different to how e.g. Safari works, where the storage is cleared only upon the browser being closed (this clears the storage also in Brave).
document.cookie, expiration is set to a maximum of 7 days.
Example: The user visits a page that is running an A/B testing tool which stores the experiment details into a cookie named
For cookies set with the
Set-Cookie HTTP response header, expiration is set to a maximum of 6 months.
Partitioned and site-length expiration for
sessionStorage APIs (see Third-party cookies for more information).
Brave Shields blocks network requests to domains in Brave’s blocklists. With version 1.17.73, Brave now also resolves the DNS of any given domain and identifies if there are CNAME records pointing to domains that are in the blocklists, and blocks these as a result, too.
Example: The web page sends a pixel request to
https://measure.example. This domain is not in Brave’s blocklist, so Brave would normally allow the network request to complete. However,
measure.example is a CNAME record which actually points to
track.everything, which is in Brave’s blocklist. As the domain the CNAME points to is in Brave’s blocklist, Brave blocks the initial request to
https://measure.example as a consequence.
For cross-origin subresource and navigational HTTP requests, Brave defaults to the
strict-origin-when-cross-origin Referrer Policy. Brave prevents the policy from ever being more relaxed than this, so even if a policy of e.g.
unsafe-url is used, cross-origin requests would still have the referrer set to just the origin of the referring page.
Example: When clicking a link from
referer header is set to
https://domain.com. Similarly, the
document.referrer will be set to
https://domain.com once the user lands on
For same-site requests (both navigational and non-navigational), referrer has normal behavior.
Brave removes known tracker identifier parameters from URL strings. On top-level navigation (e.g. landing on a page with such parameters in the URL), the parameters are stripped out in a 307 internal redirect. On non-navigational HTTP requests, the parameter is stripped from the request URL.
Here is the list of parameters that are stripped:
Example: If the user types
https://www.domain.com/?fbclid=188.8.131.52 in the omnibox and presses enter, Brave strips the parameter in an internal redirect. Similarly, if the browser makes a request to
https://www.domain.com/tracking-pixel.gif?mc_eid=23456, Brave strips the parameter out of the request before it hits the target server.
On macOS Brave, the version number in the User Agent string is frozen to
10_15_7 to fix compatibility issues with upgrading to macOS version 11+ (Big Sur). This has obvious privacy implications as well, as the platform version is no longer useful for fingerprinting purposes.
Sample User Agent string when running Brave 1.24.85 on macOS 11.3.1:
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36"