Explain the differences between sandboxed frames

[jonathanKingston]

I think the explainer would benefit from a document/section that explains the core differences to sandboxed iframes like the following:

<iframe src=bloburl sandbox="allow-popups allow-top-navigation-by-user-activation" />

Sandboxed frames are treated as a top level origin if they're opaque (!allow-same-origin).

• My understanding is the core difference here (in opaque-ads) is that the frame has an origin but is isolated from the embedding frame.
• https://github.com/WICG/fenced-frame/blob/master/explainer/opaque_src.md#proposed-solution seems like a non serializable URL object that once loaded has a serializable URL inside the frame.

I'm quite interested if the existing primitives of the web can be used rather than these new ones.

[shivanigithub]

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.

[jonathanKingston]

Right so the core differences as I see them:

1. 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?
2. 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.

[shivanigithub]

Right so the core differences as I see them:

1. 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.

2. 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).

[domfarolino]

Given that there are no outstanding action items or questions on this issue, I'll go ahead and close this. Thanks.