Comments (9)
Agreed, leaving this specifiable by the implementer makes sense to me. Even within Chromium there may be different embedders that wish to have different time constraints on these grants.
from storage-access.
That sounds fine to me as well. BTW I updated that wiki page to fix the description of Safari's behaviour, apologies for our mistake!
from storage-access.
I added a section called "Scope of Storage Access" in 32e1d3f. As noted there, if storage is frame-specific, it's not clear how age-out beyond the lifetime of the page (or iframe) could work.
from storage-access.
Resetting the expiration based on successful usage seems like it would solve #8 and would prevent people from having to login every 30 days. Would we be willing to add something to the spec about that or would that also be up to the implementation?
from storage-access.
Resetting the expiration based on successful usage seems like it would solve #8 and would prevent people from having to login every 30 days. Would we be willing to add something to the spec about that or would that also be up to the implementation?
WebKit’s implementation already does this, for that reason. Granted storage access through the Storage Access API counts as user interaction as first party (=renews the time stamp) in the eyes of ITP.
Since I don’t think any other browser is deleting website data based on user interaction like ITP (true?), I’ve been reluctant to add such details. I’ll add such a section if there is interest from other implementers.
from storage-access.
On Firefox side we would like to suggest automatically renewing storage access in any of the following cases:
- On successful use of the storage access API (in a cross-origin iframe)
- On any user interaction with a cross-origin iframe that already has storage access granted (this is to avoid developers hanging storage access requests onto unrelated button clicks as a hack to renew storage access, or having to show interstitial "yes I want to keep the site working" buttons)
We could standardize on these (the renewal mechanism) and leave the expiry mechanism (after x days of y kind of usage) implementor-specific.
Note that in Firefox "losing storage access" is technically a different thing than getting storage "purged" through the deletion mechanisms that both Firefox and Safari implement. However, the criteria for the two events are essentially the same (no user interaction in 45 days) and they are somewhat coupled in our code base. So this is very similar to Safari now, to the point where it might make for a good developer experience to call out the deletion mechanism explicitly.
from storage-access.
On Firefox side we would like to suggest automatically renewing storage access in any of the following cases:
- On successful use of the storage access API (in a cross-origin iframe)
- On any user interaction with a cross-origin iframe that already has storage access granted (this is to avoid developers hanging storage access requests onto unrelated button clicks as a hack to renew storage access, or having to show interstitial "yes I want to keep the site working" buttons)
I think this is good. Two notes:
- I assume that "successful use of the storage access API" means "being granted storage access through the API." Being denied could also be "successful use." :)
- "Any user interaction with a cross-origin iframe" should be an alternative to the above point, so that user agents don't have to do both.
That should ensure that interaction in a cross-site iframe counts as first party interaction if the interaction either results in storage access or happens during storage access.
We could standardize on these (the renewal mechanism) and leave the expiry mechanism (after x days of y kind of usage) implementor-specific.
Note that in Firefox "losing storage access" is technically a different thing than getting storage "purged" through the deletion mechanisms that both Firefox and Safari implement. However, the criteria for the two events are essentially the same (no user interaction in 45 days) and they are somewhat coupled in our code base. So this is very similar to Safari now, to the point where it might make for a good developer experience to call out the deletion mechanism explicitly.
from storage-access.
I assume that "successful use of the storage access API" means "being granted storage access through the API." Being denied could also be "successful use." :)
Your assumption is correct. A user deny will not count here.
"Any user interaction with a cross-origin iframe" should be an alternative to the above point, so that user agents don't have to do both.
I don't see how this alternative is different. If you are renewing a permission, isn't it required that the iframe already has the storage access granted?
We added the changes suggested by @johannhof to our implementation in Firefox, shipped in Firefox 97.
from storage-access.
Standardizing the "renewal" mechanism (which we should still do) is somewhat blocked on #121 as that would tell us how to tell the browser to renew the permission or storage access map.
from storage-access.
Related Issues (20)
- Fix references to un-exported definitions in other specs. HOT 2
- hasStorageAccess() deals with promises in parallel HOT 2
- Promise resolution in "determine the storage access policy" seems wrong? HOT 6
- Editorial: stop using first/third-party as terms
- Reloading frame after granted storage access to enable efficient site isolation HOT 8
- Editorial: Remove comments referencing lines of code
- Editorial: Consider removing implementation-defined steps because we have requesting permission to use HOT 1
- How does storage access interact with Dedicated, Shared and Service Workers? HOT 38
- Simplify WebDriver API for blocking cross-site cookies HOT 7
- [Per-frame] Permission grants are usable by cross-site iframes HOT 2
- hasStorageAccess() always queues a task to resolve with the environment's boolean? HOT 8
- Top-level calls to navigator.permissions.query for SAA should probably return "granted"
- Feature request: Auto-grant storage access without requiring user interaction or explicit API call in cases determined to be safe HOT 4
- Clarify intended semantics of `document.hasStorageAccess` HOT 5
- Clarify browser specific divergence with requestStorageAccess HOT 4
- Shared worker use cases doesn't seem to work HOT 3
- Storage Access API (requestStorageAccess) HOT 7
- Request Storage access Page Security model HOT 2
- Definition of Unpartitioned data incorrect/inconsistent
- Cookie store changes unspecified HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from storage-access.