Grab bag 5: "Open in App" annoyances, further pool-party protections, and more…

This is the 23rd post in an ongoing, regular series describing privacy features in Brave browsers. This post describes work done by (in alphabetical order): Filter List Enginer Ryan Brown, Research and Privacy Engineer Arthur Edelstein, and Senior Research Engineer Anton ​​Lazarev. This post was written by VP of Privacy Engineering Peter Snyder.

1. Hiding “open in app” annoyances

Starting in upcoming version 1.49 (Android and desktop) and already available since version 1.44 for iOS, Brave will hide “open in app” annoyances that appear on many websites. The links are annoying; they prompt you with unrelated questions when you’re trying to browse the Web. Worse, these notices are often privacy harming. Sites know that the “native” versions of their apps aren’t subject to the kinds of privacy-protections that Brave applies to websites, and they’re thus eager to nudge users into the (often) data-gobbling native apps.

Brave will hide “open in app” annoyances by enabling the terrific “Fanboy’s Mobile Notifications List,” maintained in part by folks working at Brave. Users who want to disable this feature can do so by going into settings and disabling “Fanboy’s Mobile Notifications List” list from the list of custom and regional filter lists.

2. Additional protections against “pool-party” attacks

Starting in version 1.49, the desktop and Android versions of Brave will include additional protections against “pool-party” attacks. Pool-party attacks are a category of attack that advanced and motivated trackers can use to link your browsing behaviors across sites (and, in some browsers, across profiles), by leveraging the unintended consequences of how some browser features are implemented. As mentioned in a previous post, most browsers are vulnerable to some form of the attack, though some browsers are more vulnerable than others.

Brave has defended against what was thought at the time to be the most serious form of the attack since version 1.35. However, researchers at Brave have recently identified more ways pool-party attacks can be conducted, and ways they can be carried out faster (i.e. how they can be optimized to communicate across site boundaries faster). As a result, Brave has released fixes to protect against additional forms of the attack ¹. We are continuing to discuss possible solutions to pool-party attacks with other browser vendors as well.

For more detail on pool-party attacks, please see our research paper that will be presented at USENIX Security 2023.

3. Improved ad blocking with procedural cosmetic filters

Starting in versions 1.49 (Android and desktop) and already available since 1.45 for iOS, Brave includes partial support for procedural cosmetic filters, an advanced way of specifying which page elements should be hidden when blocking ads and other page annoyances. Most cosmetic filters are defined through CSS selectors; filter list maintainers can specify unwanted page elements to hide using the same system that website designers use to style elements on a page. In the vast majority of cases, this simple capability is all that’s needed.

However, sometimes websites try to evade content blocking tools; in these cases content filtering tools need more sophisticated ways of specifying which page elements should be hidden. Procedural cosmetic filters are a solution to this problem, and are an important tool that browsers and Web tools can apply to keep users in control.

There are many different procedural filters, and Brave supports the two most popular ones ². We plan to support more procedural filter rules soon.

4. Protecting against screen attribute-based browser fingerprinting

Starting in versions 1.48 (Desktop) and 1.50 (Android), Brave is expanding our browser fingerprinting protections by preventing sites from identifying you based on the size of your screen and position of your browser window. Trackers try to identify you through browser fingerprinting by combining enough semi-identifiers (things that distinguish you from some other users) to build a unique identifier. No browser user is likely to be the only browser user in their country, but they might be the only browser user in their country, using a specific version of the browser, speaking a specific language, with particular graphics hardware, etc.

The size of your screen is another such semi-identifier that trackers use. On their own, your screen’s width and height aren’t enough to uniquely identify you. But if they’re different enough from those of many other browser users, they can help trackers narrow down who you are as you browse the Web. In addition, the position of your browser window on the screen may be fairly unique and another way your browser can stand out.

To combat this, Brave now prevents trackers from learning the size of your device’s screen and the position of your browser window on the screen. First, Brave reports to Web scripts that your screen has approximately the same width and height as your browser window. This prevents trackers from learning about your true screen size. Second, as with Brave’s other unique randomization-based protections, Brave reports slightly different values to each site, for each browser session. This prevents trackers from re-identifying you across different sites, or across different visits to the same site.