Consider moving API to Navigator

[jackfrankland]

Proposal

In a similar way to how a Service Worker is registered to a limited scope, via Navigator:

navigator.serviceWorker.register(scriptUrl, { scope }); // scope defaults to same-origin requests of resources within same directory of scriptUrl

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:

element.onclick = (e) => {
  navigator.requestStorageAccess(); // scoped to e.target.ownerDocument
}

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:

• Storage access is given to HttpOnly cookies for network requests, which the document cannot access by definition.
• Service Worker support: a service worker can be registered and shared across iframes, and is able to act as a proxy for requests that these iframes make. I cannot see how the current spec will be able to support the service worker making a request with credentials, as it does not have access to the document.
• It's fairly trivial to read and write storage from an iframe that's on the same origin as an iframe whose document has been granted access. Or propagate the user action to trigger grants to all siblings, reducing the effectiveness of constraining it to a document.
• Non-iframe access requests: Having to embed an iframe can be less desirable then embedding onto the main document for a variety of reasons. I can see a future where requests for storage access are not made from iframes, but from DOM/Shadow DOM elements on the first party that the third party owns.
• I feel like several discussions within the other issues on this repo seem to support a widening of the scope.

For completeness:

navigator.hasStorageAccess(scope); // scope being document initially, or the flexibility to be something else, like third party origin

Thanks, would be really interested to hear any thoughts.

[johnwilander]

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:

1. It's the third-party asking for access, not the first-party.
2. The third-party needs to be in control of when and why it requests storage access. That can be achieved by restricting the API to a context that the third-party is in full control of. Allowing adtech.example to request storage access for social.example under news.example may lead to situations we don't want.
3. The browser probably wants to prompt the user like in Safari and Firefox do today. That prompt informs the user of the third-party website that's requesting storage access under which first-party website. This is picked up from the iframe context. An API that can be called from wherever needs to take the requesting party as parameter.
4. The iframe sandbox attribute allows for first-parties to embed third-parties while not allowing them to prompt their users for storage access. Something similar could of course be achieved through something like Permissions.
5. The intention for the API is for authenticated embeds. Embedded content that needs to authenticate the user. Arbitrary, invisible resource loads don't need to authenticate the user in that way. The scope can of course be widened as you propose, but the existing proposal and implementations are for authenticated embeds.

[othermaciej]

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.)

[jackfrankland]

Thanks a lot.

There are a few reasons for why iframes have to call this API:

1. 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: #17 (comment). 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.

[jackfrankland]

(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.

[hober]

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!