requestStorageAccessFor: Page-level cross-site cookie grant API

[mreichhoff]

As requestStorageAccess in the Storage Access API is being switched to be frame-only, the former page-level behavior is now a gap. The ability to grant access for subresources in addition to iframes is likely important to preserve.

This proposal is to consider requestStorageAccessFor (name very much TBD) as a separate work item. It would work similarly to the old page-level requestStorageAccess behavior, but access would be requested by the top-level site on behalf of embedded origins. This both unlocks the old page-level behavior and ensures that the top-level site, which controls subresource loading, has control. This would require elevated trust to prevent abuse and potential security issues.

Note that requestStorageAccessFor was previously proposed as part of the Storage Access API, but the aforementioned frame-only behavior means that the new API should probably be a separate entity.

More context can be found in the old proposal under SAA or in the explainer.

@bvandersloot-mozilla @johannhof

[annevk]

I think it's important to highlight privacycg/storage-access#107 (comment) here. This proposal seems to depend on First-Party Sets for its end user story and First-Party Sets doesn't have agreement.

[johannhof]

No, this proposal doesn't depend on FPS for its end user story.

FPS is one possible mechanism for the browser to ensure relevance and user understanding of prompts (which are allowed by the proposal) or auto-grants. Apple had previously stated (on the mailing list and in meetings) that they see the potential for FPS to act as metadata for a prompting mechanism like SAA, instead of being a privacy boundary. Enabling this capability is one idea that we're trying to follow, and the FPS proposal has changed significantly as the result of that direction, but, again, to be very clear, this API does not depend on FPS.

rSAFor is a technical utility for requesting non-iframed cross-site cookie access once some trust level has been reached. The API goes to great lengths to ensure security requirements even in the absence of any other relation between the two sites, which should be further evidence that this isn't tied to FPS.

Both WebKit and Gecko have already found the need to implement this API internally to fix use cases that could not be solved with SAA alone in their quirks (still showing user prompts, to be clear). We see the utility in this API but do not want to be the arbiter of it through Chromium bugs.

I think both specifying this API as a trust-provider agnostic mechanism for cookie access for interop as well as discussing potential sources of trust and user understanding/consent are in scope for this group.

[annevk]

I'm sorry, but other than First-Party Sets I don't really see a realistic proposal there. And also, say one UA did FPS and another did .well-known that would result in a compat hellscape.

[johannhof]

I'm not sure it's fair calling a certain level of implementation-defined behavior "compat hellscape" given that browser-defined grant requirements have been a main feature of SAA (and WebKit and Gecko have greatly diverged in their requirements) for years.

[erik-anderson]

We plan to discuss this issue on the December 8th call.

[jsnajdr]

Hello from Automattic, the makers of the WordPress.com hosting service 👋 Wanted to say we are happy that something like requestStorageAccessFor is being considered, as it solves one our use case where we need third party cookie access: a customer website hosted with us, running on an example.com domain, would like to show some authenticated embed iframes from wordpress.com, the domain where the hosting administration UI runs. These embeds let you perform some admin tasks, directly on your website's example.com domain.

So far, the Chrome team considered requestStorageAccess support only between sites inside a First Party Sets, but our use case, the relationship between a site and its hosting provider, is not eligible for FPS.

What is encouraging about requestStorageAccessFor is the fact that it works even for non-FPS sites, and that the top-level site (example.com) can have full control over loading the embed iframes and requesting access for them.

[johannhof]

Hi @jsnajdr, I really appreciate your enthusiasm, though I'm under the impression that maybe regular requestStorageAccess might be a better fit for your use case. You mention that you're using authenticated embeds, which would theoretically work with rSAFor, but are really the primary use case for rSA. More importantly, I want to provide some nuance to the following statement:

What is encouraging about requestStorageAccessFor is the fact that it works even for non-FPS sites

While, yes, rSAFor can work without FPS, Chrome has so far only announced the intent to support both rSA and rSAFor through auto-granting based on FPS. We're still evaluating the possibility of supporting prompt-based authenticated embeds and hopefully will be able to share our thoughts on this in more detail soon.

With that said, incubation means that we still want to work on figuring out (and potentially change) these details, and especially if there are things that rSA doesn't do well for you for then it makes sense to discuss them in the context of rSAFor.