Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: Storage Access API #560
Hi! John Wilander from WebKit here. We hope this can extend existing specifications rather than some whole new spec.
Storage Access API
Tl;dr: Browsers that block access to third-party cookies break authenticated embeds such as commenting widgets and subscribed video services.
In the context of cross-origin resource loads, cookies are popularly referred to as third-party cookies. In reality, these cookies are often the same as the first-party cookies so what we really mean with third-party cookies is access to first-party cookies in a third-party context.
However, certain services are intended to be embedded as third-party content and need access to first-party cookies for authentication. Examples are commenting widgets, video embeds, document embeds, and social media action widgets. These break if the third-party content has no access to its first-party cookies.
The same problem exists for other kinds of storage such as IndexedDB and LocalStorage, except they are not tied to the HTTP protocol and are typically not used for authentication purposes. From here on we will refer to cookies except when the distinction between cookies and other storage makes sense.
Tl;dr: A new API with which cross-origin iframes can request access to their first-party cookies when processing a user gesture such as a tap or a click. This allows third-party embeds to authenticate on user interaction.
We propose two new functions on the document:
hasStorageAccess() can be called at any time to check whether access is already granted and it doesn't require user interaction.
requestStorageAccess() should only be called on user interaction such as a tap or a click. It will check a set of rules and grant access if the rules are fulfilled. Access to first-party cookies in the given iframe can be assumed if the returned promise resolves. From that point, any sub resource load in the iframe will have first-party cookies sent and incoming cookies will be set in the first-party cookie jar.
Note that no other third-party resources on that webpage are affected by the storage access status of an individual iframe.
Algorithm for requestStorageAccess()
Storage access is granted for the life of the document and as long as the document's frame is attached to the DOM. This means:
WebKit's implementation of Storage Access API will be available in Safari Technology Preview soon and on by default. It only covers cookie access, i.e. no other storage mechanisms and the partitioning of them is affected by a call to requestStorageAccess() at this point.
As for specification location, a more logical fit might be https://github.com/whatwg/storage including
My main concern here is with prompting the user on behalf of a third-party. I'd really like us to move to a world where all UI prompts come from a place that matches the address bar. "I'm on example.com, why do I get a prompt from "elsewhere.example?" is real problematic and not something we should further enshrine.
I contemplated navigator but since 1) storage is only granted to this document and 2) it changes document.cookie, I felt document was a better fit.
A prompt may be phrased as having to do with both the third and first party — “Would you like to use payment.com under store.com?”
I'm not sure how to ask such a question in a way that isn't confusing, which is why I'd rather not ask it.
If this is solely about cookies and document-bound, https://github.com/whatwg/html is probably the best place, as that defines
(This also feels very similar to https://www.w3.org/TR/tracking-dnt/#exceptions which nobody ended up implementing as far as I know.)
If this is not meant to cover all storage, please don't name the API using "storage".
Personally, it seems to me this permission should probably apply to all storage since users don't really understand the difference between cookies and other storage.
It would be helpful to have an example prompt that seems understandable to users.
As I mention in the proposal, this is intended to cover multiple types of storage. WebKit's first implementation only covers cookies but that's a limitation on us.
We don't have an example prompt because our current implementation is prompt-less. However, we want browsers to have the option of prompting because there might be abuse of the API or the browser may want to ensure user consent before any third-party is allowed storage access.