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/CAD_OO4ivS6ES2m-X9NvdvduDv1m5_ohGDOvgyZ3YNi4pkVw-6A%40mail.gmail.com.
