Consider requestStorageAccessFor Method

[mreichhoff]

There are use cases where user interaction within an <iframe> is difficult to retrofit. Since the top-level document controls loading of subresources, it may be attractive to allow top-level sites to request storage access on behalf of embedded sites. There is a discussion in a similar vein in issues #53 and #83 as well.

Both Firefox and Safari have run into these issues before and solved them through the application of an internal-only "requestStorageAccessForOrigin" API(1,2), which is applied on a case-by-case basis by custom browser scripts (Safari: 3,4 Firefox: 5,6,7).

Exposing such an API would require elevated trust to prevent abuse and potential security issues; membership in the same First-Party Set is one possible trust signal, which Chrome is evaluating as a replacement for the SameParty cookie attribute.

See the relevant explainer for more context.

This issue is intended to track discussion about a potential requestStorageAccessFor function.

[bvandersloot-mozilla]

“browsers should require additional trust signals to grant storage access via the proposed API, such as FPS membership.”

Are there standardizable alternatives to FPS membership here that are feasible? I’d like to have a path to removing the new “browser-specific” behavior without being handcuffed to FPS. This is why the forward-declared version of the API required bi-directional requests.

I know we already have browser-specific behavior in the spec, I’d argue that this introduces a new kind of browser-specific behavior. Heuristics for determining auto-grant and auto-decline (existing) and heuristics for determining if a request on behalf of another domain is legitimate (new here).

Making this even worse is that I see this forcing implementers that don’t use any heuristics currently to use them. FPS is defined to include utility domains. That puts a browser that doesn’t use heuristics where it either has to barrage the user with popups for every possible utility site used on each top level site visited or add heuristics. This isn’t great.

[mreichhoff]

Thanks for the feedback! As a general note, I do think user consent is another trust signal beyond FPS. Beyond that, I think there are two separate questions on the elevated trust front:

• How can we prevent security issues, e.g., if SameSite=None cookies are sent when they shouldn’t be?
• How can we prevent prompt spam, especially for less-permissive browsers?

For the first, beyond SameSite=None cookies serving as an opt-in signal by the 3rd party, we’re working on concrete, standardizable steps to mitigate security concerns. Some options could be:

• Some kind of CORS check before sending SameSite=None cookies. This would reduce the impact of an erroneous storage access grant.
• Some kind of .well-known path where sites can specify allowed requesters.

I know that johannhof and arturjanc are working on this. I’ll let them chime in when they’re ready.

For the second, I think there are a few options:

• Using a simple counter to limit the number of requests per top-level site, or to implicitly grant a small number of requests, much like is done today in multiple browsers. Separate counters could be used for requestStorageAccessForSite and requestStorageAccess so that there is less risk of contention.
• Treating sites that differ only by ccTLD as equivalent.
• Opting for site applicability (rather than origin) could help reduce notification spam. Note that we’ve been viewing this as an open question.

With all this said, I think we would still want browsers to have latitude in when they automatically grant or deny requests. I’d be curious if you think the full grant/deny logic should be standardized, or only some part of it?

[johannhof]

Yeah, I apologize that our update regarding security concerns (which affect all of rSA to an extent, not just rSAFor) takes a bit longer than planned, but I hope we can share our thoughts soon. In the explainer we should have separated this out more cleanly instead of recommending both concerns Matt mentioned to be solved through FPS. That wasn't in the spirit of the overall announcement and we'll try to fix it.

Regarding prompt/heuristics concerns, I think it's important to note that implementation-defined steps are an intentional property of SAA, both as a working compromise and as a tool to preserve differentiation for browsers. Heuristics are also used to restrict which sites may prompt, for example in Safari (through the prior 1p visit requirement). Firefox has always been much more permissive than Safari, to the point where sites that are compatible with Firefox could be incompatible with Safari.

As you know, this is a difficult field to navigate with different requirements between browsers and we should build SAA to compromise between those. forward-declare does a good job at reducing heuristics, but at the cost of utility and flexibility by being built for login-specific use cases. rSAFor is meant to bring some flexibility, given that the SameParty attribute can't be used to address certain use cases anymore and that we've seen a need for rSAFor use cases in other browsers.

So, I agree with you that we need to better define how much concern for prompt spam we see from rSAFor and how we can address it, but I wouldn't frame this as being an issue from FPS integration. If any popular service picked up rSA today then some browsers would be faced with a large number of prompts, independent of FPS or heuristics by other browsers.

Instead, we should threat-model rSAFor as possibly being abused by parties with bad intent that could reach further than a single FPS (i.e. modeling for rSAFor usage without FPS).

Maybe we could fork the prompt spam risk discussion into a separate issue on the rSAFor proposal?

[bvandersloot-mozilla]

Looking forward to the security considerations around storage requests. I agree on the impact outside of the rSAFor spec.

