Shared Storage API

[pythagoraskitty]

Braw mornin' TAG!

I'm requesting a TAG review of Shared Storage.

In order to prevent cross-site user tracking, browsers are partitioning all forms of storage (cookies, localStorage, caches, etc) by top-frame site. But, there are many legitimate use cases currently relying on unpartitioned storage that will not be fully met without the help of new web APIs. We’ve seen a number of APIs proposed to fill in these gaps (e.g., Attribution Reporting API, Private Click Measurement, Storage Access, Trust Tokens, FLEDGE, Topics) and some remain (including cross-origin A/B experiments and user measurement). We propose a general-purpose, low-level API that can serve a number of these use cases.

The idea is to provide a storage API (named Shared Storage) that is intended to be unpartitioned. Origins can write to it from their own contexts on any page. To prevent cross-site tracking of users, data in Shared Storage may only be read in a restricted environment that has carefully constructed output gates. Over time, we hope to design and add additional gates.

• Explainer (minimally containing user needs and example code): https://github.com/pythagoraskitty/shared-storage/

• Specification URL: https://wicg.github.io/shared-storage/

• Tests: Internal platform tests exist, but they rely on Fenced Frames WPT infra which is temporarily internal.

• User research:

• Security and Privacy self-review: see below

• GitHub repo (if you prefer feedback filed there): https://github.com/pythagoraskitty/shared-storage

• Primary contacts (and their relationship to the specification): Yao Xiao (@xyaoinum), Cammie Smith-Barnes (@pythagoraskitty), Josh Karlin (@jkarlin), Eric Trouton (@etrouton)

• Organization(s)/project(s) driving the specification: Google, Privacy Sandbox

• Key pieces of existing multi-stakeholder review or discussion of this specification:

• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/6256348582903808

Further details:

• [✓] I have reviewed the TAG's Web Platform Design Principles

• Relevant time constraints or deadlines: N/A

• The group where the work on this specification is currently being done: TBD

• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): TBD

• Major unresolved issues with or opposition to this specification:

• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

☂️ open a single issue in our GitHub repo for the entire review

Security/Privacy Questionnaire

This section contains answers to the W3C TAG Security and Privacy Questionnaire. This can also be found here

1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

   Shared Storage is a JavaScript storage mechanism (much like localStorage, indexedDB, CacheStorage, etc.). Like those other storage mechanisms it’s partitioned by origin. But unlike the other storage mechanisms, which may eventually be partitioned by top-frame site as well, (depending on the browser), Shared Storage is designed to not need top-frame partitioning. The intention is to provide for a large number of cross-site use cases such as cross-site fraud and abuse detection, a/b testing (including lift measurement), reach measurement, and frequency capping of ads.

2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

   Yes. While cross-partition writing to Shared Storage is unbounded, reading is severely rate limited. Reading can only occur in isolated JavaScript worklet environments, called Shared Storage Worklets, and data can only leave these worklets via “output gates”. The two output gates in development are selectURL and Private Aggregation.

   The selectURL gate allows for the Shared Storage Worklet to select between one of n URLs supplied by the embedder using information available in Shared Storage. The URL can therefore represent up to log2(n) bits of cross-site information from Shared Storage. The returned url is opaque to the caller, and can only be read within a Fenced Frame, which is isolated from the embedding page. On Fenced Frame user activation, the Fenced Frame can navigate to a destination page, which ultimately could leak the log2(n) bits with the embedder’s URL to the destination page.

   The Private Aggregation API will allow for data in Shared Storage to be aggregated into histograms. The resulting histograms are noised and are differentially private.

   Each output gate has a “budget”. The Private Aggregation’s budget is defined by its differential privacy parameters (e.g., the epsilon value). However, this budget must be reset periodically else Shared Storage becomes useless over time. The selectURL operation has a cap (budget) on the number of leaked bits per period. The bits are removed from the budget once the user has clicked on the Fenced Frame. Like with Private Aggregation, the budget is periodically reset.

3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

   Shared Storage does not place any limits on the types of information origins can write to shared storage.

4. How do the features in your specification deal with sensitive information?

   Same answer as # 3.

5. Do the features in your specification introduce a new state for an origin that persists across browsing sessions?

   Yes, similar to other storage mechanisms, with tracking mitigations provided in answer to # 2.

6. Do the features in your specification expose information about the underlying platform to origins?

   No.

7. Does this specification allow an origin to send data to the underlying platform?

   Shared Storage’s selectURL operation produces a urn:uuid that only a Fenced Frame can interpret.

8. Do features in this specification allow an origin access to sensors on a user’s device

   No.

9. What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.

   Limited access to the origin’s cross-site data as described in answer # 2.

