Following up on this:
Now that the new UseCounter
<https://chromestatus.com/metrics/feature/timeline/popularity/5459>
has made it out to Stable, the portion of pageloads that would be
affected by this change is 0.000069%.
The UseCounter
<https://chromestatus.com/metrics/feature/timeline/popularity/3311>
for `document.requestStorageAccess()` is currently at 0.075%.
Same-site cross-origin SAA usage is a strict subset of this, which
means 0.00092% of SAA usage would be affected in Chrome.
Please LMK if those numbers look acceptable to you.
On Friday, March 28, 2025 at 4:27:37 PM UTC-4 Chris Fredrickson wrote:
Thanks Alex (and Vlad), those concerns make sense.
Re: next steps, I've improved <https://crrev.com/c/6373548> the
existing UMA, but more importantly, I added
<https://crrev.com/c/6397807> 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
On Wednesday, March 26, 2025 at 11:27:05 AM UTC-4 Alex Russell wrote:
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
On Friday, March 21, 2025 at 12:39:14 PM UTC-7 Chris
Fredrickson wrote:
Mozilla standards position request:
https://github.com/mozilla/standards-positions/issues/1200
<https://github.com/mozilla/standards-positions/issues/1200>
WebKit standards position request:
https://github.com/WebKit/standards-positions/issues/476
<https://github.com/WebKit/standards-positions/issues/476>
On Wednesday, March 19, 2025 at 4:40:17 PM UTC-4 Chris
Fredrickson wrote:
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.
On Wednesday, March 19, 2025 at 11:23:28 AM UTC-4
Vladimir Levin wrote:
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
On Monday, March 17, 2025 at 2:28:23 PM UTC-4 Alex
Russell wrote:
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
On Wednesday, March 12, 2025 at 9:04:37 AM
UTC-7 Chris Fredrickson wrote:
Contact emails
cfred...@chromium.org
Explainer
None
Specification
https://github.com/privacycg/storage-access/pull/213
<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
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EStorageAccessAPI%22>
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
<https://groups.google.com/a/chromium.org/g/blink-dev/c/gERgwZfN_-E/m/QIJbT1zUCgAJ>feature.
Gecko: No signal
WebKit: No signal
Web developers: Positive
(https://github.com/privacycg/storage-access/issues/210#issuecomment-2527687508
<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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes
https://wpt.fyi/results/storage-access-api/requestStorageAccess-cross-origin-fetch.sub.https.tentative.window.html
<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
<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
<https://chromestatus.com/feature/5169937372676096?gate=5134161335287808>
This intent message was generated by
Chrome Platform Status
<https://chromestatus.com/>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8344a1ee-3466-47e0-a447-b17924af0c7an%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8344a1ee-3466-47e0-a447-b17924af0c7an%40chromium.org?utm_medium=email&utm_source=footer>.
