Intent to Ship: Shared Storage API Enhancements

[Cammie Smith Barnes]

Contact emails

cam...@chromium.org

jka...@chromium.org

ale...@chromium.org

yao...@chromium.org

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

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?

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

[Chris Harrelson]

This looks good, but please file for all of the 5 other chips necessary for shipping a feature.

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ8xcq5HooQ3L6HbL9z8-xP9fFw3gjW6150H8RSJ_a4pfDmMcQ%40mail.gmail.com.

[Jason Robbins]

At this morning's API Owners meeting, they asked me to add all review gate types to all of the "web developer facing code change" features that are currently under review, including this one.  So, I have added Privacy, Security, Enterprise, Debuggability, and Testing gates to your feature entry. 

Please click the gate chips in the "Prepare to ship" stage on your feature detail page.  For each one, answer survey questions and request that cross-functional review.  You can request them all in parallel.  In cases where you already have the go/launch bit approved, you can note that in a comment on that gate for a potentially faster review.

Thanks,

jason!

[Mike Taylor]

Thanks Jason!

And yes, Cammie (and team), please request approval bits in Chromestatus - API OWNERs will wait on that (not approvals, just beginning the process for each) before approving.

thanks,
Mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/02d283d3-3ba1-4baf-aa22-d7b1cd1dd313n%40chromium.org.

[Yoav Weiss]

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

LGTM2

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/02d283d3-3ba1-4baf-aa22-d7b1cd1dd313n%40chromium.org.

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/18947cf0-a260-4a9f-8d12-2e18af7272b1n%40chromium.org.

[Mike Taylor]

LGTM3

[Cammie Smith Barnes]

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, M119 will allow writing and deleting from Shared Storage via HTTP response header. The details can be found in the explainer with examples, as well as in the specification.

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 and #121.

Hence, the new request header attached to eligible outgoing requests will be 'Sec-Shared-Storage-Writable: ?1'.

[Cammie Smith Barnes]

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 with examples, as well as in the specification.