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/CAFUtAY-Mxd_7W%3DO2CR_Zc_XmxL6_WCa6b21FNLyhbKwV1%3DsyiA%40mail.gmail.com.
