FYI: Shared Storage API via HTTP response headers enabled by default in M124
Chrome was supposed to enable support for writing to Shared Storage via response headers by default in M119. Due to a bug, however, this behavior was not enabled by default and had to be enabled via the command line. This has been fixed and as of M124, modifying Shared Storage via response header is enabled by default. The details of using Shared Storage with response headers can be found in the explainer <https://github.com/WICG/shared-storage#from-response-headers> with examples <https://github.com/WICG/shared-storage#writing-to-shared-storage-via-response-headers>, as well as in the specification <https://wicg.github.io/shared-storage/#http>. On Fri, Oct 27, 2023 at 3:46 PM Cammie Smith Barnes <[email protected]> wrote: > FYI: Update Shared Storage API HTTP request header name to > 'Sec-Shared-Storage-Writable' > > As previously mentioned in our Intent to Ship, as part of the M119 > Enhancements to the Shared Storage API > <https://chromestatus.com/feature/5112254843846656>, M119 will allow > writing and deleting from Shared Storage via HTTP response header. The > details can be found in the explainer > <https://github.com/WICG/shared-storage#from-response-headers> with > examples > <https://github.com/WICG/shared-storage#writing-to-shared-storage-via-response-headers>, > as well as in the specification > <https://wicg.github.io/shared-storage/#http>. > > The HTTP request header name for requests that opt-in and are eligible was > originally specified as 'Shared-Storage-Writable'. For Chrome stable > versions 119 and later, however, the HTTP request header name has been > updated to 'Sec-Shared-Storage-Writable' as discussed in pull requests > #120 <https://github.com/WICG/shared-storage/pull/120> and #121 > <https://github.com/WICG/shared-storage/pull/121>. > > Hence, the new request header attached to eligible outgoing requests will > be 'Sec-Shared-Storage-Writable: ?1'. > > > On Wed, Sep 27, 2023 at 2:13 PM Cammie Smith Barnes <[email protected]> > wrote: > >> Contact emails >> >> [email protected] >> >> [email protected] >> >> [email protected] >> >> [email protected] >> >> Explainer >> >> https://github.com/WICG/shared-storage >> >> Specification >> >> https://wicg.github.io/shared-storage/ >> >> Summary >> >> We plan to ship the following changes to the Shared Storage API: >> >> 1. >> >> Only allow Private Aggregation reports for up to 5 seconds after a >> worklet operation starts >> 1. >> >> This is a privacy measure to prevent timing attacks. >> 2. >> >> Reports sent after this point are silently dropped >> 2. >> >> Allow writing to and deleting from Shared Storage via HTTP response >> header >> 1. >> >> This is a performance improvement and is backwards compatible >> 3. >> >> Per-site privacy budgeting >> 1. >> >> This change enforces budgets to per-site rather than per-origin >> >> >> Blink component >> >> Blink>Storage>SharedStorage >> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EStorage%3ESharedStorage&can=2> >> >> >> >> >> Risks >> >> >> Interoperability and Compatibility >> >> Change [1] will drop the private aggregation contributions issued after 5 >> seconds after a worklet operation starts. 5 seconds should be sufficient >> for all known use cases, so this change should have negligible backward >> compatibility issues. >> >> Change [2] is optional and fully backwards compatible. >> >> Change [3] could decrease budget for those that are using multiple >> origins today that are considered part of the same eTLD+1. Since the API is >> new (shipped in M115), the expectation is for the impact to be low. It will >> not break script since the APIs gracefully handle situations where the >> budget is exceeded, but could impact the overall quality of the returned >> data for that site. >> >> Gecko: No signal >> >> WebKit: No signal >> >> Web developers: No signals >> >> Other signals: >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> None >> >> >> Debuggability >> >> Shared Storage database contents for an origin can be viewed and modified >> within devtools. Support for debugging Shared Storage worklets will be >> available within the next couple of milestones. >> >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, Chrome OS, Android, and Android WebView)? >> >> All but WebView >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> Yes >> >> Flag name >> >> Finch feature name >> >> SharedStorageAPIM118 >> >> Requires code in //chrome? >> >> No >> >> Estimated milestones >> >> We intend to ship in M119. >> >> Anticipated spec changes >> >> 1. >> >> Timeout enforcement: >> >> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/102 >> 2. >> >> Allow writing to Shared Storage via response headers >> >> https://github.com/WICG/shared-storage/pull/110 >> >> 3. >> >> Per-site privacy budgeting >> >> https://github.com/WICG/shared-storage/pull/118 >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/5112254843846656 >> >> -- 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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ8xcq7GYHCFup9-yyXycuQijYDkqu5%3DfMvSTQse7zH%3D6M%2Biuw%40mail.gmail.com.
