As mentioned before, third-party documents get a different storage area for each top-level site. However, a YouTube embed on would see a different storage area, and a tab loading directly would see a third storage area.įourth, third-party storage partitions are cleared when the last first-party document is closed. Both instances of the YouTube iframe would see the same storage area. For example, say you have two tabs open for the same site, and, and that both of these pages include an embedded YouTube iframe. 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.

Third, storage is shared for all first-party instances of the same site. 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. This means that code running in a embedded on will see different storage than a embedded on. JavaScript executing in a third-party frame can use the okie, localStorage and sessionStorage APIs, though the values they see are partitioned under the first-party site. Second, third-party frames get partitioned storage for some DOM storage APIs. Brave also will not send cookies on any sub-resource requests occurring in a third-party context (cross-origin or otherwise). 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. 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.įirst, never send cookies on third-party sub-resource requests. “Ephemeral site storage” is the result of combining several smaller storage decisions. The post then describes how “ephemeral site storage” compares to the third-party storage policies in other browsers. 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. While this has (mostly) worked, it’s deeply unsatisfactory, and still involves some risk of privacy loss. To date we’ve dealt with breaking sites through a combination of script injections, DOM modifications, and as-narrow-as-possible storage exceptions. And, unfortunately, since the most popular browser allows mostly unrestricted third-party storage, most sites are built assuming third-party storage.Īs 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. 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. To date Brave has had the most aggressive policy of a popular, general use browser namely, disabling third-party storage all together. And for nearly as long, privacy focused browsers have different techniques to protect users against tracking that relies on third-party storage.

This tracking and re-identification occurs generally without your consent, or even knowledge. 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. Background: Brave’s Current Third-Party Storage Protections “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. 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. Blocking third-party storage protects Brave users from the most common forms of tracking, but can also break sites. Since our first release, Brave has by default blocked all third-party application storage (e.g., cookies, localStorage, indexedDB). This post describes work done by Principal Engineer Brian Johnson, Senior Software Engineer Ivan Efremov, and Senior Privacy Researcher Peter Snyder.

Dom plus storage