-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Storage Access API #807
Comments
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. |
Thanks @hadleybeeman (and TAG)! |
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
The text was updated successfully, but these errors were encountered: