Comments (5)
I don't think there is a future like this, in the context of COEP (see below)
However, maybe we should switch back toward a string value, so that future web browser developer can potentially repurpose the "anonymous" attribute in a different way, potentially (?)
The goal was to avoid the problem with COEP: its requirement is recursive. When you want to embed a website, you need to ask the 3rd party to deploy COEP, and the 3rd party of your 3rd party to deploy COEP too. In most cases, it is not possible.
So the anonymous bit is inherited and can only become more restricted. This is similar to sandbox flags in some sense. This guarantee when using anonymous iframe that you aren't going to break the iframe. It is guaranteed to load.
If we allowed to express "false", this would break the chain and won't be able to provide this guarantee anymore.
Also, allowing multiple change along the ancestor chain would force us to update some algorithm and check the whole chain instead of depending only on the parent. Doable, but not ideal. There is also the question of popups.
from anonymous-iframe.
I haven't fully thought this through, but a way to think of this feature might be as a COEP policy. It is then conceivable that a nested document could meet that COEP requirement in another way. Of course, given the way this is structured the embedder would have to know that in advance and undo the "forced COEP" somehow.
Have you tried to imagine this feature as a COEP policy rather than a new kind of policy? (Happy to open a new issue for this if you prefer.)
from anonymous-iframe.
Have you tried to imagine this feature as a COEP policy rather than a new kind of policy?
This was the original idea. Then, we had 3 meeting during Feb/March 2021, which caused us to reconsider it, and put anonymous iframe out of COEP:credentialless. I realize the necessary justification isn't yet part of the "alternatives considered" section. Please let me some time to update this section. I will let you know when it's updated.
Anonymous iframe affects the credentials of the navigation request, so we can't really rely on the navigation's response later for a potential override/inherit decision at the child level.
So the parent is the only one who can make the decision, prior to sending the navigation request. However, it can still be part of its own COEP policy like you said. However, this would be a "global" state and developer wouldn't have a way to make the appropriate decision on each individual <iframe>.
It is important, because there are website containing a mix of <iframe> it controls where credentials play a role, and some <iframe> outside of their own control, like ads.
With COEP:credentialless
you can make the decision at the individual request level, by switching the request.mode to CORS and request.credentials to "include".
We need something similar for the <iframe> element. This became <iframe credentials="xxx">. Then it became <iframe anonymous> (see why).
from anonymous-iframe.
I was thinking of something where you'd still have <iframe x>
, but the result is as if the newly navigated document ends up with Cross-Origin-Embedder-Policy: forced-credentialless
or some such. But reflecting on it a bit more I suspect that's not great as this ends up impacting all requests, not just "no-cors" requests. And COEP thus far has been strictly about the latter.
(@smaug---- was wondering if this could be part of a larger whole somehow and that made me think along these lines, but I can't quite figure it out.)
from anonymous-iframe.
I added an "alternative considered" about using some kind of COEP:credentialless top-level state:
https://wicg.github.io/anonymous-iframe/#alternatives-coep-credentialless
Cross-Origin-Embedder-Policy: forced-credentialless or some such. But reflecting on it a bit more I suspect that's not great as this ends up impacting all requests, not just "no-cors" requests. And COEP thus far has been strictly about the latter.
Yes, that's right.
One thing we wanted with anonymous iframe, is being able to ensure the iframe's document to load. Using an ephemeral storage area is different from forcing COEP:credentialless
. The main differences are:
COEP: credentialless
causes no-cors request to omit credentials, so the embedded website may be broken. With the anonymous iframe, it will behave as if it was the first visit ever. It can set some cookies using JS and issue some fetch with those cookies. It won't break the website.- COEP:credentialless only affect the network requests issued by the website, but we need to protect from any kind of credentials being leaked through Spectre. This is more than just cookies. This is about every kind of storage API.
I am wondering if @smaug---- would have some alternative to anonymous iframe.
from anonymous-iframe.
Related Issues (15)
- `window.anonymous` usage in the wild HOT 7
- Consider to rename "anonymous" to "credentialless" or some such HOT 14
- Policy container HOT 1
- isAnonymouslyFramed naming should probably be anonymouslyFramed HOT 2
- window.anonymous reference leftover in explainer HOT 1
- "This nonce will be recomputed every time the top-level frame navigates." HOT 2
- Forcing all iframes to be credentialless / dealing with iframes created by external scripts HOT 2
- How could a credentialless iframe use BroadcastChannel? HOT 6
- Define interaction with requestStorageAccess() HOT 1
- Invalid w3c.json data
- Clarify/enable postMessage behaviour with SharedArrayBuffer HOT 5
- Interaction with sandbox attribute HOT 2
- Meta: overtaking Window interface definition? HOT 2
- Broken references in Iframe credentialless 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 anonymous-iframe.