requestStorageAccessFor

[mreichhoff]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: requestStorageAccessFor
• Specification or proposal URL: https://github.com/privacycg/requestStorageAccessForOrigin
• Caniuse.com URL (optional): N/A
• Bugzilla URL (optional): N/A
• Mozillians who can provide input (optional): @bvandersloot-mozilla @martinthomson

Other information

The proposed requestStorageAccessFor API builds on the Storage Access API to allow non-iframe use. This affords more control for the top-level site as cross-site cookies continue to be phased out; it also allows partial restoration of the page-level behavior of requestStorageAccess, which will be retired in favor of a per-frame model. Like requestStorageAccess, implementation-defined behavior allows different user agents flexibility to apply policies as they see fit, though the hope is that divergence will be minimized.

Note that this proposal is similar to an internal shim API implemented by both Safari and Firefox.

Prior discussions have surfaced the need for embeddee opt-in, which the API attempts to ensure via requiring invocation of requestStorageAccess for frame-level access (the same way a prior requestStorageAccess grant is proposed to waive the user interaction requirement in the per-frame requestStorageAccess model); requiring CORS on subresource requests to the embeddee from the top-level site in order for cookies to be included; and applying only to explicitly SameSite=None cookies.

[bvandersloot-mozilla]

I have a few concerns with this specification.

The first concern centers on Step 6 of the draft algorithm, “Check for embeddee opt-in,” with the context of Anne’s comment on the proposal issue and our discussion in the PrivacyCG meeting on 6 Dec 2022. Chrome plans to use First Party Sets for this step, which I think we agree shouldn’t be a necessary condition for the spec. So one open question here is “what is the alternative to FPS that is acceptable to be used by other implementers in parallel with Chrome’s use?”

I see 3 purposes to Step 6:

1. Prevent reputational harm to sites being falsely used as an authenticated embedded resource.
2. Prevent abuse by embedded scripts.
3. Allow storage access without direct user-interaction with the embedded site.

If we were to accept that First Party Sets is workable (e.g. ignoring open questions of governance), these concerns may be addressed. However, Mozilla does not believe that FPS is workable and I don’t see an alternative that addresses all three points. The two suggestions that seem most practical are an independent .well-known file and a heuristic allowing a small constant number of requests. Webcompat and developer-experience concerns aside, these address purpose 1 and some but not all aspects of purpose 2 respectively. This leaves cases of abuse and does not solve purpose 3; one such case of abuse is a site that wants no permission requests but embeds third-party scripts has no control. Returning to my motivating question “what is the alternative to FPS…”, I see no answer, which means this spec is still tied to FPS.

The second concern I have relates to my question in our discussion in the PrivacyCG meeting on 6 Dec 2022. When the Storage Access API returned to a per-frame scope, this deprecated cross-site cookies for requests initiated in a top-level document. This provides an improvement in abstraction and security and seems to be a consensus desired end-state. Given that, it is unclear to me based on current discussion that this is worth the ergonomic benefit to developers.

Finally, it is worth noting that while Safari and Firefox both deploy a privileged requestStorageAccessFor function to fix compatibility issues, there are two reasons to believe it best to not enshrine this as a publicly available function. First, in Firefox’s case we use it as a lightweight method to fix breakage without for sites that focus their development on functionality within a single browser. Second, all of Mozilla’s uses (and Apple’s uses, I believe) of the privileged version are to fix breakage that is in federated authentication flows that the Federated Credential Management API is aiming to address.

[mreichhoff]

Thanks for the feedback!

I think it’s important to note that the explainer draft spec you mentioned isn’t reflective of the latest spec as it stands at: https://privacycg.github.io/requestStorageAccessForOrigin/.

For the 3 concerns you mentioned:

Prevent reputational harm to sites being falsely used as an authenticated embedded resource.

We feel this is addressed by:

