Ephemeral third-party site storage

This post describes work done by Principal Engineer Brian Johnson, Senior Software Engineer Ivan Efremov, and Senior Privacy Researcher Peter Snyder.

The TL;DR

Since our first release, Brave has by default blocked all third-party application storage (e.g., cookies, localStorage, indexedDB). Blocking third-party storage protects Brave users from the most common forms of tracking, but can also break sites. This post presents “ephemeral site storage”, a new strategy for managing third-party storage in Brave, designed to improve Web compatibility, while maintaining the same level of privacy protection.

“Ephemeral site storage” can be enabled in Brave Nightly now, by visiting brave://flags and setting “Enable Ephemeral Storage” to “Enabled.” The feature will be enabled by default on our Desktop and Android browsers shortly, once the system has been sufficiently tested in Nightly.

Background: Brave’s Current Third-Party Storage Protections

Most tracking on the Web, for most of the Web’s history, has relied on “third-party storage”, or the saving and retransmitting of unique identifiers to sites other than the one you intend to visit. This tracking and re-identification occurs generally without your consent, or even knowledge. And for nearly as long, privacy focused browsers have different techniques to protect users against tracking that relies on third-party storage.

To date Brave has had the most aggressive policy of a popular, general use browser; namely, disabling third-party storage all together. While blocking third-party storage provides strong privacy protections, those protections come with the significant risk of breaking sites that expect third-party storage to be available. And, unfortunately, since the most popular browser allows mostly unrestricted third-party storage, most sites are built assuming third-party storage.

As a result, it’s not uncommon for sites to break in Brave, forcing users into the no-win choice of either having their privacy violated, or having a diminished browsing experience. To date we’ve dealt with breaking sites through a combination of script injections, DOM modifications, and as-narrow-as-possible storage exceptions. While this has (mostly) worked, it’s deeply unsatisfactory, and still involves some risk of privacy loss.

The rest of this blog presents “ephemeral site storage”, a new system that protects against tracking, at a far lower risk of breaking benign site functionality. The post then describes how “ephemeral site storage” compares to the third-party storage policies in other browsers.

How “Ephemeral Site Storage” Works

“Ephemeral site storage” is the result of combining several smaller storage decisions. We’re currently evaluating each of these decisions during our test period, so any of these details may change as we get more experience and feedback.

First, never send cookies on third-party sub-resource requests. Brave will continue sending cookies for sub-resource requests that occur in the main document, or in other sub-documents that are local (i.e., same-site) to the main document, but Brave will not send cookies on cross-origin sub-resource requests occurring in the first-party context. Brave also will not send cookies on any sub-resource requests occurring in a third-party context (cross-origin or otherwise).

Second, third-party frames get partitioned storage for some DOM storage APIs. JavaScript executing in a third-party frame can use the document.cookie, localStorage and sessionStorage APIs, though the values they see are partitioned under the first-party site. This means that code running in a social.org <iframe> embedded on example.org will see different storage than a social.org <iframe> embedded on other.org. Our initial “ephemeral site storage” implementation only allows sites to access these three storage APIs; all other DOM storage APIs are still disabled for third-parties, though we may enable more in the future.

Third, storage is shared for all first-party instances of the same site. If a user has two tabs open to the same site (i.e., same eTLD+1), third-parties on those sites will see the same storage area, and can use it to communicate. For example, say you have two tabs open for the same site, first.example.org and second.example.org, and that both of these pages include an embedded YouTube iframe. Both instances of the YouTube iframe would see the same storage area. However, a YouTube embed on different.org would see a different storage area, and a tab loading youtube.com directly would see a third storage area.

Fourth, third-party storage partitions are cleared when the last first-party document is closed. As mentioned before, third-party documents get a different storage area for each top-level site. As long as there is at least one top-level document open for the site, the storage area will persist, and the third-party will see the same storage for any new top-level documents for the same-top level site. However, when there are no longer any top-level documents for a site, all third-party partitions under that site are cleared. If you later revisit the same first-party site, all third-parties embedded on that site will see new, empty storage areas.

