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.