Hi API Owners, The Shared Storage API was deprecated in Chrome-144 with a plan to remove it in Chrome-150. For example, currently the usage of sharedStorage.worklet.addModue() is at 3.1% of page loads.
<https://chromestatus.com/metrics/feature/timeline/popularity/4264>We are proposing the following as next steps for removal and associated timelines: 1. M150: Remove all Ads API-related entries from Chrome settings and UI surfaces (e.g., chrome://settings/adPrivacy) via field trial. After this point, all API invocations for field-trial enabled browsers will always reject. Since the API can already be disabled for one of many reasons, scripts must already handle such rejections (or they’re already significantly broken). 2. M152: Permanently remove the underlying implementation code for the API, and replace it with a lightweight stub API. The stub will remain removable via field trial. 3. M152 Canary/Beta: Begin a controlled rollout of the stub API removal via a field trial. 4. M152 Stable: Assuming there are no regressions or breakage after reaching 1% stable, we will request additional approval for full removal at this stage. At this time, we are seeking LGTMs for steps #2 and #3. Thanks, Cammie On Wed, Nov 19, 2025 at 11:13 AM Chris Harrelson <[email protected]> wrote: > LGTM3 > > On Wed, Nov 19, 2025 at 8:12 AM Vladimir Levin <[email protected]> > wrote: > >> LGTM2 with the same conditions as Yoav >> >> On Wednesday, November 19, 2025 at 11:11:12 AM UTC-5 Yoav Weiss wrote: >> >>> LGTM1 to carry on with deprecation in M144 and to remove in M150 IFF >>> usage is lower than 0.0003% >>> >>> In case usage doesn't drop as M150 approaches, I expect y'all to come >>> back to this thread so that we can jointly evaluate our options. Does that >>> work? >>> >>> On Friday, November 14, 2025 at 7:43:00 PM UTC+1 Cammie Smith Barnes >>> wrote: >>> >>>> Thank you for raising this issue. >>>> >>>> We've already reached out to folks representing 99% of the remaining >>>> Shared Storage API calls, and will reach out to the rest soon. We're >>>> confident that we can remove this API by the proposed milestone with >>>> minimal user breakage or utility loss. >>>> >>>> Cammie >>>> >>>> On Wed, Nov 12, 2025 at 11:42 AM Daniel Bratell <[email protected]> >>>> wrote: >>>> >>>>> Part of the reason that I think that we can remove the other "privacy >>>>> sandbox" features so aggressively despite high usage numbers, is that the >>>>> number of actual users is very limited. I don't have the understanding >>>>> necessary to say if that is true for this one as well. >>>>> >>>>> Or in other words, do you know how realistic it is to drive this to a >>>>> really, really, minute usage number through a deprecation? >>>>> >>>>> I am also more worried about the effect of breaking this compared to >>>>> some of the others. It seems more likely to actually cause site breakage, >>>>> if (I don't know this) it is used more widely than the other APIs. >>>>> >>>>> Do you know more about those concerns? >>>>> >>>>> /Daniel >>>>> On 2025-11-07 20:32, Cammie Smith Barnes wrote: >>>>> >>>>> Intent to deprecate and remove Shared Storage >>>>> >>>>> >>>>> Contact emails >>>>> >>>>> [email protected] >>>>> >>>>> Explainer >>>>> >>>>> https://github.com/WICG/shared-storage/blob/main/README.md >>>>> >>>>> Specification >>>>> >>>>> https://wicg.github.io/shared-storage/ >>>>> >>>>> Summary >>>>> >>>>> The Shared Storage API is a privacy-preserving web API to enable >>>>> storage that is not partitioned by first-party site. >>>>> >>>>> Following Chrome's announcement >>>>> <https://privacysandbox.com/news/privacy-sandbox-next-steps/> that >>>>> the current approach to third-party cookies will be maintained, we are now >>>>> planning to deprecate and remove the Shared Storage API (along with >>>>> certain >>>>> other Privacy Sandbox APIs, as outlined on the Privacy Sandbox >>>>> feature status page >>>>> <https://privacysandbox.google.com/overview/status>). >>>>> >>>>> Interest in the Shared Storage API has decreased since the >>>>> announcement. Use of sharedStorage.worklet.addModule() >>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4264> >>>>> has decreased ~20% from its peak of 7.35% of page loads down to 5.85% of >>>>> page loads. Use of sharedStorage.createWorklet() >>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4836> >>>>> has decreased ~82% from 4.87% to 0.864% of page loads. Use of >>>>> sharedStorage.run() >>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4270> >>>>> has decreased ~30% from 5.28% to 3.71% of page loads. Use of >>>>> sharedStorage.selectURL() >>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4269> >>>>> has decreased ~28% from 6.24% to 4.51% of page loads. Use of >>>>> sharedStorage overall >>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4263> >>>>> has decreased ~9% from 11.91% of page loads to 10.86% of page loads. >>>>> >>>>> Blink component >>>>> >>>>> Blink>Storage>SharedStorage >>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EStorage%3ESharedStorage%22> >>>>> >>>>> 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. Given >>>>> this, we expect adoption to decrease over time (currently at ~11% >>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4263> >>>>> of page loads) as the main use cases for Shared Storage will remain >>>>> possible in Chrome using third-party cookies. Further, other browser >>>>> engines have not signaled interest in launching the API. See also the >>>>> initial public proposal below. >>>>> >>>>> >>>>> Developer-facing impact >>>>> >>>>> Sites that are using the Shared Storage API that do not migrate to >>>>> alternative solutions may experience a disruption in functionality, and in >>>>> particular all writes, reads, and worklet operations will fail. If >>>>> continued usage numbers warrant, we will take steps to minimize any risk >>>>> of >>>>> actual page breakage, e.g. by temporarily retaining stub implementations >>>>> of >>>>> the window-exposed methods that are still being called most frequently. >>>>> >>>>> The following API surfaces will be removed: >>>>> >>>>> - >>>>> >>>>> All of the Shared Storage JavaScript functions exposed to the >>>>> Window >>>>> >>>>> <https://github.com/WICG/shared-storage/blob/main/README.md#outside-of-worklets-eg-places-where-writing-can-happen> >>>>> will be removed or replaced with stub implementations: >>>>> - >>>>> >>>>> `window.sharedStorage.worklet.addModule()` >>>>> - >>>>> >>>>> `window.sharedStorage.createWorklet()` >>>>> - >>>>> >>>>> `window.sharedStorage.worklet.run()`/`sharedStorage.run()` >>>>> - >>>>> >>>>> >>>>> >>>>> `window.sharedStorage.worklet.selectURL()`/`sharedStorage.selectURL()` >>>>> - >>>>> >>>>> `window.sharedStorage.set()` >>>>> - >>>>> >>>>> `window.sharedStorage.append()` >>>>> - >>>>> >>>>> `window.sharedStorage.delete()` >>>>> - >>>>> >>>>> `window.sharedStorage.clear()` >>>>> - >>>>> >>>>> `window.sharedStorage.batchUpdate()` >>>>> - >>>>> >>>>> All of the Shared Storage JavaScript functions exposed only to the >>>>> SharedStorageWorklet >>>>> >>>>> <https://github.com/WICG/shared-storage/blob/main/README.md#in-the-worklet-during-an-operation> >>>>> will be removed. Since the worklet operation methods >>>>> (`sharedStorage.run()` >>>>> and `sharedStorage.selectURL()` listed above) will be removed or >>>>> replaced >>>>> with no-op stub implementations, there will be no calls to any >>>>> SharedStorageWorklet-exposed Shared Storage JavaScript functions, and >>>>> so >>>>> removing them will cause no breakage. >>>>> - >>>>> >>>>> The SharedStorageWorklet interface will be removed or replaced by >>>>> a stub worklet interface (potentially for `addModule`, `run`, >>>>> `selectURL` >>>>> stub implementations). >>>>> - >>>>> >>>>> Consequently the `sharedStorage.worklet` attribute will either be >>>>> removed or updated to the stub worklet interface type pending removal. >>>>> - >>>>> >>>>> The `sharedStorage.context` attribute will be removed, along with >>>>> the related `setSharedStorageContext()` method on fenced frame >>>>> configs. We >>>>> will measure the usage of `setSharedStorageContext()` to determine >>>>> whether >>>>> it should be replaced with a no-op stub implementation instead. >>>>> - >>>>> >>>>> The `sharedstoragewritable` attribute on <iframe> and <img> >>>>> elements will be ignored. >>>>> - >>>>> >>>>> The `sharedStorageWritable` option in the fetch() API's >>>>> RequestInit will be a no-op. >>>>> - >>>>> >>>>> Consequently, the `Sec-Shared-Storage-Writable` and >>>>> `Sec-Shared-Storage-Data-Origin` request headers will no longer be >>>>> sent, >>>>> and the `Shared-Storage-Write` and >>>>> `Shared-Storage-Cross-Origin-Worklet-Allowed` response headers will no >>>>> longer be honored. >>>>> - >>>>> >>>>> The “shared-storage” and “shared-storage-select-url” permissions >>>>> policy-controlled features will be removed along with the APIs. Since >>>>> the >>>>> APIs they control will no longer exist, the permission policies will >>>>> have >>>>> no effect and their removal is not considered a breaking change. >>>>> - >>>>> >>>>> The `sharedStorage` attribute on the Window will be removed once >>>>> all stub implementations are no longer needed and are removed. >>>>> >>>>> >>>>> Estimated milestones >>>>> >>>>> Planning to deprecate in M144 and remove in M150. >>>>> >>>>> Currently, ~11% >>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4263> >>>>> of page loads use Shared Storage API. While this usage is quite high >>>>> for a deprecation and removal, it is driven by a small number of >>>>> third-party ad tech scripts present on a large number of sites. We will >>>>> continue to monitor usage in addition to providing comprehensive updates >>>>> on >>>>> privacysandbox.google.com with the status of the API and deprecation >>>>> plans <https://privacysandbox.google.com/overview/status>. >>>>> >>>>> We will proactively work toward reducing usage to low levels once this >>>>> intent is approved, including disallowing any new enrollment sign-ups, and >>>>> contacting enrolled sites to inform them about the deprecation timelines. >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/5076349064708096 >>>>> >>>>> -- >>>>> 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/CAJ8xcq6ty%3DiW_L9%3DpbzJbZKAT7rVdu_%2B9-QJ2P2ojCRtSRk4xw%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ8xcq6ty%3DiW_L9%3DpbzJbZKAT7rVdu_%2B9-QJ2P2ojCRtSRk4xw%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/a54fca7f-06d9-4e5c-b15c-3f6cf408b0bbn%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a54fca7f-06d9-4e5c-b15c-3f6cf408b0bbn%40chromium.org?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/CAJ8xcq671i84KCqC1wOkwLAMVtZu7%2BvfbH8yEhRMU3ZU6%2B11rA%40mail.gmail.com.
