#807: Storage Access API
Discussions
Comment by @johannhof Jan 18, 2023 (See Github)
cc @cfredric @helenyc
Discussed
Feb 1, 2023 (See Github)
agreed to close
Discussed
Feb 1, 2023 (See Github)
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.
Comment by @hadleybeeman Feb 15, 2023 (See Github)
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.
Comment by @annevk Feb 15, 2023 (See Github)
Thanks @hadleybeeman (and TAG)!
OpenedJan 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:
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.
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