You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In particular if you allow the Storage category to have its keying relaxed, there's an argument to be made that BroadcastChannel and shared/service workers ought to be blocked rather than have additional keying as sites could end up in a state where they have both third-party and first-party BroadcastChannel, for instance. And they cannot really be told apart either other than the site knowing when it allocated them relative to its current Storage Access API state.
Note that it's not a good solution to let part of the Storage category have its keying relaxed and part of it not. Sites often use multiple storage APIs for various bookkeeping purposes. Making their data inconsistent with each other is bad news. Blocking on the other hand doesn't really have that problem and might even be doable given that BroadcastChannel and shared worker are not supported by Safari.
Effectively this is a variant of the issue with same-origin frames having synchronous communication access being able to end up in different states. (Though we made a decision there to not let that happen.)
The text was updated successfully, but these errors were encountered:
This is also discussed in #9 and I don't get the impression there is interest in this, apart perhaps for particularly bad actors so standards should allow for it being blocked (and already do as far as I'm aware).
This is related to #7.
In particular if you allow the Storage category to have its keying relaxed, there's an argument to be made that BroadcastChannel and shared/service workers ought to be blocked rather than have additional keying as sites could end up in a state where they have both third-party and first-party BroadcastChannel, for instance. And they cannot really be told apart either other than the site knowing when it allocated them relative to its current Storage Access API state.
Note that it's not a good solution to let part of the Storage category have its keying relaxed and part of it not. Sites often use multiple storage APIs for various bookkeeping purposes. Making their data inconsistent with each other is bad news. Blocking on the other hand doesn't really have that problem and might even be doable given that BroadcastChannel and shared worker are not supported by Safari.
Effectively this is a variant of the issue with same-origin frames having synchronous communication access being able to end up in different states. (Though we made a decision there to not let that happen.)
The text was updated successfully, but these errors were encountered: