At a glance

Current status

DetailDescription
MechanismShields
Originally deployed in0.55.18
User controlsSite-specific and global controls for:
  • Cross-site tracker blocking
  • Automatic connection upgrade to HTTPS
  • Script blocking
  • Cookie blocking
  • Device recognition blocking

Brave Shields default settings

Classification of “known trackers”

Brave classifies tracking domains using input from multiple lists:

These are the main lists. Brave’s list catalog has the full, current set.

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.

By blocking requests upstream, it means that if the request initiated a resource download (such as a JavaScript library), this resource is never downloaded and thus the code is not executed in the user’s browser. If the request initiated a pixel call (such as a GET for an image), it means the pixel call will be aborted before it is received by the endpoint.

Blocking of known trackers

With Shields at their default Standard level, Brave blocks third-party requests that match its filter lists. This covers ads, trackers and cryptominers, and also known fingerprinting services: Brave says it blocks requests to fingerprint.com’s domains and other known fingerprinting services.

Requests that are same-site with the page the user is browsing are not blocked (see the note above).

Some scripts are not blocked outright but replaced with a stripped-down version that keeps the page working, for example so that a site calling a missing analytics function doesn’t break.

Third-party cookies

All third-party cookies are blocked by default in subresource requests (e.g. CDN loads, pixel pings).

Brave uses "cross-site" interchangeably with "third-party" in this case

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 shortly after the last page of the site embedding the cross-site frame is closed, the partitioned storage is cleared. Brave waits about 30 seconds, so that sign-in flows that briefly leave the site keep working. 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).

First-party cookies

Cookies have a maximum expiration of about 6 months. This applies to cookies set with JavaScript’s document.cookie and with the Set-Cookie HTTP response header alike.

Other third-party storage

Partitioned and site-length expiration for localStorage and sessionStorage APIs (see Third-party cookies for more information).

Other first-party storage

No restrictions.

CNAME cloaking

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.

Fingerprinting

Brave has lots of initiatives for neutralizing fingerprinting surfaces. By default, it randomizes the values returned by APIs that are commonly used for fingerprinting, such as the HTML canvas. The random seed changes per site and per session, so the same device looks different on each site and after a restart. Highly identifying APIs are blocked, as are browser-language and font fingerprinting.

Known fingerprinting services are also blocked outright.

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.

Referrer

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.

For same-site requests (both navigational and non-navigational), referrer has normal behavior.

Other

Brave also skips known bounce trackers ("debouncing"). If a link goes through a known tracking domain on its way to the real destination, Brave navigates straight to the destination, so the tracking domain never sees the visit.

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:

  • __hssc (HubSpot)
  • __hstc (HubSpot)
  • __hsfp (HubSpot)
  • __s (Drip)
  • _hsenc (HubSpot)
  • _openstat (OpenStat)
  • dclid (Google)
  • fbclid (Facebook)
  • gbraid (Google)
  • gclid (Google)
  • hsCtaTracking (HubSpot)
  • igshid (Instagram)
  • mc_eid (Mailchimp)
  • ml_subscriber (MailerLite)
  • ml_subscriber_hash (MailerLite)
  • msclkid (Microsoft)
  • oly_anon_id (Olytics)
  • oly_enc_id (Olytics)
  • rb_clickid
  • s_cid (Adobe)
  • twclid (Twitter)
  • vero_conv (Vero)
  • vero_id (Vero)
  • wbraid (Google)
  • wickedid (Wicked)
  • yclid (Yandex/Yahoo)

History

  1. Brave

    Brave skips known bounce trackers

    With “debouncing”, Brave notices when a link goes through a known tracking domain and navigates straight to the destination (desktop 1.32).

    affects: other · source: Debouncing (Brave privacy updates)

  2. Brave

    Brave announces ephemeral third-party storage announced

    Instead of blocking storage in third-party frames, Brave gives each one a temporary partition that is cleared when the user leaves the site. It was turned on by default later in 2021.

    affects: 3rd-party cookies, 3rd-party storage · source: Ephemeral third-party site storage (Brave privacy updates)

  3. Brave

    Brave uncloaks CNAME trackers

    Brave 1.17 resolves the DNS of each request and blocks it if a CNAME record points to a domain on its blocklists.

    affects: cname cloaking · source: Brave 1.17.73 release