LGTM1, thanks Johann! I appreciate that there's some risk here (0.018% is still a lot of pageloads). But given the context of an optional feature not well supported across browsers and useful only for the small fraction of Chromium browser users with 3PCs disabled, I believe the risk is low and also trust that you and your team will respond to any incidents effectively.
On Mon, Jul 27, 2026 at 5:50 PM Johann Hofmann <[email protected]> wrote: > Hello! > > I'm happy to report that rSAFor usage has been driven down significantly. > Given > that the previous LGTMs were for deprecation only, *I'm seeking** final > approval to remove document.requestStorageAccessFor in M153*. > > After the biggest consumer of the API removed usage in June, we are now > at 0.018% of pageloads > <https://chromestatus.com/metrics/feature/timeline/popularity/4332>. To > address Mike's earlier concern, usage of navigator.permissions.query for > top-level-storage-access has been driven down massively as well, to <= > 0.03% of pageloads (this is an upper bound as I am naively assuming at most > one query per pageload, which is the best I can do with the available > metrics). > > From brief spot testing of the few larger sites still using the API, the > only noticeable loss of functionality is the lack of automatic (silent) > login between their related sites. This is an expected result (and only > happens if the user actually blocks 3PCs). > > As such, I'd like to proceed and remove the API now. We'll use a feature > flag (StorageAccessAPIRelatedWebsiteSets) to have an emergency lever for > unexpected breakage, and plan to actually remove the code in the M154/M155 > timeframe. > > Please let me know if you have any questions! > > Thanks, > > Johann > > > On Mon, Nov 24, 2025 at 5:03 PM Johann Hofmann <[email protected]> > wrote: > >> Thank you everyone! Just wanted to ack the concerns again and will try to >> report back on any bumps along the way. >> >> On Sun, Nov 23, 2025 at 4:50 PM Rick Byers <[email protected]> wrote: >> >>> LGTM3 to deprecate. >>> Yes I'm quite sure that worst case we can no-op this. I hope it doesn't >>> get stuck there though, total removal doesn't seem like it should be too >>> hard, but we still need to put the work in to do it responsibly. >>> >>> Thanks! >>> Rick >>> >>> On Sun, Nov 23, 2025, 1:46 a.m. Yoav Weiss (@Shopify) < >>> [email protected]> wrote: >>> >>>> LGTM2 with a similar disclaimer >>>> >>>> On Wednesday, November 19, 2025 at 11:06:30 PM UTC+2 Mike Taylor wrote: >>>> >>>>> Thanks Johann. >>>>> >>>>> LGTM1 to deprecate, but please come back before M150 for us to discuss >>>>> removal, so we have a better idea of the risk. And good luck driving usage >>>>> down. >>>>> On 11/9/25 8:31 p.m., Johann Hofmann wrote: >>>>> >>>>> 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. >>>>> >>>>> >>>>> On Mon, Nov 10, 2025 at 9:56 AM Mike Taylor <[email protected]> >>>>> wrote: >>>>> >>>>>> 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`? >>>>>> >>>>>> On 11/8/25 8:39 a.m., Rick Byers wrote: >>>>>> >>>>>> 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 >>>>>> >>>>>> On Fri, Nov 7, 2025 at 1:52 PM Rick Byers <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> 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 >>>>>>> >>>>>>> On Fri, Nov 7, 2025, 12:35 p.m. 'Johann Hofmann' via blink-dev < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Apologies, I used the wrong Chromestatus link (the original feature >>>>>>>> status), this one is correct: >>>>>>>> https://chromestatus.com/feature/5162221567082496 >>>>>>>> >>>>>>>> On Fri, Nov 7, 2025 at 2:44 PM Johann Hofmann <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Contact emails >>>>>>>>> >>>>>>>>> [email protected], [email protected] >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorageAccessAPI> >>>>>>>>> >>>>>>>>> Web Feature ID >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> Motivation >>>>>>>>> >>>>>>>>> Chrome has announced >>>>>>>>> <https://privacysandbox.com/news/update-on-plans-for-privacy-sandbox-technologies/> >>>>>>>>> that the current approach to third-party cookies will be maintained. >>>>>>>>> rSAFor >>>>>>>>> currently has usage on about 0.95% of page loads >>>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4332>, >>>>>>>>> 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 >>>>>>>>> <https://github.com/GoogleChrome/related-website-sets/blob/main/related_website_sets.JSON>. >>>>>>>>> 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 >>>>>>>>> <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 [email protected]. >>>>>>>> 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 >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4jr7zaQS-Sy%2B_DvWQsMWx_DMJ_sLsMe412Ca96Cg-uLyg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>>>> 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 [email protected]. >>>>>> To view this discussion visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8Q1KXUC0W9JMrpknW2o%2BPLdK7vi4d4dmhUZEssj1Gung%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8Q1KXUC0W9JMrpknW2o%2BPLdK7vi4d4dmhUZEssj1Gung%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9HSKH39mijc6ysuXcbpCgm7ouyS5KryO4mDcqcOWk0qw%40mail.gmail.com.
