Grab bag 3: fixing pool-party, improving fingerprinting protections, more debouncing, and less Chromium

This is the fifteenth post in an ongoing series describing new and upcoming privacy features in Brave. This post describes work done by Software Engineer Aleksey Khoroshilov, Senior Software Engineer Mark Pilgrim, Filter List Engineer Ryan Brown, and Senior Software Engineer Max Karolinskiy. This post was written by Director of Privacy Peter Snyder.

TL;DR;

Brave continues to ship the most aggressive and broad privacy protections available in any popular browser. Desktop and Android versions of Brave now include:

• Fixes for the Pool-Party vulnerabilities we recently disclosed
• Additional defenses against browser fingerprinting
• Protections against a large number of additional bounce-trackers
• Removal of further privacy-harming features in Chromium

Read on to learn more.

Note: The bounce-tracking improvements are already deployed for all Brave users. The other three changes are included in forthcoming Brave 1.35 (currently in Brave Nightly).

1. Fixing the “Pool-Party” Cross-Site Tracking Vulnerability

Starting in Brave 1.35, Brave includes protections against all known practical forms of “pool-party” attacks. All browsers are vulnerable to pool-party attacks, though some more than others. Brave is now one of only two browsers to protect users from realistic pool-party attacks¹.

Brave protects users from pool-party attacks by partitioning the global limit on WebSocket connections by site, meaning that all sites are restricted to a maximum of 30 WebSockets (Edit: the initial version of this post specified 10 WebSockets per site. This number has since been increased to 30 for web-compat reasons). This change prevents sites from using the global WebSocket pool to communicate across site boundaries. (Brave users were never vulnerable to the other practical pool-party attack that Brave researchers identified, which used the global Server-Sent events pool. That form of pool-party attack only applied to WebKit-based browsers.)

“Pool-party” attacks are not a specific vulnerability, but a category of attack technique enabled by implementation decisions in browsers. Any browser resources that are limited (e.g., there is a limit on the number of times a site can perform an action) and shared across privacy boundaries (e.g., multiple sites draw from the same pool of limited resources) can be abused by an attacker to communicate in ways not intended by the browser. Trackers, for example, can use these techniques to link identities on different sites, allowing users to be tracked despite other browser protections.

Brave users are now protected against all known practical forms of the attack. The other forms of pool-party attack we identified in Chromium-based browsers are difficult enough to carry out that they would not be suitable for web trackers, either because those forms of the attack use resources with short-lived lifetimes (e.g., limits on the number of simultaneous DNS requests), are only available in uncommon configurations (e.g., when Chromium browsers are configured to use an HTTPS proxy), or are very low bandwidth (e.g., using the global WebSpeech handle).

Brave continues to watch for, and protect users against, future pool-party attacks. We will work in standards bodies and with other browser vendors to prevent new proposals that would enable pool-party attacks.

2. Preventing SpeechSynthesis-Based Browser Fingerprinting

Starting in Brave 1.35, Brave prevents websites from abusing the SpeechSynthesis API to fingerprint (and thus track) Brave users. These new defenses build on Brave’s unique, randomization-based approach to fingerprinting protection.

By adding small amounts of “noise” to the features trackers use for fingerprinting, Brave preserves user-benefiting functionality while preventing tracker-based user identification. Randomizing fingerprinting keeps users private, and is why Brave continues to have the strongest fingerprinting protections of any popular browser.

3. More Rules to Defeat Bounce-Trackers

Android and Desktop versions of Brave now include protections against many more bounce-trackers. Brave includes a unique (among browser vendors) feature called “debouncing” to protect users against bounce-tracking. Brave has increased the number of bounce-trackers we protect against, and will continue to add more as they’re discovered.

Bounce-tracking is a form of online tracking that’s become more common as privacy-focused browsers like Brave block or partition third-party cookies. The main way trackers work is by convincing sites to include tracker code on their pages (e.g., Google Analytics, Facebook like buttons, etc.), and then using third-party cookies to send the same identifier across sites. Browsers increasingly block or partition third-party cookies to prevent against this form tracking. Functionally, this means that resources loaded from the same tracker on two different sites will break the identification chain—the tracker no longer receives the same cookie (identifier) across sites, preventing the tracker from being confident that both requests came from the same person. Bounce-trackers try to continue tracking, despite such protections, by injecting themselves between the referring site and the to which a user is being redirected. The tracker then knows the same person visited both sites and, over time, can build a detailed user profile.

Brave’s debouncing feature works by identifying when a tracker is injecting itself between sites, and “fast forwarding” past the tracking site; Brave never visits the tracking site, and instead takes the user directly to the destination site.

Brave’s bounce tracking protections are stronger and more robust than what is offered in other browsers. Other browsers load the intermediate bounce-tracking site, but then clear storage for the site soon after. This allows certain types of trackers to still operate (for example, if a user identifier is included in the URL the bounce tracker receives, or if the bounce tracker can re-identify the user through fingerprinting).

Our debouncing rules are open and public, and other privacy-improving projects are welcome to use or contribute to the list. Brave users and Brave Researchers both use and contribute to other privacy-improving lists, and we hope our debouncing list can similarly benefit other Web privacy tools.

4. Removing the Network Information API

Brave versions 1.35 and higher remove support for the non-standard Network Information API. This functionality, available in Chromium browsers and (partially) in some versions of Firefox, allows sites and trackers to learn detailed information about a user’s network. For instance, a site or tracker could detect the type of connection (e.g., “ethernet,” “bluetooth,” or “3g”), a change in network quality (e.g. Wi-Fi to mobile), and when a user changes local networks (since a local network can change independently of the IP address originally associated with a user).

The Network Information API poses an unacceptable privacy risk to Web users. Among other issues, the API shares information that can be used by trackers and attackers to fingerprint users, learn when they’re traveling or not at home, and learn when they’re connecting through an anonymizing VPN. As of Brave version 1.35, the feature is disabled regardless of Shields settings. Advanced users can re-enable the feature in brave://flags, but we discourage this.

Removing the Network Information API is just the latest in a long list of Chromium features Brave removes or disables. Brave aggressively modifies, configures, and adds to Chromium to provide Brave users the best possible Web experience: the strong security features available in Chromium, coupled with the best privacy protections available in any popular Web browser.