Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scope of grant in terms of domains #39

Closed
annevk opened this issue May 21, 2020 · 12 comments
Closed

Scope of grant in terms of domains #39

annevk opened this issue May 21, 2020 · 12 comments
Assignees
Labels
resolve before graduation These issues need to be resolved before the spec graduates from the CG

Comments

@annevk
Copy link
Collaborator

annevk commented May 21, 2020

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
Copy link

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
Copy link
Member

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.

@hober hober assigned hober and johnwilander and unassigned hober Jun 2, 2020
@johannhof
Copy link
Member

(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
Copy link
Collaborator

johnwilander commented May 18, 2021

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
Copy link
Member

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
Copy link

hpsin commented Sep 21, 2021

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
Copy link
Member

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
Copy link
Collaborator

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.

@johannhof johannhof added needs edit This issue is waiting on a PR to be written. and removed needs edit This issue is waiting on a PR to be written. labels Mar 22, 2022
@johannhof johannhof self-assigned this Mar 22, 2022
@johannhof johannhof added the resolve before graduation These issues need to be resolved before the spec graduates from the CG label Mar 22, 2022
@johnwilander
Copy link
Collaborator

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
Copy link
Collaborator Author

annevk commented Mar 23, 2022

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
Copy link
Member

johannhof commented Sep 27, 2022

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

johannhof added a commit to johannhof/storage-access that referenced this issue Oct 11, 2022
)

This is what Firefox ships and Chrome intends to ship, so it makes sense
to align the spec. Some of our rationale for why we prefer origin as the
embedded choice is outlined in privacycg#113.

These security concerns don't apply to top-level site and indeed we've
seen compatibility cases in Firefox that justify keeping top-level site.
@lghall
Copy link

lghall commented Oct 24, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolve before graduation These issues need to be resolved before the spec graduates from the CG
Projects
None yet
Development

No branches or pull requests

9 participants