requestStorageAccessFor

[mreichhoff]

Request for position on an emerging web specification

• WebKittens who can provide input: @annevk @johnwilander

Information about the specification

• Title: requestStorageAccessFor
• GitHub repository: https://github.com/privacycg/requestStorageAccessForOrigin

Design reviews and vendor positions

• TAG Design Review: requestStorageAccessFor w3ctag/design-reviews#808
• Mozilla standards-positions issue: requestStorageAccessFor mozilla/standards-positions#736

Anything else we need to know

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.

[annevk]

For context, prior discussion about this API took place in privacycg/storage-access#107. It sounds like it has had a few changes.

However, I think my fundamental concern still stands.

Assume a top-level A that may or may not fetch a CORS script from B after a successful requestStorageAccessForOrigin() call. A and B are cross-site. In this case A can prompt on behalf of B without B having been involved, potentially tarnishing B's reputation.

(SameSite=None cookies seems like a red herring as that follows from how cookies are defined.)

[johannhof]

Thanks Anne!

I understand the reputation concern. While it also seems like something that a prompt should be able to explain (top-level.com wants to access your identity on other-site.com), I think it's important to acknowledge that this is easier to solve for when you have a gating mechanism like FPS. It still seems like an important extension to the SAA given the recent (necessary) per-frame changes, so we'd love to explore ways to make this work for everyone.

I was wondering: Is there any concern to WebKit with using FPS not as a deciding factor but just as a "filter" for who gets to prompt as part of this API? @johnwilander previously mentioned in conversations that this would be worth considering. I know you weren't fully satisfied with the latest version of FPS, but it's not clear to what extent this applies to the idea of gating prompts on it. Alternatively, FPS requires developers to leave .well-known/ artifacts on participating sites that could be checked at runtime, without needing to consume a list.