Fifth, storage partitions are cleared when the browser is restarted. When you quit Brave, all partitioned storage areas are cleared, regardless of whether you’re restarting the browser, or if you have “Continue where you left off” and related features enabled. This matches when Brave rotates the random seed used to randomize your browser fingerprint, and is done in part to avoid the kinds of unexpectedly long-lasting session values that have been discussed by Eric Lawrence on the Edge team.

The above describes our initial version of “ephemeral site storage”. While we’re excited to deploy and share this version of it, we will be evaluating it in practice, to see how it can be further improved. A partial list of additions we’re considering are integration with the Storage Access API (implemented in Chromium by the terrific Edge team), sending partitioned cookies with iframe navigation, and adding additional DOM Storage APIs. Any changes to the “ephemeral site storage” policy described here will be discussed in future posts.

Comparison With, and Credit To, Other Browsers

The “ephemeral site storage” system described in this post sits alongside other great work done by other privacy oriented browser vendors. We now briefly describe how “ephemeral site storage” compares to browser’s third-party storage policies, both to give credit to the ideas we’ve built from, and to motivate some of the choices made in Brave’s solution.

In many ways, our “ephemeral site storage” proposal is most similar to how Safari manages third-party storage. Safari deserves enormous credit for popularizing partitioning third-party storage as a defense against third-party tracking. Safari, along with the Tor Browser Bundle (TBB, which has long partitioned third party storage as part of a larger “First-Party Isolation” feature), gives third-parties different storage areas, depending on which site they’re embedded in.

Brave’s implementation also draws from Safari’s strategy of “ephemeral” third-party storage. However, Brave’s approach differs from Safari’s in a significant way. Safari clears third-party storage partitions when the browser is closed; Brave clears third-party storage when the site is closed. While each approach has its trade-offs, our site-length approach protects Brave users against certain cases where a third-party might be able to link first-party accounts, in a way the first-party didn’t intend. Nevertheless, we want to note and credit the Safari and TBB teams for, in many ways, pioneering partitioned application storage.

Additionally, we want to appreciate and highlight related work the Firefox team has done in this area. Firefox is also testing a partitioned application storage approach in nightly versions of the browser (though the approaches differ; where Brave persists partitions for only as long as you are interacting with the site, partitions in Firefox are persistent. Partitions in Safari persist until you quit the browser).

Also, while in some aspects Brave’s “ephemeral site storage” approach is more aggressive than the Safari, Firefox, and TBB approaches, there are other areas where the other browsers are leading the way. While Brave’s current approach focuses on the most common ways storage is used to track users, Safari, Firefox and TBB currently partition other kinds of storage more comprehensively than Brave does. This includes (depending on the browser) the HTTP cache, other network caches, services workers, other DOM Storage APIs, etc. Firefox in particular recently announced an impressive and comprehensive partitioning strategy. These are extremely important parts of protecting Web privacy, and their teams deserve tremendous credit for their leading work.

We also want to note the terrific work being done by the Chromium team on implementing partitioning of caches and network services. This work is extremely difficult and subtle, and doesn’t often attract the attention that new user-visible features receive, but is nonetheless vital to improving privacy on the Web. So we note and appreciate the critical work the Chromium team is doing around in the area, and the security and privacy improvements it’ll bring to users of Chrome, Brave, Edge and other Chromium-family browsers.

Finally, we want to thank folks whose comments and thinking (knowingly or otherwise) have been helpful in our thinking around “ephemeral site storage”, including Michael Kleber, Maciej Stachowiak, John Wilander, Steven Englehardt, and Anne van Kesteren.

Special Acknowledgment: We also want to thank Martin Robinson and Cathie Chen from Igalia for their help in developing and implementing this feature in Brave.