Grab bag 2: permission lifetimes, bounce tracking, and fingerprinting protections

This post describes work done by Software Engineer Aleksey Khoroshilov, Principal Engineer Brian Johnson, Senior Software Engineer Ivan Efremov, Privacy Project Manager and Engineer Shivan Sahib, Senior Software Engineer Mark Pilgrim, and Director of Privacy Peter Snyder.

In order to stay one step ahead of online trackers, Brave regularly releases new privacy features and improvements. This post discusses four recent changes in Brave that achieve better user privacy and Web compatibility.

Improved Web Permission Lifetimes

Since the release of Brave browser version 1.25 (on desktop and Android) a few weeks ago, users now have more control over how long sites can access powerful, but privacy-sensitive browser features, like geolocation sensors, webcams, and microphones.

Previously Brave used the default Chrome behavior for permissions, which limited users to giving access to the relevant capability forever, or never. There was, for example, no easy way to say “this site can use my webcam while I have the page open, but ask me again next time.”  Limited “all or nothing” options encourage oversharing of data, which benefits trackers who would like to record as much information about you as possible (for example, Google Maps, Facebook ,etc.). In fact, when Apple found that, when users had the option to limit how long apps had access to geolocation data, users ended up sharing 68% less geolocation data, an enormous privacy improvement.

Brave users can now choose to give sites temporary access to permission-protected capabilities to better protect their privacy. Common examples of permission-protected browser capabilities include web cameras, microphones, location information, and motion sensors, among others. 

This is similar to, though more powerful than, protections offered in other browsers.  Safari and Firefox allow users to give sites either permanent access, page-length access, or no access.  Brave now allows users to give sites access to permission-gated capabilities for limited amounts of time. Chrome is also testing allowing users to give similar options, though only for geo-location data.

Additional Bounce Tracking Protections

Browsers are ¹ starting to defend against the most common, straightforward forms of tracking on the Web, including third-party cookies, third-party storage, and browser fingerprinting. In response, trackers are moving to more sophisticated types of tracking, including “first-party tracking,” or methods for linking your identity and actions on one site, with your actions or identity on other sites.

The most common form of first-party tracking is bounce tracking, where sites add unique identifiers to URLs before you navigate away from a site.  For example, Facebook’s tracking scripts add unique identifiers (i.e., fbclid) to URLs before you leave a site, so that Facebook scripts on the destination site can read the same identifier from the URL, enabling Facebook to know the same person visited both the “from” and “to” sites. 

The common terms for this kind of tracking are bounce tracking, or more broadly, navigation-based tracking. Broadly, this form of tracking is defined by sites trying to break the privacy improvements brought by isolating or partitioning first-party storage, by pushing unique identifiers across site boundaries.

To date, browsers have done a poor job of protecting against this form of tracking. Safari’s Intelligence Tacking Protection 2.0 system offers some protection, and Brave protects users from known bounce trackers by stripping tracking parameters from URLs. While useful, both systems are incomplete and do not protect users against some forms of bounce tracking.

Brave is improving its bounce tracking protections by (in aggressive mode) notifying users who are about to visit a URL suspected as a bounce tracker. When users have i) enabled aggressive tracking protections, and ii) are about to visit a URL that filter lists label as suspect, Brave will present users with an interstitial, notifying them that the URL may be privacy harming.  Advanced users can then choose to abort the request, or visit the URL none-the-less.

We anticipate that this kind of defense will only be useful to advanced users, and so the interstitial warning is only presented for users who have opted into the most aggressive privacy protections. However, our goal is to provide comparable protections to all Brave users, advanced, novice, and in between. We will shortly be announcing our plans to extend these bounce tracking protections to all Brave users, including Brave users with the default blocking settings.

Brave determines if a URL is likely to be a bounce tracker by using the same approach as the excellent uBlock Origin project, using the approach uBlock Origin calls “strict blocking".  Roughly, the above interstitial will warn users of possible bounce tracking if all the below are true:

• The user has shields set to “ads & trackers blocked (aggressive)”
• A top-level navigation request would be blocked by a filter list rule (from EasyList, EasyPrivacy and uBlock Origin’s lists, among others)
• There isn’t a specific ~document exception for the URL

Ephemeral Storage “Keep Alive”

Brave previously announced a novel form of storage partitioning called “ephemeral third-party storage” that is designed to prevent cross-site and cross-session tracking without breaking websites. Brave has improved on this policy to preserve the same privacy protections but to un-break additional sites that expect third-party storage to persist. Most significantly, this means that some Single-Sign On (SSO) and similar integrations that broke under the original third-party ephemeral storage implementation will now work as expected without sacrificing user privacy.

Previously, Brave cleared all third-party storage areas embedded in a site the moment there were no longer any more top-level documents for the site open. This protected privacy well because it meant that if you closed a site and then returned to it later, then by default embedded third parties would have no memory of you. This is a useful protection for sites you maintain multiple accounts on since it removes many of the ways an embedded third-party might be able to identify you as the owner of both accounts.

Unfortunately, ephemeral third-party storage would break useful flows like SSO for the technical reasons detailed here. Brave now prevents this category of breakage by waiting a short period of time before clearing the partitioned third-party storage areas (currently, 30 seconds).

So, previously, if example.org included an iframe for third-party.org, the storage for third-party.org would be closed the instant there were no more example.org tabs open; Brave now waits for 30 seconds after the last example.org tab was closed before clearing the storage for third-party.org. If another example.org tab is opened within that 30 second window, the timer is canceled.

We’re experimenting with this 30-second window, to see if more or less time is optimal, but so far we’ve found 30 seconds to be a useful way to minimize the lifetime of third-party state, without breaking sites (and so requiring users to drop shields all together).

Additional Fingerprinting Protections

Finally, Brave has implemented additional fingerprinting protections, to stay one step ahead of the trackers. A partial list of improvements to Brave’s fingerprinting protections are as follows:

• Dark mode fingerprinting protections (strict mode)
• Improvements to WebGL fingerprinting protections (strict mode)