Storage Access API

[johannhof]

TAG auch!

I'm requesting a TAG review of the Storage Access API.

User Agents sometimes prevent content inside certain iframes from accessing data stored in client-side storage mechanisms like cookies. This can break embedded content which relies on having access to client-side storage.

The Storage Access API enables content inside iframes to request and be granted access to their client-side storage, so that embedded content which relies on having access to client-side storage can work in such User Agents.

• Explainer¹ (minimally containing user needs and example code): https://github.com/privacycg/storage-access#readme
• Specification URL: https://privacycg.github.io/storage-access/
• Tests: https://wpt.fyi/results/storage-access-api?label=experimental&label=master&aligned
• User research:
• Security and Privacy self-review²: https://github.com/privacycg/storage-access/blob/main/tag-security-questionnaire.md
• GitHub repo (if you prefer feedback filed there): https://github.com/privacycg/storage-access
• Primary contacts (and their relationship to the specification):
  • Johann Hofmann (@johannhof), Google Chrome, Editor
  • Anne Van Kesteren (@annevk), Apple WebKit, Editor
  • Benjamin VanderSloot, (@bvandersloot-mozilla), Mozilla Firefox, Editor
• Organization(s)/project(s) driving the specification: Google, Apple, Mozilla
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • Proposal: Storage Access API whatwg/html#3338 (mostly for historical context, may not fully reflect current views of participants or their organizations)
  • Adopt Storage Access API as a deliverable privacycg/proposals#2
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5612590694662144

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: We are looking to send an intent to ship in Chrome within the next few upcoming releases (M111 - M113)
• The group where the work on this specification is currently being done: Privacy CG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG (Fetch/HTML)
• Major unresolved issues with or opposition to this specification:

With the changes I mention below, we have been able to resolve most points of contention between implementers. There remains work and open issues that the editors consider critical to resolve before we attempt to standardize. None of it should present fundamental concerns with the specification itself.

There is still some implementation-defined behavior in the prompt strategy of different browsers (e.g. prompts vs. heuristics or list-based grants), but the spec makes an effort to preserve interoperability despite these differences.

• This work is being funded by: Google, Apple, Mozilla

You should also know that we have recently undergone a major design revision to address security concerns, integrate with the permissions API and better align the API behavior between implementations, with fewer pieces of unspecified or implementation-defined behavior remaining.

We’re satisfied with the recent changes but because of their scope they may have left some rough edges and follow-up work in the spec.

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

🐛 open issues in our GitHub repo for each point of feedback

[johannhof]

cc @cfredric @helenyc

[hadleybeeman]

Hi @johannhof, @annevk and @bvandersloot-mozilla! We have reviewed this and don't think we can make it better. Your use cases are clear and compelling, and the privacy controls that have come out of your non-goals (especially cross-site tracking prevention) are helpful to protect users in a world without third-party cookies. It's also clear that you've struck a series of compromises to make things work for all the implementers involved, which we applaud.

We don't want to hold you up, so we are going to close this issue. Let us know if you need anything else from us.

[annevk]

Thanks @hadleybeeman (and TAG)!