#807: Storage Access API

Visit on Github.

Opened Jan 18, 2023

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.

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

Discussions

2023-02-13

Minutes

agreed to close

2023-02-13

Minutes

Amy: the conclusion was this is good but we wanted to spend some time going through the detail.

Hadley: we looked at it and we didn't comment ... We're pretty happy with it. Work is being done in the Privacy CG... They are happy with it. It's got lots of multi-stakeholder support.

Dan: can we close it?

Hadley: we were happy to greenlight it - but do we keep it open for "storage access for origin"

Dan: that's a separate review anyway...

Hadley: will leave a closing comment.