10. Do features in this specification enable new script execution/loading mechanisms?

    Yes. The Shared Storage worklets are loaded and executed in separate JavaScript contexts without access to any web page or network.

11. Do features in this specification allow an origin to access other devices?

    No.

12. Do features in this specification allow an origin some measure of control over a user agent’s native UI?

    No.

13. What temporary identifiers do the features in this specification create or expose to the web?

    None.

14. How does this specification distinguish between behavior in first-party and third-party contexts?

    Shared Storage is intentionally provided to both first and third-parties on a page.

15. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

    The behavior is like other JavaScript storage mechanisms in incognito mode. That is, the storage is kept in a separate partition from normal browsing mode, and is cleared when the incognito session ends.

16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

    Yes.

17. Do features in your specification enable origins to downgrade default security protections?

    No.

18. What should this questionnaire have asked?

    N/A.

[torgo]

Hi - just quickly is this happening / going to happen in the Privacy CG? Thanks.

[hadleybeeman]

Discussed briefly in TAG breakout A today. This fits in with more general feedback that we are working on.

[jkarlin]

Sorry, didn't see the earlier question. The CG is WICG. I haven't heard support from privacy cg or patcg.

[nschonni]

mozilla/standards-positions#646

[torgo]

Hi Josh - just checking back on this. Has there been any movement on multi-stakeholder (specifically multi-browser) support for this API? Thanks, Dan

[torgo]

It was brought to my attention today that my comment above could be clearer. To clarify: we pay attention to multi-stakeholder support as a key indicator of consensus. As stated in the Ethical Web Principles, the Web is multi-browser, multi-OS, multi-device. Multiple implementations are also part of the W3C process and WHATWG process. We are also considering the complexity we're adding to the web platform – and disparity of implementations of web feature adds to that complexity. This is why we ask for "Key pieces of existing multi-stakeholder review" in our review request template. Ideally we would like to see expressed support from at least 2 browser engines. It would also be interesting to know if there has been support from other Chromium-based browsers and/or from web developers.

[jkarlin]

I'm not aware of interest from other browsers for Shared Storage. There is certainly web developer interest (and ongoing testing) for advertising, a/b testing, and anti-fraud use cases.

[shivanigithub]

FYI, Chrome plans to start gating shared storage API invocation behind the enrollment and attestation mechanism. (enrollment explainer, spec PR)

[rhiaro]

Hi folks - We're planning to close this as the concerns raised by us and in the Mozilla standards position have not been addressed. We're also noting that there is lack of multi-stakeholder feedback/support. We are sympathetic to the need to replace some of the functionality lost with the removal of third-party cookies; in this case we think it'd be better to address the use cases individually, with designed-for-purpose approaches, rather than adding a single underlying mechanism which has the potential to re-introduce the risks that the removal of third-party cookies were intended to mitigate in the first place.

We're a little concerned by the addition of the attestation mechanism mentioned. Registering in order to use an API is not something we see having a place in the web platform.

Please let us know if there are any significant changes in the design going forward that would mitigate the issues raised.

[jkarlin]

Please let us know if there are any significant changes in the design going forward that would mitigate the issues raised.

Are you also interested in hearing about and providing feedback on other changes to the design going forward, given the unsatisfied status?

e.g., we're making it possible to directly create cross-site worklets so that third-party script doesn't have to create an iframe for its origin in order to create its worklet.

[torgo]

Hi @jkarlin sorry we didn't get back to you on this question. If there are significant changes to Shared Storage that you think we should review, then by all means let us know and we can re-review. Depending on the scope of the update it might be appropriate to open a new review?

[jkarlin]

Great! FYI WICG/shared-storage#161 is a recent spec change we've made to make it possible to load cross-site script in shared storage worklets, and to align the behavior of addModule and createWorklet() to both use the calling context's origin by default.

[jkarlin]

FYI WICG/shared-storage#176 is our latest change to selectURL. It allows for the caller to specify a query name, and repeated query names on the same page load will result in the same value being returned. Since the same information is returned for each call, the privacy budget is only decremented once per saved query name.

[xyaoinum]

FYI WICG/shared-storage#203 is a recent spec change we've made to include an interestGroups() API. This API, accessible from the shared storage worklet, returns the associated Protected Audience interest groups. It provides the Protected Audience buyer with a better picture of what's happening with their users, allowing for Private Aggregation reports.

[dmdabbs]

Thank you. Assume the API access will expand when/as PA lands its extension of IG expiries from 30 to 90 days.

[jkarlin]

FYI WICG/shared-storage#209 adds web locks support to Shared Storage writes and worklets to aid sequenced reads and writes when shared storage tasks are run in parallel (e.g., across tabs). The web locks have a partitioned space and one cannot wait on a lock outside of the worklet environment, so as to prevent exfiltrating shared storage data.