Intent to Deprecate and Remove: document.requestStorageAccessFor

[Johann Hofmann]

Contact emails

joha...@google.com, kaust...@google.com

Explainer

https://github.com/privacycg/requestStorageAccessFor 

Specification

https://privacycg.github.io/requestStorageAccessFor/ 

Summary

The requestStorageAccessFor (rSAFor) API is an extension to the Storage Access API that allows a top-level site to request access to unpartitioned ("first-party") cookies on behalf of embedded sites. Browsers will have discretion to grant or deny access, with mechanisms like Related Website Sets (RWS) membership as a potential signal. This allows for use of the Storage Access API by top-level sites. Following Chrome's announcement that the current approach to third-party cookies will be maintained, we are now planning to deprecate and remove rSAFor, as it is only usable in Chrome to request storage access between RWS sites. Related Website Sets will also be deprecated via a separate intent.  

Blink component

Blink>StorageAccessAPI

Web Feature ID

None

Motivation

Chrome has announced that the current approach to third-party cookies will be maintained. rSAFor currently has usage on about 0.95% of page loads, but any website relying on successful invocation of rSAFor (i.e. the API returns a promise that resolves) must also have registered a set on the RWS GitHub repository. Any invocations of rSAFor outside of an RWS currently returns a promise that is rejected.

Our metrics suggest that almost all of the usage of rSAFor is from websites that have registered sets. We will continue to monitor usage and aim to drive it down prior to removal by proactively informing set owners of the deprecation timelines and request them to turn down usage. Additionally, other browser engines have not signaled interest in implementing the API, obviating any interoperability concerns.

Debuggability

N/A

Requires code in //chrome?

False

Estimated milestones

Deprecate in M144, and target M150 for removal. 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5122534152863744

This intent message was generated by Chrome Platform Status.

[Johann Hofmann]

Apologies, I used the wrong Chromestatus link (the original feature status), this one is correct: https://chromestatus.com/feature/5162221567082496

[Rick Byers]

This one seems a bit trickier than RWS itself because we have to reason about the risk of code that assumes the API exists. I am supportive of deprecation now, but perhaps we should come back to the data after RWS is removed and see what the usage severity of breakage is in practice before approving removal?

Rick

--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4jr7zaQS-Sy%2B_DvWQsMWx_DMJ_sLsMe412Ca96Cg-uLyg%40mail.gmail.com.

[Rick Byers]

That said, your point about it applying just to the relatively small number of sites on the RWS list is a good one. I do expect you're right that it'll be easy to drive down usage and I'd also guess that the vast majority of usage would be gated by a feature detect, right? Just feels like we'll need a bit more evidence to demonstrate why we know this will be safe to remove given the high UseCounter. 

Rick

[Mike Taylor]

One concern I have is once we remove the `top-level-storage-access` permission, `navigator.permissions.query` will throw a TypeError. Of the ~1% of pages using rSAFor, do we know how many of them are using `navigator.permissions.query`?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8Q1KXUC0W9JMrpknW2o%2BPLdK7vi4d4dmhUZEssj1Gung%40mail.gmail.com.

[Johann Hofmann]

Thanks both, I think you're spot on with these concerns, both could cause potential breakage and we'll have to work through them as part of the deprecation. It should be possible to look at data for both of these cases, although to Rick's point it may only be possible once we've worked through the list of partners with Related Website Sets.

I'm very confident that outside of the known list of RWS users both checking for existence of rSAFor and potentially problematic permissions checks should be rare enough that I'd still like to seek API Owner approval for this intent right now, also to unblock the outreach to these partners with a reference to the deprecation process in Chrome.

I believe that a viable worst-case option for the M150 timeline could be to simply no-op the API (and the permissions API integration) without RWS support while we track down remaining usage.