Comments (4)
IIUC the question is about why we haven't used unique origin for fenced frames similar to !allow-same-origin. There were a few considerations:
- having opaque origin for a fenced frame and the way sandbox flags inheritance works, it would imply any nested iframe in the fenced frame tree would also have a unique origin. That would imply no same-origin communication within the fenced frame tree.
- There are many APIs which would simply throw exceptions for opaque origins e.g. storage access. To be more compatible with the web platform and not having to throw exceptions, we preferred giving the fenced frame tree a nonce-based storage partition, as described here.
The other difference with sandbox iframes is that even if they have a unique opaque origin they can still have communication with the top-level frame via window.top, window.parent, joint history, post message (I think) etc. and fenced frames do not have any of those.
from fenced-frame.
Right so the core differences as I see them:
- Fenced frames have an origin, the embedding document can't read them.
i. The nonce origin prevents two<fenced-frame>
communicating even if they have the same origin?
ii. The nonce origin allows example.com frames to communicate to other example.com frames within the<fenced-frame>
iii. The nonce origin prevents<fenced-frame>
to example.com storing/communicating to example.com top-level tabs.
iiii. Can the same nonce URL be passed to two frames? - Embedding document APIs are blocked (window.top, postMessage etc)
Are there any other parts I'm missing?
Could this be instead handled by:
- Allowing construction of nonce URLs that are opaque to the document
- Having a flag on iframes to prevent communication between frame and parent.
from fenced-frame.
Right so the core differences as I see them:
- Fenced frames have an origin, the embedding document can't read them.
i. The nonce origin prevents two<fenced-frame>
communicating even if they have the same origin?
Note that fenced frames don't have nonce in the origin but in the storage partitioning and cookie partitioning keys. And storage partitioning key also partitions broadcastChannel thus restricting any same-origin communication between 2 different fenced frame trees.
ii. The nonce origin allows example.com frames to communicate to other example.com frames within the
<fenced-frame>
Since the origin doesn't contain the nonce as mentioned in the above point, any same-origin iframes withing the fenced frame tree will continue to stay same-origin. Note that the storage partitioning key's nonce is the same for all iframes in the same fenced frame tree.
iii. The nonce origin prevents
<fenced-frame>
to example.com storing/communicating to example.com top-level tabs.
Yes, because of the same reason as mentioned in (i)
iiii. Can the same nonce URL be passed to two frames?
do you mean the urn:uuid? There is nothing stopping the embedder to create two fenced frames with the same urn:uuid but they will both have different storage key nonce and so cannot communicate with each other.
- Embedding document APIs are blocked (window.top, postMessage etc)
right.
Are there any other parts I'm missing?
There are also other side channels that can be used as communication channels between the fenced frame and the embedding frame, and are therefore restricted. e.g. no joint history (see here), no permission policy and cspee delegation (see here), no programmatic focus switch between fenced frames and embedding frame, no resizing allowed, intersection observer to be changed (we are working on the specifics there) etc. (more of these side channels are listed in this document)
Essentially sandbox iframes were not a privacy boundary but more of a security boundary while fenced frames need to create a privacy boundary even in the scenario where two parties are colluding with each other to communicate information, which gives fenced frames a very different threat model.
Could this be instead handled by:
- Allowing construction of nonce URLs that are opaque to the document
- Having a flag on iframes to prevent communication between frame and parent.
As discussed above, there are multiple channels that need to be mitigated for fenced frames which makes them different from iframes. Spec-wise in many ways they behave like top-level browsing contexts (window.top/parent etc.) so if the API was iframe it would still require spec and implementation changes for them to behave like top-level browsing contexts. Iframes already have a combination of flags e.g. sandbox, allow, cspee etc. and having a new flag that governs a bunch of behavioral characteristics would be a hard to follow in how it interacts with the other flags. Infact there are discussions ongoing about considering multiple fenced frame elements for its different modes (issue).
from fenced-frame.
Given that there are no outstanding action items or questions on this issue, I'll go ahead and close this. Thanks.
from fenced-frame.
Related Issues (20)
- Can Shared Storage be used from Fenced Frames during Origin Trials? HOT 2
- Store the beacon's initiator origin in the pending event struct
- How do we embed tags in turtle dove model within fenced frames which return dynamic data from an ad-server HOT 1
- [Spec] Spec "substitute macros" helper.
- [Specification] Spec should clearly outline fenced APIs + fencing principles HOT 4
- Say something about what eventTypes are valid HOT 4
- Add example to introduction
- Spec an API to tell if an opaque-ads fenced frame can load in a given context HOT 1
- Proposal for changes to fenced frames urns/attributes HOT 2
- Capture scroll bubbling and scrollIntoView() behavior differences HOT 1
- Need to split the feature to individual primitives and figure out the best ways to support them HOT 4
- Spec changes are not being published
- https://github.com/publicsuffix/list/commits/master.atom
- What is the behavior of reportEvent in iFrame? HOT 2
- broken link HOT 2
- Define what descendant nodes of a fenced frame element represent
- Remove fenced frame config mapping when urn iframes are removed HOT 1
- Permissions policy "container policy" check should be sufficiently fenced
- Explainer: mention the developer-only flag to enable `FencedFrameConfig` constructor HOT 2
- Incompatible with a CSP sandbox HOT 4
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 fenced-frame.