I agree that @mreichhoff 's proposed heuristics sound reasonable. One other idea I thought of that I'd like to put forward is the base URL of the script making the request.

With all this said, I think we would still want browsers to have latitude in when they automatically grant or deny requests. I’d be curious if you think the full grant/deny logic should be standardized, or only some part of it?

I think that we should be mindful of what behaviors are browser-dependent. As Johann pointed out, browser-dependent behavior is a deliberately chosen feature of the Storage Access API to allow compromise among browsers. I don't think it is reasonable to strip all behaviors left up to the browser this instant, however I do think it is good to hold up as a goal to aim for (we are all trying to build a consensus around standardized behavior after all!).

forward-declare does a good job at reducing heuristics, but at the cost of utility and flexibility by being built for login-specific use cases. rSAFor is meant to bring some flexibility, given that the SameParty attribute can't be used to address certain use cases anymore and that we've seen a need for rSAFor use cases in other browsers

I agree. Given Safari's positive position on and Mozilla's interest in implementing FedCM, the utility of forward-declare is reduced and makes rSAFor the better proposal to build an extension on. I just want to be mindful of prompt spam on less permissive browsers and maintaining a minimal set of browser-specific behavior required to make things work.

Instead, we should threat-model rSAFor as possibly being abused by parties with bad intent that could reach further than a single FPS (i.e. modeling for rSAFor usage without FPS).

Sure, this sounds good.

Maybe we could fork the prompt spam risk discussion into a separate issue on the rSAFor proposal?

👍 Forked here.

[annevk]

This still very much applies I think:

The third party needs to be involved as it receives (part of) the blame and holds the authority over the data involved.

As I understand this API, it allows A to ask the user whether they want to include their cookies for B in fetches that A makes to B, without any involvement from B. This can be bad for B's security and reputation.

[mreichhoff]

As I understand this API, it allows A to ask the user whether they want to include their cookies for B in fetches that A makes to B, without any involvement from B. This can be bad for B's security and reputation.

Yes, your understanding is correct.

To preserve B's reputation, Chrome has been planning to use First-Party Sets as a trust signal that indicates B has opted in to sharing with A. Our view is that the various policy checks imposed by FPS are sufficient to establish this relationship at rSAFO call-time.

To ensure B's security, our view is that the combination of SameSite protections, origin scoping, and the suggested CORS requirement for subresources might help make the opt-in signal more granular when the cookies are actually used.

We are continuing to explore other ways of indicating embeddee opt-in, so any ideas are more than welcome!

[OskarEichler]

Would certainly be very much in favor of a requestStorageAccessFor method that can be called without the need of opening an Iframe, as we are trying to open backend WebSockets, so embedding iFrames is really not the ideal solution.

Alternatively it would be awesome if domain owners could somehow chain domains to a cluster that are allowed to access each others cross-origin cookies. For instance, if we own Domain A, Domain B and Domain C - it would be awesome if we could provide a DNS entry or likewise in Domain A to authorize Domain B and C to access its cross-site cookies without any further request.

[johnwilander]

I truly believe that allowing the first party website to request storage access for third parties will end up in a bad situation for users. You will go to news.example and as soon as you tap something you’ll be prompted to grant storage access to tracker.example. That’s why the requirement has always been for the user to engage with the third party content before a request for access can be made.

Sure, tracker.example can convince news.example to cover its whole page with a transparent iframe to achieve the same result but that hasn’t happened. However, tracker.example’s script running in news.example’s context is already the case and them hooking up some onclick handlers will be a small thing.

This will put pressure on the escape hatch for when the user denies access, is not happy with the results, and wants to change their mind. WebKit started out with no limit on the number of times the user could be asked on a page but that was abused so we backed to twice per rendered cross-site iframe. That’s WebKit’s escape hatch today. There will be tremendous pressure on this if first parties can start requesting storage access on behalf of third parties. We may not be able to offer an escape hatch at all if users are repeatedly pushed to opt in to tracking.

[OskarEichler]

Just some thoughts:

It seems like there are three moving parts here:

1. The First Party Website (news.example)
2. The Third Party Website (tracker.example)
3. The user

The Third Party website currently doesn't have any say in who can access their cookies. That feels wrong. I think that there should either be an allow-list or black-list that can be configured as DNS entry by the embedded website. If no entries exist then the default behavior applies and every website can request cookie access from the user. I think this is important, as otherwise website can request data from third parties without their consent.

Now for the User behavior - I personally think that this should work similar to when a website requests to send the user push notifications. So a single prompt that requests permissions. It could even be with a warning that by allowing this the website can actively track you, and can potentially be disabled all together by the user based on their browser settings.

[OskarEichler]

Alternatively if not as DNS entries, adding it similar to the Permissions Policy or Content Security Policy would also work great!

[johannhof]

This has moved to its own proposal in https://github.com/privacycg/requestStorageAccessForOrigin