This document is intended as a starting point for engaging the community and standards bodies in developing collaborative solutions fit for standardization. As the solutions to problems described in this document progress along the standards-track, we will retain this document as an archive and use this section to keep the community up-to-date with the most current standards venue and content location of future work and discussions.
As privacy is becoming increasingly important to users, requests for stricter browser defaults and user opt-in settings like blocking all third-party storage access are increasingly common. While these settings help improve privacy and block unwanted access by unknown or untrusted parties, they can have unwanted side effects such as blocking access to content the user may want to view (e.g. social media and embedded media content).
Users shouldn't have to compromise between privacy protections and enabling sites' embedded content to function correctly. The Storage Access API is a JavaScript API that allows fine-grained control of storage access permissions when access would otherwise be denied by the browser's current settings. Sites with meaningful scenarios that depend on loading third-party resources will be able to leverage the API to allow the user to explicitly choose, on an as-needed basis, when to allow more permissive access.
Current implementations: Firefox, Safari
MDN: https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API
WHATWG discussions:
Safari overview: https://webkit.org/blog/8124/introducing-storage-access-api/
If a website loads third-party content that requires access to its first-party storage, and the current browser settings would block that access, the Storage Access API provides a mechanism for the third-party content to request access. A document can call one of two new APIs to check for access or request access respectively.
API usage (https://webkit.org/blog/8124/introducing-storage-access-api/):
partial interface Document {
Promise<bool> hasStorageAccess();
Promise<void> requestStorageAccess();
};
var promise = document.hasStorageAccess();
promise.then(
function (hasAccess) {
// Boolean hasAccess says whether the document has access or not.
},
function (reason) {
// Promise was rejected for some reason.
}
);
<script>
function makeRequestWithUserGesture() {
var promise = document.requestStorageAccess();
promise.then(
function () {
// Storage access was granted.
},
function () {
// Storage access was denied.
}
);
}
</script>
<button onclick="makeRequestWithUserGesture()">Play video</button>
This greater level of control over storage access permissions allows for existing Chromium privacy controls such as third-party cookie blocking to be hooked up to this API in order to allow for broader adoption of more privacy-centric settings while also providing potentially broken scenarios-- such as federated authentication and user-desired third-party content-- a mechanism to restore functionality in a highly-targeted manner. This API also provides a valuable abstraction at the platform layer for other Chromium implementors to integrate additional privacy controls while providing a unified mechanism to control storage access permissions.
The API would address storage access for all forms of storage that may currently be blocked by existing policies and browser settings such as third-party cookies. This includes traditional HTTP cookies as well as other storage apis such as indexedDB and localStorage.
Third-party cookie settings are set to block.
A root document, https://example.site, embeds an iframe from https://socialmedia.site that requires access to storage to authenticate.
There are two existing similar implementations with minor differences (Firefox, and Safari), documented at https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API#Safari_implementation_differences. The intent is to follow common implementation patterns between the two implementations. Where differences exist or more favorable Chromium mechanisms exist (e.g. site-engagement scores) a preference towards being minimally invasive for the user (e.g. few, or no prompts) and maintaining functional web experiences will be taken. There are a number of considerations discussed by various Chromium implementors and browser vendors in the WHATWG discussion (https://github.com/whatwg/html/issues/3338). The intent is to take these concerns, feedback, and considerations into account when making design decisions in areas that differ between implementations.