Intent To Deprecate and Remove: Shared Storage API
Cammie Smith Barnes
Intent to deprecate and remove Shared Storage
Contact emails
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 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).
Interest in the Shared Storage API has decreased since the announcement. Use of sharedStorage.worklet.addModule() has decreased ~20% from its peak of 7.35% of page loads down to 5.85% of page loads. Use of sharedStorage.createWorklet() has decreased ~82% from 4.87% to 0.864% of page loads. Use of sharedStorage.run() has decreased ~30% from 5.28% to 3.71% of page loads. Use of sharedStorage.selectURL() has decreased ~28% from 6.24% to 4.51% of page loads. Use of sharedStorage overall has decreased ~9% from 11.91% of page loads to 10.86% of page loads.
Blink component
Web Feature ID
None
Motivation
Chrome has announced that the current approach to third-party cookies will be maintained. Given this, we expect adoption to decrease over time (currently at ~11% 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 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 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% 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.
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
Mike Taylor
Could you please request Debuggability and Testing bits in your chromestatus entry?
--
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/CAJ8xcq6ty%3DiW_L9%3DpbzJbZKAT7rVdu_%2B9-QJ2P2ojCRtSRk4xw%40mail.gmail.com.