I2P&S: Strict Same Origin Policy for Storage Access API

[Chris Fredrickson]

Contact emails

cfre...@chromium.org

Explainer

None

Specification

https://github.com/privacycg/storage-access/pull/213

Summary

Adjusts the Storage Access API semantics to strictly follow the Same Origin Policy, w.r.t. security. I.e., using document.requestStorageAccess() in a frame only attaches cookies to requests to the iframe's origin (not site) by default.

Note: the CookiesAllowedForUrls enterprise policy and/or Storage Access Headers may still be used to unblock cross-site cookies.

Blink component

Blink>StorageAccessAPI

TAG review

Not requested since this is a small change to the existing Storage Access proposal that improves security and has no impact on privacy or user experience.

TAG review status

N/A

Risks

Interoperability and Compatibility

The Storage Access API specification is imprecise about its integration with Fetch, and does not define whether same-site, cross-origin requests ought to be credentialed after an iframe has used the Storage Access API.

Chrome and Firefox both currently include cookies on these same-site cross-origin requests, so there is some risk to making their behaviors diverge. We have discussed this with other browser vendors and they expressed that they were not concerned with Chrome making this change.

However, the Storage Access API currently has very little usage in Chrome (0.08% of pageloads). The cross-origin, same-site subset of usage is an even smaller portion (9% of network requests from affected pageloads). So, the impact of breakage is small regardless.

Sites that are broken by this can fix themselves using the recently-shipped Storage Access Headers feature.

Gecko: No signal

WebKit: No signal

Web developers: Positive (https://github.com/privacycg/storage-access/issues/210#issuecomment-2527687508)

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

Cookies (and the reasons why they are included/excluded) are debuggable via the Network panel in Chrome DevTools.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/storage-access-api/requestStorageAccess-cross-origin-fetch.sub.https.tentative.window.html

Flag name on about://flags

storage-access-api-follows-same-origin-policy

Finch feature name

StorageAccessApiFollowsSameOriginPolicy

Requires code in //chrome?

False

Tracking bug

https://crbug.com/379030052

Estimated milestones

136

Anticipated spec changes

None anticipated.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5169937372676096?gate=5134161335287808

This intent message was generated by Chrome Platform Status.

[Alex Russell]

Hey Chris,

Do you have a sense for what fraction of Storage Access API use (yes, I know it's low) will be impacted by this change? Is there a way to tell?

Best,

Alex

[Vladimir Levin]

Is it a correct reading that that it's roughly 9% of 0.08% of pageloads that will be affected? That still seems large. Can you speak to the nature of the breakage? Specifically, do the sites that currently use it become unusable or is it a milder change from that?

On the process side, do you mind filing vendor signals (Gecko and Webkit) for this?

Thanks,

Vlad

[Chris Fredrickson]

Sorry for the delay, for some reason Alex's message didn't show up in my inbox!

Alex: 

Up to 100% of Storage Access API (SAA) usage could be affected, if we assume that every usage of SAA later involves a cross-origin, same-site network request that is required to be credentialed.

However, it's also possible that none of the network traffic in the cross-origin, same-site bucket actually needs to be credentialed, so the breakage is somewhere between 0% and 100% of SAA usage... which is not very helpful. It's impossible for the browser to measure more specifically (other than checking the credentials mode), since the browser can't tell that cookies are required to be present on a given request.

While writing this I realized that the browser does know the request's credentials mode, so the breakage estimate can at least exclude the portion of requests that opt out of cookies entirely. I'll update the metric accordingly; I expect this will reduce the 9% figure a bit.

Vlad:

Not exactly, the upper bound of breakage is 0.08% of pageloads (under the same assumptions as above). In practice I expect the real figure to be much lower, as not every such iframe will issue a cross-origin, same-site request; and of those that do, probably not all of those requests actually need to be credentialed.

The 9% figure is the proportion of network traffic that could be affected from iframes that have called SAA. E.g., if we assume that every iframe that calls SAA then sends 11 network requests (and one of them is cross-origin same-site), then about 9% of that traffic falls into the bucket that's changing in this launch. As that example illustrates, it's possible that all of the 0.08% of pageloads that use SAA are affected by this launch; it's also possible that only a small fraction are affected.

Re: nature of the breakage, the cross-origin same-site subset of network requests would no longer carry cross-site cookies from an iframe that has called `document.requestStorageAccess()`, by default. The real consequences of that could be anything from a completely broken experience, to unnoticeable; but since sites use cookies in such a variety of ways, it's kind of impossible to predict where on that spectrum this will fall.

Re: vendor signals, yes, I'll do that.

[Chris Fredrickson]

Mozilla standards position request: https://github.com/mozilla/standards-positions/issues/1200

WebKit standards position request: https://github.com/WebKit/standards-positions/issues/476

[Alex Russell]

Thanks, Chris.

We discussed briefly at today's API OWNERs, and Vlad and I are in the same boat (I think?), which is that we're glad that you were able to confirm our understanding of the situation, but the risk continues to look high in that light.

There's generally a menu of options in these cases, ranging from adding more detailed metrics and waiting for analysis to roll in (which can take months), to working with developers and partners to characterise the potential for breakage, to spot checks of known-affected sites (or adding UKM to detect them), to finch'd rollout. We'd like to understand if any of these make sense for this case to reduce the risk profile here.

WDYT?

Best,

Alex

[Chris Fredrickson]

Thanks Alex (and Vlad), those concerns make sense.

Re: next steps, I've improved the existing UMA, but more importantly, I added a UKM-based UseCounter that will precisely measure the % of pageloads that would be affected by this change. I will follow up once I have data from Stable (M136) from that, and know which sites are most likely to experience breakage.

I'm reluctant to do a finch'd rollout for this, since this change affects web platform semantics; a finch rollout for this would make it very hard for web developers to predict the user agent's behavior, IMO. So the other options (improving metrics, including UKM to identify affected sites) seem like the better option to me.

Talk to you in a month or two (I hope),

Chris