requestStorageAccessFor

[mreichhoff]

Hello TAG!

I'm requesting a TAG review of requestStorageAccessFor.

Enabled-by-default cross-site cookie access is in the process of being deprecated (or is already deprecated) by several major browsers. Multiple substitutes have been proposed, like the Storage Access API, the SameParty cookie attribute previously in the First-Party Sets proposal, and partitioned cookies in the CHIPS proposal.

However, the Storage Access API is primarily intended for authenticated embeds, a use case which entails <iframe> use, SameParty has been abandoned, and partitioned cookies (while preferred for most cases) aren't always applicable. This raises questions like:

• How can legacy content directly embedded in a document rely on cross-site cookies?
• How can top-level sites ensure their cross-site content can get the access it needs early enough in the page lifecycle to avoid user experience degradation?

The requestStorageAccessFor API is intended to solve these concerns, with a requirement of additional trust signals and security controls to ensure safety.

• Explainer¹ (minimally containing user needs and example code): https://github.com/privacycg/requestStorageAccessForOrigin/blob/main/README.md
• Specification URL: rendered, bikeshed source
• Tests: N/A, hopefully coming soon
• User research: N/A
• Security and Privacy self-review²: https://github.com/privacycg/requestStorageAccessForOrigin/blob/main/tag-security-questionnaire.md
• GitHub repo (if you prefer feedback filed there): https://github.com/privacycg/requestStorageAccessForOrigin
• Primary contacts (and their relationship to the specification):
  • Matt Reichhoff (@mreichhoff), Google, Editor
  • Johann Hofmann (@johannhof), Google, Editor
• Organization(s)/project(s) driving the specification: Google Chrome (Privacy Sandbox)
• Key pieces of existing multi-stakeholder review or discussion of this specification: See, for example, privacycg meeting minutes or comments on various issues.
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5122534152863744

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: We are looking to send an intent to ship in Chrome within the next few upcoming releases (M111-M113, much like the SAA spec review).
• The group where the work on this specification is currently being done: PrivacyCG.
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG (HTML/Fetch)
• Major unresolved issues with or opposition to this specification:

There are concerns about explicit embeddee opt-in without dependence on First-Party Sets, which should be addressed by:

• the requirement that embedded frames themselves invoke requestStorageAccess to gain access to cookies
• subresource requests must be CORS protected to have cookies attached (where the embeddee must be informed of the caller and then return the appropriate header to allow reading the response).

Prompt spam has also been discussed, with implementation-defined steps to prevent abuse, much like is done with the larger Storage Access API. Note that at least Safari remains concerned with the proposed mitigation, though we hope to continue to discuss it in PrivacyCG.

• This work is being funded by: Google Chrome

You should also know that the proposed functionality was implemented internally in both Safari and Firefox, but not web exposed. Instead, it was automatically applied on a case-by-case basis. This proposal intends to enable site authors to use such functionality while still maintaining sufficient guardrails to prevent abuse.

Much of the feedback on the Storage Access API review is likely to apply here, as well.

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback

[mreichhoff]

cc @johannhof @helenyc

[hadleybeeman]

Hi all! We have done an initial review, and have a few questions to begin the conversation:

1. What use cases are you explicitly designing for? Can you elaborate on "legacy use cases"? Why is just using iframes and the Storage Access API insufficient?
2. What abuse scenarios have you considered, and what are the mitigations for them? The S&P questionnaire says, "While this functionality comes with a risk of abuse by third parties for tracking purposes, it is an explicit goal of the API and a key to its design to not undermine the gains of cross-site cookie deprecation." -- how does that work?
3. We see "Permission grants for storage access are double-keyed" in the S&P questionnaire, but this isn't in the spec - is there something to add here?
4. Why do images need access to storage? (The explainer alludes to uses for cookies, images and scripts).

We'd be grateful for your thoughts. Thanks!

[johannhof]

Hi Hadley, thank you for taking a look and thanks for inviting me on your recent call to explain some of this in detail. I added summarized answers below (credit to @mreichhoff who wrote much of this up).

What use cases are you explicitly designing for? Can you elaborate on "legacy use cases"? Why is just using iframes and the Storage Access API insufficient?

Some example use cases are:

• SSO/login hosted on another domain, where the top-level document wants to be able to load authenticated resources such as profile images, without using an iframe.
• A top-level document embedding an authenticated resource, for example, google docs, where the top-level document would like to ensure that the content is loaded or display fallback content, rather than requiring another interaction with the embedded document.
• See also the cross-domain quirk scenarios implemented in Safari and Firefox (e.g., 1, 2), most of which involve cross-site authentication and are invoking an internal version of requestStorageAccessForOrigin.

In general, requestStorageAccess’ requirement of iframe use plus interaction with the iframe removes some autonomy of the top-level document to control what is loaded. This API is intended to improve that situation, and also act as a partial replacement for the prior page-level functionality provided by requestStorageAccess.

What abuse scenarios have you considered, and what are the mitigations for them? The S&P questionnaire says, "While this functionality comes with a risk of abuse by third parties for tracking purposes, it is an explicit goal of the API and a key to its design to not undermine the gains of cross-site cookie deprecation." -- how does that work?

As we discussed, like requestStorageAccess, this API requires developers to request user permission before access to cross-site cookies can be granted. This is the primary gate against abuse in the form of cross-site tracking.

However, with user prompts comes another large abuse vector. Sites may try to trick or annoy users into granting permission, and even just seeing too many well-intentioned prompts may cause harm on the user and the overall ecosystem.

There are a few prompt abuse scenarios and mitigations that we have been able to incorporate in the spec:

• Prompts from pages the user has not interacted with, leading to confusion: user interaction is required to show a prompt.
• Repeated prompts, where a request is denied and re-requested: user interaction is consumed on denial to prevent this.
• Retaliation against users who deny a prompt: the denied state is not exposed on a call to permissions.query to prevent this.

This is a baseline defense, but for SAA, browsers have chosen to add additional implementation-defined steps to reduce user annoyance (heuristic auto-grants in Firefox, 1P user interaction requirement in Safari, FPS auto-grants in Chrome).

We’re confident that similar measures can be employed in the case of requestStorageAccessForOrigin. It should be noted that other browsers see a new concern with prompts from this API that we haven’t been able to fully address yet: Requests for an unrelated domain (e.g., evil.example requesting puppies.example, harming the reputation of puppies.example). Although the spec mentions making it clear who is requesting what in the prompt, this may not be enough. Chrome currently plans to use First-Party Sets to prevent this type of abuse. Other browsers could consider numeric limits or their own allowlists. Numeric limits, where requests for a given origin are allowed on up to limit top-level sites, could potentially be standardized, but such conversations haven’t yet taken place.

The Chrome team is working with other browsers on APIs that would expose more relevant user prompts on the web for a variety of use cases in the long term, such as FedCM. While we don’t think that those are quite ready yet, the flexibility of the Storage Access API (including this proposal) makes me hopeful that we can achieve a graceful developer transition path away from potentially confusing user experiences in the long run.

Finally it’s worth mentioning security as an aspect of abuse. As I had mentioned, we did an extensive analysis of the security posture of the Storage Access API (including this proposal) and came out with a few recommendations that are being followed here. Specifically, security requirements include explicit invocation of requestStorageAccess for frames to have access; CORS protection for subresource requests from the top-level site; disallowing access on subresource requests from other frames; and explicit requirement of SameSite=None cookies.

We see "Permission grants for storage access are double-keyed" in the S&P questionnaire, but this isn't in the spec - is there something to add here?

That is a great question, it wasn’t clear enough in the spec! A note was added in a recent commit to address this concern. The idea is that the permission descriptor used by the API has a field called requestedOrigin, and the permission key is the top-level site. The permission store entry is then effectively double-keyed on {top-level site, embedded origin}, since checks would be against the permission key plus the descriptor.

Why do images need access to storage? (The explainer alludes to uses for cookies, images and scripts).

Like for requestStorageAccess, “storage” in this case currently refers to cookies only. A use case where an image request would desire SameSite=None cookies could be loading a profile picture from an SSO domain. Besides that, as we discussed in our call, images or “pixels” are often just a convenient way of setting HTTP (only) cookies in cross-site contexts. These pixels are currently used both for user-facing functionality as well as cross-site tracking. This API wants to ensure we preserve the user-benefiting usage while making the tracking parts ~impossible.

[torgo]

Hi @annevk @bvandersloot-mozilla as co-editors with @johannhof of StorageAccess API could either/both of you let us know your perspective on this proposal? We understand that requestStorageAccessForOrigin was a departure from StorageAccessAPI. Is this direction likely to gain your support?

[annevk]

