This document goes into how fenced frames interact with the various states associated with a document/site/origin e.g. cookies, storage etc. as well as the state associated with the corresponding network requests e.g. cookies, http cache etc.
Note that this document does not go into how unpartitioned storage/cookie access for modes like "read-only" and "unpartitioned-storage" will be supported.
It is important to note for this discussion, that even though fenced frames are embedded in another document, they are treated as top-level browsing contexts as explained here. This implies that we need to consider it’s interaction with both unpartitioned state (for fenced frame tree root) and partitioned state (for iframes nested in a fenced frame tree). The rest of the sections will detail how both of these states will be unique inside a fenced frame tree. A fenced frame is an isolated browsing context, with a carefully limited flow of information in and out. While in some cases a fenced frame is allowed to make network requests, we need to ensure that this does not open up new communication paths between the fenced frame and any other browsing context.
A fenced frame tree (the fenced frame root and any nested iframes) cannot access the same storage as another frame (top-level or nested) even though they may have the same storage key (same origin and top-level site). Once storage partitioning is the default, fenced frames and their nested iframes will end up with storage keys of <fenced-frame-root-site, fenced-frame-root-origin> and <fenced-frame-root-site, current-frame-origin>, respectively (existing storage key spec). This is because fenced frame root is considered a top-level browsing context. But these keys are not unique and will allow sharing state with other frames outside this tree. To achieve uniqueness, we would be using the nonce-based storage key where all frames inside a given fenced frame tree will have the same nonce. Note that the same storage key will also partition origin-based communication channels like broadcastChannel. This will allow all same-origin frames within the tree to communicate with each other while disallowing any state sharing/communication outside the tree. The storage keys would then be <fenced-frame-root-site, fenced-frame-root-origin, nonce-for-this-tree> and <fenced-frame-root-site, current-frame-origin, nonce-for-this-tree>, for the fenced frame root and a nested iframe, respectively.
Note that this is a dependency on the storage partitioning workstream to be fully implemented and it will not be available in the very first experiment of fenced frames but will eventually be available. So for the first version, storage/service workers/broadcast channel will be unpartitioned and that will go away once storage partitioning implementation is complete. We will update the timelines here as and when they are clear. Cookies, however will be partitioned from the first version itself. See cookies section below.
From a developer perspective, the same document/scripts can be reused for both fenced frames or for regular frames. That’s because storage access APIs are still allowed and do not return an exception. The difference that developers would need to understand is that none of the storage would be shared by any frame outside the tree.
The network isolation project attempts to prevent all persistent and session network data the browser stores on behalf of and about websites from being used to correlate the activity of a user across top-level browsing contexts for different sites. The state partitioned using network isolation keys include the http cache, Socket Pools etc. Similar to storage partitioning described above, fenced frames cannot share network state with other frames, even those with the same network isolation key (same top-level and frame sites). To achieve uniqueness of the network partition for each fenced frame tree, we would be using the nonce-based network isolation key (NIK spec) where all frames inside a given fenced frame tree will have the same nonce. This will allow all same-origin frames within the tree to access the same network partition. That enables them to access the same cached entries, for instance. The network isolation keys would then be <fenced-frame-root-site, fenced-frame-root-site, nonce-for-this-tree> and <fenced-frame-root-site, current-frame-site, nonce-for-this-tree>, for the fenced frame root and a nested iframe, respectively.
The partitions of network state are not really visible to the developer except for the http cache functionality. All same-site frames within a single fenced frame tree will access the same cache partition. Developers would need to understand that the cache partition would not be shared with any frame outside this fenced frame tree.
Since fenced frames are treated as top-level browsing contexts, they would by default have access to the unpartitioned cookies for that site. But that would allow sharing state with another same-site top-level page which is not permissible, given that fenced frames do not, by default, get access to unpartitioned storage. Therefore, any access to unpartitioned cookies will be disallowed for fenced frames.
In conjunction with the partitioned cookies effort (CHIPS), the cookies inside a fenced frame tree can access partitioned cookies, but they would use a nonce to be unique to a fenced frame tree (similar to storage partitioning). This approach has the advantage of treating cookies and storage consistently.
Alternatively, cookies can be blocked but that would require special logic for fenced frames. Using unique and transient cookie partition as given above would align well with existing cookies infrastructure.
The same document can continue to work for a fenced frame as for a regular frame, except that the cookie API calls and network requests will set/get cookies which are set in a transient and unique partition.