Comments (17)
@johnwilander @annevk Would you mind taking a look at this idea, or advising me on how to properly ask for feedback? I'm not very clear on the etiquette for contributing here.
from storage-access.
Hi! Sorry for the delay. This was talked about in the context of per-frame vs per-page storage access. We eventually agreed to per-page storage access which introduces the problem you're trying to solve.
Looking at real world use cases though, the user has just interacted with iframeA from thirdParty.example, the frame called the Storage Access API, and the frame was granted access. What immediately needs to happen in sibling frames? The user is not interacting with them. Are you thinking of speculatively fetching resources in case the user interacts with iframeB from thirdParty.example?
from storage-access.
A few cases:
-
Like you describe: iframes iframeA and iframeB both from thirdparty.example, say a social embed which allows the user to like a piece of embedded content. The user interacts with iframeA, and approves a storage access prompt. When the user then scrolls and looks at iframeB, it still does not reflect whether the user has already liked the associated content (or any other personal state), even though the user has already approved access. But when the user does anything that causes iframeB to check, it finds that it already has access. thirdparty.example can fix this behavior by polling hasStorageAccess periodically, but this wakes up the CPU frequently and wastes resources.
-
A single iframe from thirdparty.example uses multiple libraries with different authors. When the user interacts with any component in the iframe that requires storage access and it is granted, the other components have storage access but don't know it, so they appear to the user not to be responding to the prompt approval (which, from their perspective, applies to the page as a whole) correctly. Fixing this either requires that the author to tightly couple and coordinate this across these various libraries (i.e., building this exact API themselves, and trying to make sure every call site to
requestStorageAccess
hooks into it), or the library authors can each pollhasStorageAccess
.
I will note that I'm particularly motivated by another use case that we're considering using Storage Access API for, which is uncredentialed prerendering (in which a prerendered page would be denied storage access in much the same way as a third-party frame might, and storage access would be granted only if the user chose to navigate to the prerendered page). In this case, the grant of storage access is also a result of an action outside the affected frame, and so it's necessary for the page to be able to observe it, preferably without polling.
from storage-access.
2. Fixing this either requires that the author to tightly couple and coordinate this across these various libraries (i.e., building this exact API themselves, and trying to make sure every call site to
requestStorageAccess
hooks into it), or the library authors can each pollhasStorageAccess
.
+1. Say we had three components:
- A login box.
- Something that handles user visual preferences, eg font size or theme.
- A button which lets the user opt in to storage access.
On page load, the login box knows it doesn't have storage access, so it puts itself into an indeterminate state. It wants to update this if storage becomes available, but it doesn't want to request storage access.
The visual preferences component may want to change page appearance once storage access is gained.
The button is the thing that calls requestStorageAccess
when clicked. If storage access is gained by some other means, this button should go away, as it's no longer needed.
In this example, if we don't have something like storageAccessAvailable
, this app will have to reinvent it using something like BroadcastChannel
, and components which aren't built by the same team may end up using a different system which can get out of sync. The only reliable system is polling.
There's a similar issues with the storage
event on localstorage. If storage changes, the event is fired on other window instances. This means that components on the same page won't hear about the change unless a custom pub/sub is created, or components resort to hacks like each creating an iframe to get another window object for the event. It'd be good to avoid the need for more hacks 😄.
from storage-access.
As I mentioned in #62 this seems reasonable to Mozilla. Did you also consider giving a signal before the switch happens to allow for any migration?
from storage-access.
I admit to not being completely current on the state of pre-storage-access (i.e., document.hasStorageAccess()
resolves to false) behavior of storage APIs (e.g. this doesn't seem to correspond with the current notion).
I think a migration signal might be interesting (though I think this issue makes sense independently from it). If I had to sketch one out, I would imagine it wouldn't affect the shape of this idea, because you could do something like:
document.addEventListener('beforestorageaccess', async e => {
let readyToMigrate = (async function() {
// open a database, fetch some rows, etc
// exactly what must be pulled out depends on whether
// database connections, transactions, etc. can persist
// across the change
})();
e.waitUntil(readyToMigrate);
let dataToMigrate = await readyToMigrate;
await document.storageAccessAvailable;
// write into the newly available database
});
The semantics of such a beforestorageaccess
event would be entwined with the semantics of the storage partitioning (which I think are still evolving -- and raise questions like which frame is responsible for migrating data, if they share a partition before), but I think in all likely scenarios fit naturally with document.storageAccessAvailable
.
from storage-access.
Yeah, no disagreement there. (FWIW, MDN matches what we currently ship on release, Firefox Nightly has where we want things to go. Which is approximately that third parties have partitioned storage by default and can get to non-partitioned storage for all same-origin documents within an agent.)
from storage-access.
This is generally a reasonable idea and it doesn't look problematic from a privacy perspective. We still consider this something to have in the next version of the spec, but not for immediate graduation. It would be interesting to see if there are real-world problems that we could solve with such a feature right now.
from storage-access.
Adding a +1 to this request - For Google Workspace, there are scenarios with multiple embeds in the same top-level page (for example, a third-party site that embeds multiple Google Docs, or a Google Doc + a Google Calendar appointment booking page). Having some way for embeds to automatically know when storage access has been granted is key to providing a smooth user experience.
from storage-access.
Note that with #138 we have added formal integration with permissions, and I'll try to verify and test that storage access availability can be observed through the Permissions API. I'll close this issue once that's done.
from storage-access.
I'm not sure that addresses all cases from OP. You can observe that you can now call requestStorageAccess()
in your document, but you can't observe that someone else has done so. So depending on the use case you might still want some kind of signal that requestStorageAccess()
has been successfully invoked for your document.
from storage-access.
I believe you ought to be able to use the permissions API to observe changes which might be caused by other documents:
navigator.permissions.query({ name: 'storage-access' }).then(async (status) => {
if (status.state === 'granted') {
await document.requestStorageAccess(); // should auto-resolve due to the existing grant
doSomethingWithThirdPartyCookies();
} else {
status.addEventListenever('change', () => reactToPermissionChange(status));
}
});
from storage-access.
Correct. I'm talking about observing a successful requestStorageAccess()
invocation in your document, no other documents involved. That's one of the scenarios OP discusses, where you have multiple libraries interested in the outcome of that call. Of course all these libraries could call requestStorageAccess()
themselves, but that might also have inadvertent side effects.
from storage-access.
I don't see why @cfredric's code doesn't work for these libraries. Through the permissions API they can ensure that they won't prompt the user and will only call rSA when the main UI code has done so. What might be missing from the example is a hasStorageAccess
call to avoid setting up the permissions part if it's not necessary, but otherwise it seems sufficient to me.
from storage-access.
That pattern encourages swapping Storage Access as soon as possible by all code that wants to do something once Storage Access is there. It doesn't allow for code reacting to Storage Access becoming available and leaving a single piece of code in charge of when to actually make the swap.
from storage-access.
Yeah, that's fair, though I'd personally consider that a lower priority until we have evidence that this is an issue. It feels like allowing cross-frame observation of grants is more impactful but I could be wrong. Certainly don't want to block adding that kind of ability.
from storage-access.
I still think @jeremyroman's suggestion makes sense and as far as I can tell he specifically made it for the single-document case, only later elaborating on multiple documents.
I agree it's not quite a priority and #154 might also change things around, but I'd like to keep this open for now.
from storage-access.
Related Issues (20)
- Synchronous hasStorageAccess? HOT 4
- Use (top-level site, embedded site) permissions
- Should we expose "denied" storage access permissions?
- 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
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.