Closed jackfrankland closed 4 years ago
The document was picked because it matches the narrowest scope of what the API manages, namely document.cookie. The fact that also network requests from the iframe carry cookies doesn't change the narrowest scope. This isn't set in stone but it was the reasoning, especially since WebKit's implementation only changes document.cookie in terms of script-accessible storage/state.
There are a few reasons for why iframes have to call this API:
The navigator
object is not narrower in scope than document
. navigator
is usually where things go that have a relatively global nature, such as info or registrations that pertain to all frames/windows.
(Even if navigator
was slightly better, it's disruptive to change the API at this time, now that multiple browsers have shipped it, so we should only do so if there is a pretty good reason.)
Thanks a lot.
There are a few reasons for why iframes have to call this API:
- It's the third-party asking for access, not the first-party.
Sorry, I should have been clearer. It would still be the third party iframe requesting access for its document. In my previous example, scope is implicit, but maybe this version highlights it better:
element.onclick = (e) => {
navigator.requestStorageAccess({ scope: document }); // exception is thrown if document !== e.target.ownerDocument
}
navigator.hasStorageAccess(document); // exception is thrown if document cannot be referenced, as is the case from a different origin
In this way, this is not a proposal to change the behaviour of the existing spec.
The navigator object is not narrower in scope than document. navigator is usually where things go that have a relatively global nature, such as info or registrations that pertain to all frames/windows.
If the behaviour of the spec as written were to never change, and the scope is always tied to the document and its lifecycle, then considering to move this to the more global navigator would be pointless I agree. The catalyst for this proposal was mainly this: https://github.com/privacycg/storage-access/issues/17#issuecomment-608742116. If, in a future event, the spec of the scope does increase beyond the lifecycle of a document, or different browsers wanted to define the scope differently (as is the current case for Firefox I believe), registering that access on the navigator instead (but still tied to a scope like service worker registrations) may make sense.
(Even if navigator was slightly better, it's disruptive to change the API at this time, now that multiple browsers have shipped it, so we should only do so if there is a pretty good reason.)
Fully appreciate that this is extremely late in the game, I'm just putting it out there 🙂. This is about providing flexibility for possible forward-compatibility at a stage that might be less disruptive now.
Given the conversation here and on this week's call, I'm going to close this issue. If anyone would like it re-opened, let @johnwilander or one of the @privacycg/chairs know. Thanks!
Proposal
In a similar way to how a Service Worker is registered to a limited scope, via Navigator:
I'd like to put forward that storage access should be granted via Navigator too, scoped initially to the ownerDocument of the HTML Element that received a user action:
Why?
Perhaps the biggest reason is flexibility for a future spec. I believe it could match the current behaviour by limiting the scope to the ownerDocument. However, if ever the spec were to change, or if different browsers wished to implement it differently... by having storage access granted to a double-keyed origin, to all iframes on the origin, or across page loads for instance, having it on the navigator allows for this widening of scope in perhaps a more comprehensible way.
Further arguments:
For completeness:
Thanks, would be really interested to hear any thoughts.