-
Notifications
You must be signed in to change notification settings - Fork 69
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
Extending Storage Access API (SAA) to non-cookie storage #898
Comments
@bvandersloot-mozilla (StorageAccess is primarily a privacy/anti-tracking concern). |
See the original discussion and Privacy CG proposal. There is no privacy concern here. Unpartitioned storage offers no benefit to attackers over unpartitioned cookies. Instead the question is whether the API is reasonable. @asutherland and @annevk offered varying degrees of pushback on localStorage and sessionStorage because they are sync. I believe this proposal resolves @asutherland's concerns though. This call returns a handle, rather than trying to use storage buckets. Each storage type is opt-in, making it a developer choice if it is acceptable to degrade performance. But, it may be worth a second look. |
I'm generally happy with the consensus direction we ended up with in privacycg/storage-access#102 through the current timestamp. The API described in the proposed solution seems consistent-ish with that but I would like to see the proposal expanded on, especially in terms of the semantics of "all" which was not/has not yet been discussed on privacycg/storage-access#102. Specifically, I can see an advantage to developers of being able to say "I want all the new storage API endpoints that show up in the future too", but it would be nice then to be sure that something like I know it's frequently explicitly discouraged for people to put WebIDL in explainers, but since Blink seems to be at the prototyping stage already, it likely does make sense to have some draft WebIDL and spec language around the relationship to the Storage spec's endpoint terminology. |
I agree that 'all' has tenuous value, to some extent it's there for developers who are testing or prefer convenience. I'm not sure I like the idea of an 'all, except for' feature. Developers who aren't into the convenience of 'all' should probably just be requesting the specific APIs they want. I agree about WebIDL, if/once the explainer is adopted by the PrivacyCG I plan to put up a PR to modify the existing spec: https://privacycg.github.io/storage-access/. |
Two additional explainers (each of which is an extension to Storage Access API (SAA) to non-cookie storage) have been published! Explainer: Extending Storage Access API (SAA) to omit unpartitioned cookies Explainer: Extending Storage Access API (SAA) to Shared Workers Would it be possible to get review on this issue of those as well? |
Request for Mozilla Position on an Emerging Web Specification
@
-mention GitHub accounts): @arichiv @johannhofOther information
We propose an extension of the Storage Access API (backwards compatible) to allow access to unpartitioned (cookie and non-cookie) storage in a third-party context, and imagine the API mechanics to be roughly like this (JS running in an embedded iframe):
// Request a new storage handle via rSA (this should prompt the user)
let handle = await document.requestStorageAccess({all: true});
// Write some cross-site localstorage
handle.localStorage.setItem("userid", "1234");
// Open or create an indexedDB that is shared with the 1P context
let messageDB = handle.defaultBucket.indexedDB.open("messages");
The same flow would be used by iframes to get a storage handle when their top-level ancestor successfully called rSAFor, just that in this case the storage-access permission was already granted and thus the rSA call would not require a user gesture or show a prompt, allowing for “hidden” iframes accessing storage.
The text was updated successfully, but these errors were encountered: