Re: [w3ctag/design-reviews] requestStorageAccessForOrigin (Issue #808)

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 as an authenticated user 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](https://github.com/WebKit/WebKit/blob/fa68fec45f7ce4091b510ddef3e2a4e6fd35ad8c/Source/WebCore/page/Quirks.cpp#L1144) and Firefox (e.g., [1](https://phabricator.services.mozilla.com/D124493), [2](https://phabricator.services.mozilla.com/D131643)), 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](https://github.com/privacycg/storage-access/issues/3) 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](https://github.com/privacycg/requestStorageAccessForOrigin/blob/618b92776d1b581a2131327ebd3a620cb6522715/index.bs#L125) is required to show a prompt.
- Repeated prompts, where a request is denied and re-requested: user interaction is [consumed on denial](https://github.com/privacycg/requestStorageAccessForOrigin/blob/618b92776d1b581a2131327ebd3a620cb6522715/index.bs#L135) to prevent this.
- Retaliation against users who deny a prompt: the denied state is [not exposed](https://github.com/privacycg/requestStorageAccessForOrigin/blob/618b92776d1b581a2131327ebd3a620cb6522715/index.bs#L179) 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](https://github.com/privacycg/requestStorageAccessForOrigin/blob/618b92776d1b581a2131327ebd3a620cb6522715/index.bs#L254) 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](https://docs.google.com/document/d/1AsrETl-7XvnZNbG81Zy9BcZfKbqACQYBSrjM3VsIpjY/edit#heading=h.vb3ujl8dnk4q) (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](https://github.com/privacycg/requestStorageAccessForOrigin/commit/618b92776d1b581a2131327ebd3a620cb6522715) 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](https://www.w3.org/TR/permissions/#dfn-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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/808#issuecomment-1439861601

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/808/1439861601@github.com>