I outlined my (and WebKit's) concerns with this feature in WebKit/standards-positions#125 and privacycg/storage-access#107. If you have two websites A and B. A can ask the user if its requests to B can include the user's cookies for B. All without B's involvement. That's not good for security. It's potentially also bad for B's reputation.

[johannhof]

Thanks Anne,

That's not good for security.

I'm not sure if you are up to date with the changes we made on the proposal to both require CORS on subresource requests as well as require rSA calls for iframes to opt into this. I don't think there's a significant risk to B's security here.

[annevk]

@johannhof CORS doesn't make it secure. (Unless you have made changes to CORS such that you require a preflight before sending a request with credentials, but I didn't see anything of the sort.)

[johannhof]

Not sure if it's worth having the full discussion here but CORS protects against cross-site leaks. CSRF could also be done through top-level navigation? Anything else you're concerned about? Would be nice to capture it in the repo.

[plinss]

I have concerns about the SSO use cases. The goals listed are explicit features of FedCM. I understand that this feature could ship faster than FedCM but adding something new that will need to be maintained and exposes additional complexity, security, and privacy risk just for interim support is generally not a good path forward.

Furthermore, while I understand that some of the cross-site behaviors can be useful to some users, they can get in the way of others. For example, if a user wants to maintain different experiences on different TLDs, for example the same site in different countries, how would they do that?

[johannhof]

Hi Peter, thanks for your questions.

I have concerns about the SSO use cases. The goals listed are explicit features of FedCM. I understand that this feature could ship faster than FedCM but adding something new that will need to be maintained and exposes additional complexity, security, and privacy risk just for interim support is generally not a good path forward.

Can you be more specific as to which goals are explicit features of FedCM? I'm not sure I really understand. I think comparing this to FedCM isn't quite apples-to-apples and really depends on the context and use cases we're talking about. It should be noted that FedCM in its current form (which already shipped) doesn't really aim to solve SSO, but federated/social login (though, naturally, we think that the FedCM user experience is a promising model for future attempts at generalizing on more identity flows such as SSO).

Furthermore, while I understand that some of the cross-site behaviors can be useful to some users, they can get in the way of others. For example, if a user wants to maintain different experiences on different TLDs, for example the same site in different countries, how would they do that?

This is why this proposal exists, in a way. Post cross-site cookies, browser vendors make very different choices about how they may derive permission for sites to share a common user identity. Some browser vendors always prompt users in these situations, e.g. Safari. Firefox and Edge would prompt sometimes but usually auto-grant via their 5-domain heuristic. At Chrome we're still working on our prompt design but we hope to absorb a lot of these prompts into known cross-site user flows that are registered via FPS. This API is compatible with all these choices and other future UX explorations.

So, this question ultimately depends on which browser you're using. In Chrome, the user might disable FPS in their cookie settings, for example. It should be noted that sites may be adding this integration for good reasons and it's not clear whether most users generally have enough technical understanding to know why they would choose to isolate two different top-level sites.

[johannhof]

Hi @torgo, apologies, we haven't yet made progress on those but they have definitely not dropped off our radar. We still intend to address (or at the very least better position ourselves on) the reputation/security concerns brought up with prompting rSAFor.

[hadleybeeman]

Thanks @johannhof, we'll keep this open for now. For our TAG processes, we are keen to not let issues stand open and inactive for too long, so we'd be grateful if you could give us a quick update within 3-4 weeks at the most.

[johannhof]

Thanks for the heads up @hadleybeeman, just to avoid misunderstandings 3 - 4 weeks doesn't really match our current planning and capabilities to follow up here, as we want to make sure we can come up with a constructive proposal that goes beyond the FPS-based opt-in that Chrome offers right now (which doesn't exhibit these concerns but doesn't have cross-browser support).

I understand that it's hard for you to review this with our response to these issues outstanding, so we're happy to adjust to your preferred way of handling blocked requests (e.g. ask for review again in a few months).

[torgo]

Hi @johannhof given that, we're going to set the milestone of early September to check back on this. In the mean time please ping if there's been any update we need to be aware of.

[martinthomson]

Hey @johannhof, it's been a little while. What is the status of this request? (I know that I should be tracking this more closely as Privacy CG chair, but the churn got a bit ahead of me.) We're considering closing this. Let us know if we shouldn't.

[hadleybeeman]

Hi @johannhof. As per your previous posts, it sounds like you're not in a position to progress this right now. We're going to close the issue, so it doesn't keep coming up in our reviews. Feel free to come back to it or open a new issue when you're ready.

[johannhof]

Ah, apologies for missing this. That seems fair. We're still working through some of the mentioned challenges for a potential prompting version of this, there's a lot of complexity to disentangle. We'll come to this group with the results of our work, which may not be on this thread but via other API proposals such as storage access headers.