• Limiting the access for rSAFor to subresource requests from the top-level document that are CORS-enabled, such that the embeddee must opt-in via the normal CORS response headers.
• And also requiring a requestStorageAccess call in the iframe for frame-level access, where the rSAFor call merely simplifies the ergonomics by removing the user interaction requirement on the iframe, but does not itself grant access.

Note that the draft steps in the explainer didn’t reflect this yet, which I’ve opened a PR to correct. Regardless, the spec itself is the authoritative version, not the explainer.

Prevent abuse by embedded scripts.

I don’t think this depends on FPS: as you mention, a simple count-based limit seems workable here, and note that an embedded script could already do things like embed an iframe and make it large enough to get a click, which opens requestStorageAccess abuse as well.

Allow storage access without direct user-interaction with the embedded site.

I do note that this is part of the rationale of having this API in the first place. I don’t think this is a concern about FPS, really. I think there are cases where top-level sites know what access is needed, and allowing a measure of control over it (while protecting embeddees), seems reasonable.

Regarding the per-frame scope concern, I feel it is addressed with the frame-level rSA invocation requirement and the CORS requirement for subresources. The former, in particular, greatly reduced the actual access granted by rSAFor.

I also acknowledge the Federated Credential Management concern, but my understanding is that it is not ready to replace such access at this time, and will not be anytime soon, so I don’t think depending on it is the right call.

[bvandersloot-mozilla]

Regardless, the spec itself is the authoritative version, not the explainer.

Ah, thank you!

We feel this is addressed by:

• Limiting the access for rSAFor to subresource requests from the top-level document that are CORS-enabled, such that the embeddee must opt-in via the normal CORS response headers.
• And also requiring a requestStorageAccess call in the iframe for frame-level access, where the rSAFor call merely simplifies the ergonomics by removing the user interaction requirement on the iframe, but does not itself grant access.

But inducing a storage-access permission dialog can be a reputational harm to the embedee-to-be, and is much more visible than the actual use of cross-site cookies. These protections are targeted to the use of cross-site cookies, not the request reaching the permission request stage.

 I do note that this is part of the rationale of having this API in the first place. I don’t think this is a concern about FPS, really. I think there are cases where top-level sites know what access is needed, and allowing a measure of control over it (while protecting embeddees), seems reasonable.

Understood- this is a core feature of the spec. I think we need to consider internally whether this is a positive or negative feature.

Regarding the per-frame scope concern, I feel it is addressed with the frame-level rSA invocation requirement and the CORS requirement for subresources. The former, in particular, greatly reduced the actual access granted by rSAFor.

These may resolve security concerns (I haven't given it enough thought yet), but there still remain the increased abstraction and moving in the opposite direction of what seems to be a consensus desired end-state.

I also acknowledge the Federated Credential Management concern, but my understanding is that it is not ready to replace such access at this time, and will not be anytime soon, so I don’t think depending on it is the right call.

According to the privacy sandbox timeline it should be set for general availability in Q3. Is this not up to date? Also, I thought a version of it has shipped in Chrome 108 and is being used by some sites already. Please correct me if I'm wrong on this.

[johannhof]

Hey Ben,

moving in the opposite direction of what seems to be a consensus desired end-state.

Can you elaborate more on this desired end-state and what it is in your view? Happy to chat in person (and report back here) if it's easier. I may be misunderstanding, but I think we should address some questions about bigger picture plans and motivations, also in terms of how this relates to FedCM (in my view they can and need to support one another).

[bvandersloot-mozilla]

Can you elaborate more on this desired end-state and what it is in your view?

A desired eventual state in my view is one in which we have a high bar of user friction that is implementation-independent for storage access grants and also have use-case driven APIs that provide cross-site functionality where they are beneficial. I admit that "end-state" is probably a misnomer for any living standard, however this is a good place to keep our eyes toward.

[...] I think we should address some questions about bigger picture plans and motivations, also in terms of how this relates to FedCM (in my view they can and need to support one another).

That sounds like a good idea to make sure we stay on the same page. Although @martinthomson may be the one you have to talk to based on my leave schedule.