Scope of grant in terms of domains

[annevk]

I was reading https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy#Scope_of_storage_access yesterday and noticed that it does not use the registrable domain as the key.

In particular, if tracker.example is granted storage access on foo.example.com, and the user navigates to example.com that also embeds tracker.example, tracker.example does not have storage access. If the user then navigates to bar.foo.example.com which also embeds tracker.example, tracker.example does have storage access.

I suspect we are flexible with regards to this, but I thought I'd bring it up to see what people think.

[othermaciej]

I'm not sure what we use in WebKit. It's likely reasonable to use the registrable domain (i.e. eTLD+1) as the scope of permission grant. Or perhaps it should be schemeful site?

[Brandr0id]

Given other parts of the web are origin based would it make sense to even scope these further to just origin? That might also simplify other aspects such as FeaturePolicy integration and avoid creating a unique allow list scope just for this API.

[johannhof]

(Going through old issues to figure out if we can close them)

Firefox is currently origin-scoping both our heuristics and regular storage access grants through the Storage Access API. That means that https://tracker.example will have storage access only on https://foo.example.com, not https://example.com (and https://foo.tracker.example will also not have access).

However, the spec currently says "site" (scheme + eTLD+1), if I read it correctly. https://privacycg.github.io/storage-access/#partitioned-storage-key

@Brandr0id @johnwilander I talked to @annevk and we'd like to update the spec to scope by origin instead, mostly because this matches the scope of other permissions on the web and thus as Brandon mentioned there are probably fewer edge cases to worry about. With that said our top priority on this is interop so if y'all have strong opinions we'd be interested in hearing them. If not I'll make this change :)

Thanks!

[johnwilander]

There’s compatibility risk with narrowing the scope. We’d have to do a large QA pass with focus on logins, and a developer communication effort. Safari has shipped the API with site-based scope for more than three years and with full third-party cookie blocking by default, the Storage Access API is something developers have to rely heavily on.

We should also cover the popup compatibility measure which today relies on the same scope.

[johannhof]

FYI we've noticed some real world cases where origin-scope breaks things and requires unnecessary hacks to fix reasonable use cases (such as history.com and play.history.com) and are now leaning towards aligning with Safari, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1731739

If we have some agreement on this then we should fix up the remaining site-vs.-origin issues in the spec and close the issue.

[hpsin]

From a product-building perspective, I'm strongly in favor of eTLD+1 being the basis for the permission, for both top- and bottom-frame (although can see room for compromise on bottom-frame, typically the IDP). It allows us to build products split by subdomain instead of path (app1.example.com instead of example.com/app1) which makes for a cleaner experience, more secure and reliable apps, and better UX in the browser bar (paths being hidden in many browsers today).

If Storage Access were changed to be by origin, we'd be incentivized to reduce our security posture and move to path-based application architectures. It's common to get cross-app user hints by dropping a cookie on a shared parent domain. Origin-based storage access would result in moving from app1.example.com to app2.example.com and the site effectively signing you out, in federated auth scenarios.

[johannhof]

We discussed this again at Mozilla and ended up with a preference for site (scheme + eTLD+1) being used for keying the top-level, and origin for keying the frame.

The reasoning for this preference is outlined by @annevk in https://bugzilla.mozilla.org/show_bug.cgi?id=1731739#c1, in short, we fear that this will result in a storage request from one origin affecting storage in another origin embedded on the same page. This would, to a certain extent, violate the same-origin policy and the permission model of the web as mentioned before. We have not traditionally asked (and given) permission for eTLD+1 scopes, and rather for origins.

I think that to change this, we would need to update the partitioned storage key to a tuple of (top-level site, embedded origin).

@johnwilander @Brandr0id would you support this change? I suspect that keeping the top-level at site scope is the only thing that really matters for compatibility, and we don't want to break that as it's indeed more useful. I doubt that there are consumers that rely on getting access in separate cross-site iframes on the same page.

[bvandersloot-mozilla]

Following up on this, Firefox is trying out using the storage access permission as Site-scoped for the top-level page starting on Firefox 97.

[johnwilander]

Johann and I discussed this in our call today. There are at least three arguments for granting storage access to the site and not just the origin:

• The cross-site iframe will get read+write access to site-scoped storage in the form of cookies anyway.
• There is no privacy benefit to restricting it to origin so we might as well go for the highest chance of usefulness and compatibility.
• User messaging in any kind of prompt still needs to call out the site because of access to site-wide cookies.

[annevk]

Those are solid as far as the user prompt is concerned, but I still think it having side effects across the origin boundary is rather bad. Perhaps the other origins could still be required to call document.requestStorageAccess() before their cookies end up being enabled/unpartitioned (assuming storage will stay partitioned as discussed elsewhere).

[johannhof]

As discussed in #113 on Chrome side we would prefer this to be restricted to (top-level site, embedded origin) as in Firefox, to protect from leaking information such as credentialed endpoints or SAA usage across (same-site) origins, and to prevent attacks on privileged subdomains of embedded requestors (outlined in more detail in that issue).

[lghall]

For Google Workspace, we have several use cases where an embed redirects to a same-site page. For example, docs.google.com may redirect to accounts.google.com to access an origin scoped login cookie, and then redirect back to docs.google.com.

Restricting storage access to same-origin (instead of same-site) would cause these flows to break in an embedded context, or require repeat rSA calls per origin.