From 005d68fbb070ca4d4ef53ed63b52231c201ae7a6 Mon Sep 17 00:00:00 2001 From: Liam Brady Date: Mon, 14 Oct 2024 18:48:04 -0400 Subject: [PATCH] Update explainers to include permissions inheritance behavior (#136) * Update explainers to include new permissions behavior * add link * address comments * update links to external docs * link to WICG instead of personal github --- README.md | 9 ++++---- adjacent_work/TurtledoveWorklets.md | 4 +--- .../PrompltessUnpartitionedStorageAccess.md | 4 ++-- explainer/README.md | 22 +++++++++---------- explainer/integration_with_web_platform.md | 12 +++++----- explainer/opaque_ads_use_cases.md | 2 +- explainer/permission_document_policies.md | 15 ++++++++----- ...ons_policy_for_API_backed_fenced_frames.md | 1 + explainer/storage_cookies_network_state.md | 2 +- 9 files changed, 37 insertions(+), 34 deletions(-) diff --git a/README.md b/README.md index b74c84bb..5e44a126 100644 --- a/README.md +++ b/README.md @@ -7,16 +7,15 @@ See the [draft specification](https://wicg.github.io/fenced-frame). The explainer is organized as follows: * What is a fenced frame: the concept, HTML element, security and privacy considerations - * [explainer/README](https://github.com/shivanigithub/fenced-frame/tree/master/explainer) + * [explainer/README](https://github.com/WICG/fenced-frame/tree/master/explainer) * What are the problems being solved/ different modes of fenced frames? - * [Modes/Use cases of fenced frames](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/use_cases.md) + * [Modes/Use cases of fenced frames](https://github.com/WICG/fenced-frame/blob/master/explainer/use_cases.md) * Deep dive in the "opaque-ads" use case which will be the first launch of fenced frames - * [Opaque ads use cases](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/opaque_ads_use_cases.md) - * [Opaque src](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/opaque_src.md) + * [Opaque ads use cases](https://github.com/WICG/fenced-frame/blob/master/explainer/opaque_ads_use_cases.md) * How fenced frames integrates with the web platform. This is a growing list of things and will be added to the documentation - * [Integration with the web platform](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/integration_with_web_platform.md) + * [Integration with the web platform](https://github.com/WICG/fenced-frame/blob/master/explainer/integration_with_web_platform.md) diff --git a/adjacent_work/TurtledoveWorklets.md b/adjacent_work/TurtledoveWorklets.md index 236a777d..89ca9694 100644 --- a/adjacent_work/TurtledoveWorklets.md +++ b/adjacent_work/TurtledoveWorklets.md @@ -43,9 +43,7 @@ Let’s dive deeper into how this environment will be used by looking at the end * **Communication with the page**: Since the worklet has access to user’s interest groups, it cannot share that with the embedding page and thus communication to the embedding page is not allowed. * **Restricted Outputs**: The winning ad output from the worklet needs to be further worked upon by the TURTLEDOVE API for the following aspects: * Confirm if the output is k-anonymous i.e. the same ad is seen by ‘n’ other browsers. If not, re-run the auction logic. - * Map the winning ad url to an opaque url before passing it back to the publisher page. This is detailed [here](https://github.com/shivanigithub/fenced-frame/blob/master/OpaqueSrc.md). - -Here's a [sequence diagram](https://github.com/shivanigithub/fenced-frame/blob/master/TurtledoveSequenceDiagram.png) + * Map the winning ad url to an opaque url before passing it back to the publisher page. ## Isolation characteristics diff --git a/alternate_usecases_analysis/PrompltessUnpartitionedStorageAccess.md b/alternate_usecases_analysis/PrompltessUnpartitionedStorageAccess.md index 53028a67..e991fb81 100644 --- a/alternate_usecases_analysis/PrompltessUnpartitionedStorageAccess.md +++ b/alternate_usecases_analysis/PrompltessUnpartitionedStorageAccess.md @@ -4,7 +4,7 @@ ## Introduction -This document goes into the details of promptless unpartitioned storage access as a potential use case of fenced frames ([privacyCG discussion](https://github.com/privacycg/storage-access/issues/41)). For fenced frames concept and design please see the [explainer](https://github.com/shivanigithub/fenced-frame). +This document goes into the details of promptless unpartitioned storage access as a potential use case of fenced frames ([privacyCG discussion](https://github.com/privacycg/storage-access/issues/41)). For fenced frames concept and design please see the [explainer](https://github.com/WICG/fenced-frame). ## Unpartitioned storage access @@ -27,7 +27,7 @@ Although many of these use cases could be handled with a combination of user ide ### Challenges -requestStorageAccess is used to provide access to unpartitioned storage. When invoked within fenced frames, the goal is to not show a permission prompt, thanks to the communication isolation of a fenced frame. However, that is dependent on mitigating challenges like link decoration, network timing etc. as discussed in the explainer [here](https://github.com/shivanigithub/fenced-frame#challenges) and the thread [here](https://github.com/privacycg/storage-access/issues/41#issuecomment-673057755). +requestStorageAccess is used to provide access to unpartitioned storage. When invoked within fenced frames, the goal is to not show a permission prompt, thanks to the communication isolation of a fenced frame. However, that is dependent on mitigating challenges like link decoration, network timing etc. as discussed in the thread [here](https://github.com/privacycg/storage-access/issues/41#issuecomment-673057755). ## Alternative state machine considered diff --git a/explainer/README.md b/explainer/README.md index 77ff375f..e5a2fe69 100644 --- a/explainer/README.md +++ b/explainer/README.md @@ -42,7 +42,7 @@ The privacy threat addressed is: **The ability to correlate the user’s identity/information on the embedding site with that on the embedded site.** -The different use cases and their privacy models are discussed [here](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/use_cases.md). +The different use cases and their privacy models are discussed [here](https://github.com/WICG/fenced-frame/blob/master/explainer/use_cases.md). ## Design @@ -51,7 +51,7 @@ Fenced frames are embedded contexts that have the following characteristics to p * They’re not allowed to communicate with the embedder and vice-versa, except for certain information such as limited size information. -* They access storage and network via unique partitions so no other frame outside a given fenced frame document can share information via these channels. This is described [here](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/storage_cookies_network_state.md). +* They access storage and network via unique partitions so no other frame outside a given fenced frame document can share information via these channels. This is described [here](https://github.com/WICG/fenced-frame/blob/master/explainer/storage_cookies_network_state.md). * They may have access to browser-managed, limited unpartitioned user data, for example, turtledove interest group. The idea is that the fenced frame should not have access to both of the following pieces of information and be able to exfiltrate a join on those: @@ -64,9 +64,9 @@ The idea is that the fenced frame should not have access to both of the followin * Accessible via an API (e.g., Turtledove) or via access to unpartitioned storage -A primary use case for fenced frames is to load content that depends on values in another partition’s storage. For example, in Turtledove, we pick an ad based on the user's interest groups (which are joined while browsing other sites) and load it in a fenced frame. The URL of the ad reflects the user's interest group memberships, which is a form of cross-site data, therefore we store the URL for the ad creative _opaquely_ in a fenced frame config (details [here](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/fenced_frame_config.md)). The embedder can use this object to load the ad resulting from the Turtledove auction, but can't inspect it to determine _which_ ad won. +A primary use case for fenced frames is to load content that depends on values in another partition’s storage. For example, in Turtledove, we pick an ad based on the user's interest groups (which are joined while browsing other sites) and load it in a fenced frame. The URL of the ad reflects the user's interest group memberships, which is a form of cross-site data, therefore we store the URL for the ad creative _opaquely_ in a fenced frame config (details [here](https://github.com/WICG/fenced-frame/blob/master/explainer/fenced_frame_config.md)). The embedder can use this object to load the ad resulting from the Turtledove auction, but can't inspect it to determine _which_ ad won. -We expect some leakage of information to be possible via network timing attacks. The side channel and some mitigations are described [here](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/network_side_channel.md). +We expect some leakage of information to be possible via network timing attacks. The side channel and some mitigations are described [here](https://github.com/WICG/fenced-frame/blob/master/explainer/network_side_channel.md). ### Fenced frame API @@ -153,12 +153,12 @@ This is called synchronously, and will look at the execution context of the fram Even though a fenced frame is isolated from its embedding context, it cannot be used as a workaround to the security restrictions that the top-level site wants to enforce on the embedding frames, without the knowledge of the top-level site. The design decisions of fenced frames related to security mechanisms like sandbox, csp, permission policy etc. are based on the following principles: * Attributes like cspee, sandbox etc. and headers like frame-ancestors etc. cannot be used as a communication channel with the embedding context. -* Fenced frame should not be able to escalate privileges without the knowledge of the top-level site e.g. all permission policy delegation based features in a fenced frame are therefore disallowed. +* Fenced frame should not be able to escalate privileges without the knowledge of the top-level site. A feature disallowed by a top-level site for a given origin cannot be allowed in a fenced frame of that same origin, since that becomes a security risk. Since this requires the fenced frame learning about what features are allowed for its origin, and since revealing to the fenced frame what features are enabled for what origins are a fingerprinting vector, all permission policy delegation based features are therefore disallowed in fenced frames that don't allow data infiltration. Fenced frames that do allow for data infiltration (i.e. ones loaded with transparent URLs allowing for arbitrary data to be added) can use and inherit permissions policy delegation for features. See: [Fenced frames: permissions and document policies](https://github.com/WICG/fenced-frame/blob/master/explainer/permission_document_policies.md). * There are headers from the fenced frame site that are not honored as they would in an iframe, e.g. frame-ancestors, due to being a privacy leak. This is the reason fenced frames need to be opted in by the site using the opt-in response header. More about security mechanisms are detailed in: -* [Fenced frames and CSP](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/interaction_with_content_security_policy.md) -* [Fenced frames and policies](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/permission_document_policies.md) +* [Fenced frames and CSP](https://github.com/WICG/fenced-frame/blob/master/explainer/interaction_with_content_security_policy.md) +* [Fenced frames and policies](https://github.com/WICG/fenced-frame/blob/master/explainer/permission_document_policies.md) * [Fenced frames and sandbox](https://docs.google.com/document/d/1RO4NkQk_XaEE7vuysM9LJilZYsoOhydfh93sOvrPQxU/edit?usp=sharing) **Secure contexts:** Fenced Frames are only allowed if all ancestor frames are [secure contexts](https://w3c.github.io/webappsec-secure-contexts/), the fenced frame's document is from a [potentially trustworthy URL](https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-url) and all subresources inside the FF will follow [mixed mode restrictions](https://web.dev/fixing-mixed-content/). @@ -167,7 +167,7 @@ More about security mechanisms are detailed in: **xsleaks:** In terms of cross site leak attacks, fenced frames is at least as secure as iframes are and better in some cases by default e.g. always having noopener, no joint history etc. For more details, the fenced frames xsleaks audit can be found [here](https://docs.google.com/spreadsheets/d/1YkQxcQlOd24XmSUQ8RpQU0zINYSTTih8drNibV0LIXE/edit?usp=sharing). -**Process isolation:** Process isolation for fenced frames is detailed [here](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/process_isolation.md). +**Process isolation:** Process isolation for fenced frames is detailed [here](https://github.com/WICG/fenced-frame/blob/master/explainer/process_isolation.md). ## Privacy considerations @@ -177,11 +177,11 @@ The fenced frame’s main goal is to improve privacy by disallowing communicatio * **Initial size and resize:** The API that generates a fenced frame config can pick the initial size that the fenced frame document sees, subject to whatever restrictions it deems necessary for its privacy model. If the initial size is fixed, then any changes the embedder attempts to make to the fenced frame's size will not be reflected inside of it. * **Intersection Observer:** See [Integration with web platform > Viewability](https://github.com/WICG/fenced-frame/blob/master/explainer/integration_with_web_platform.md#Viewability) for discussion of the privacy considerations for the Intersection Observer API. -* **Delegated permissions:** [Permission delegation](https://www.chromestatus.com/feature/5670617353289728) restricts permission requests to the top-level frame. Since fenced frames are embedded contexts, they should not have access to permissions, even if they are treated as top-level browsing contexts. Also delegation of permissions from the embedding context to the fenced frames should not be allowed as that could be a communication channel. This is detailed further [here](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/permission_document_policies.md). -* **Network side channel:** This is detailed more here: [network side channel](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/network_side_channel.md) +* **Delegated permissions:** [Permission delegation](https://www.chromestatus.com/feature/5670617353289728) restricts permission requests to the top-level frame. Since fenced frames are embedded contexts, they should not have access to permissions, even if they are treated as top-level browsing contexts. Delegation of permissions from the embedding context to the fenced frame is a data infiltration channel, and should be disallowed when the privacy story disallows data inflow. This is detailed further [here](https://github.com/WICG/fenced-frame/blob/master/explainer/permission_document_policies.md). +* **Network side channel:** This is detailed more here: [network side channel](https://github.com/WICG/fenced-frame/blob/master/explainer/network_side_channel.md) * **Navigation url:** Since fenced frames are allowed to open popups or navigate the top-level page in some use cases, gated on user activation, the navigation url can carry bits of information out of the fenced frame tree. If the embedder and the destination are same-origin, the information in the url and embedder's info can be joined locally on navigation. This might need mitigations going forward (currently being brainstormed); we plan to add metrics to understand how often this happens in practice. Additionally, this is vulnerable to the network side channel as mentioned above if the embedding site and destination site are colluding (even when not same-origin)---though this is less concerning than for non-navigation network requests, since navigation is only allowed upon user interactions like clicks. -More of these channels exist and the [integration with web platform](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/integration_with_web_platform.md) details them further. +More of these channels exist and the [integration with web platform](https://github.com/WICG/fenced-frame/blob/master/explainer/integration_with_web_platform.md) details them further. ### Ongoing technical constraints Fenced frames disable explicit communication channels, but it is still possible to use covert channels to share data between the embedder and embeddee, e.g. global socket pool limit (as mentioned in the [xsleaks audit](https://docs.google.com/spreadsheets/d/1YkQxcQlOd24XmSUQ8RpQU0zINYSTTih8drNibV0LIXE/edit?usp=sharing)), network side channel and intersection observer as described above, etc. Mitigations to some of these are being brainstormed. We also believe that any use of these known covert channels is clearly hostile to users and undermines web platform intent to the point that it will be realistic for browsers to take action against sites that abuse them. diff --git a/explainer/integration_with_web_platform.md b/explainer/integration_with_web_platform.md index 8d2fe75a..35e367ce 100644 --- a/explainer/integration_with_web_platform.md +++ b/explainer/integration_with_web_platform.md @@ -2,10 +2,10 @@ This document goes into the various ways in which fenced frame interacts with the platform. The web platform is massive and so we expect this document to be a running document with ongoing additions. ## Source url -The initial source url for the fenced frame is subjected to various restrictons or no restrictions depending on the use case for the fenced frame. Refer to the use cases document [here](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/use_cases.md) that discusses the source url for each of those. +The initial source url for the fenced frame is subjected to various restrictons or no restrictions depending on the use case for the fenced frame. Refer to the use cases document [here](https://github.com/WICG/fenced-frame/blob/master/explainer/use_cases.md) that discusses the source url for each of those. ## Origin -The origin of the fenced frame will be the regular origin that it got navigated to. For opaque src, the origin will be that of the url was mapped to by the browser. Any origin-keyed storage and communication channels with other same-origin frames outside the fenced frame tree will be disallowed by using a partitioning key with a nonce. The storage key will use the same nonce for the nested iframes and the root fenced frame, so that same-origin channels can still work within the fenced frame tree. Essentially, along with the storage partitioning effort, the storage and broadcast channel access will be keyed on for the root frame and for a nested iframe. More details related to this can be found [here](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/storage_cookies_network_state.md). +The origin of the fenced frame will be the regular origin that it got navigated to. For opaque src, the origin will be that of the url was mapped to by the browser. Any origin-keyed storage and communication channels with other same-origin frames outside the fenced frame tree will be disallowed by using a partitioning key with a nonce. The storage key will use the same nonce for the nested iframes and the root fenced frame, so that same-origin channels can still work within the fenced frame tree. Essentially, along with the storage partitioning effort, the storage and broadcast channel access will be keyed on for the root frame and for a nested iframe. More details related to this can be found [here](https://github.com/WICG/fenced-frame/blob/master/explainer/storage_cookies_network_state.md). ## Size The API that generates a fenced frame config can pick the initial size that the fenced frame document sees, subject to whatever restrictions it deems necessary for its privacy model. If the initial size is fixed, then any changes the embedder makes to the width and height attributes of the will not be reflected inside the fenced frame. @@ -15,7 +15,7 @@ Viewability events using APIs like [Intersection Observer](https://developer.moz Viewability events are important information in the ads workflow for conversion reports and billing; therefore, Intersection Observer will be fully supported in fenced frames and it will be phased out only if/when an alternative mechanism is launched. In the meantime, we plan to add metrics to understand honest use and detect abuse, to help guide the need/development of these eventual mechanisms or mitigations. ## Visibility -APIs like [visibilityState](https://developer.mozilla.org/en-US/docs/Web/API/Document/visibilityState) and the corresponding [visibilityChange event](https://developer.mozilla.org/en-US/docs/Web/API/Document/visibilitychange_event) determine the visibility of the tab based on user actions like backgrounding etc. A fenced frame and the main page could join server-side on the basis of when they lose and gain visibility. This kind of joining is also possible with other joining ids like the fenced frame creation time. The network side channel and future mitigations are described more [here](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/network_side_channel.md). +APIs like [visibilityState](https://developer.mozilla.org/en-US/docs/Web/API/Document/visibilityState) and the corresponding [visibilityChange event](https://developer.mozilla.org/en-US/docs/Web/API/Document/visibilitychange_event) determine the visibility of the tab based on user actions like backgrounding etc. A fenced frame and the main page could join server-side on the basis of when they lose and gain visibility. This kind of joining is also possible with other joining ids like the fenced frame creation time. The network side channel and future mitigations are described more [here](https://github.com/WICG/fenced-frame/blob/master/explainer/network_side_channel.md). ## Accessibility For accessibility, fenced frames will behave like iframes, they will be part of the accessibility tree and a11y users can navigate through its contents with a screen reader. @@ -26,7 +26,7 @@ Fenced frames would have normal user-interactivity as an iframe would. ## Focus Since fenced frames require interactivity, they would need to get system focus. It could be a privacy concern in the following ways: -* A fenced frame and the main page could join server-side on the basis of when one lost focus and another gained focus. The network side channel and future mitigations are described more [here](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/network_side_channel.md) +* A fenced frame and the main page could join server-side on the basis of when one lost focus and another gained focus. The network side channel and future mitigations are described more [here](https://github.com/WICG/fenced-frame/blob/master/explainer/network_side_channel.md) * For programmatic focus, calling element.focus() might invoke blur() on an element that is in the embedding page thus making a channel from the fenced frame to the embedding page. So the mitigations there would be: * Only allow programmatic focus()/blur() to be successful if the fenced frame already has system focus. * Only allow system focus to move to a FF on a user gesture including hitting the tab key and not because of calling focus(). @@ -38,10 +38,10 @@ A fenced frame does not allow communication via PostMessage between the embeddin Fenced frames can navigate but their history is not part of the browser back/forward list as that could be a communication channel from the fenced frame to the embedding page. Additionally, fenced frames will always have a replacement-only navigation (back/forward list of length 1) which is a simpler model since it doesn't imply that there's a hidden list of back/forward entries for the nested page, only accessible via history APIs and not via the back/forward buttons, etc. This is also consistent with the iframes new opt-in mode for disjoint session history as discussed in https://github.com/whatwg/html/issues/6501. ## Content Security Policy -Fenced frames ineractions with CSP are detailed [here](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/interaction_with_content_security_policy.md). +Fenced frames ineractions with CSP are detailed [here](https://github.com/WICG/fenced-frame/blob/master/explainer/interaction_with_content_security_policy.md). ## Permissions and policies -This is discussed in more detail [here](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/permission_document_policies.md). +This is discussed in more detail [here](https://github.com/WICG/fenced-frame/blob/master/explainer/permission_document_policies.md). ## COOP and COEP Although COOP is only defined for top-level documents, it has impacts on popups opened by subframes in the page. Because COOP is crucial to the web exposed mitigation against Spectre, Fenced Frames must support COOP in one way or another. Because COOP contains a reporting endpoint, we cannot actually pass the COOP value to the Fenced Frame. So to support COOP, we have two options: diff --git a/explainer/opaque_ads_use_cases.md b/explainer/opaque_ads_use_cases.md index 33f6369d..53e64117 100644 --- a/explainer/opaque_ads_use_cases.md +++ b/explainer/opaque_ads_use_cases.md @@ -2,7 +2,7 @@ ## Use-cases/Key scenarios -Following are the use cases for fenced frames loading [ads with opaque urls](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/use_cases.md#opaque-ads). +Following are the use cases for fenced frames loading [ads with opaque urls](https://github.com/WICG/fenced-frame/blob/master/explainer/use_cases.md#opaque-ads). ### Interest Group ads based on user activity (TURTLEDOVE) diff --git a/explainer/permission_document_policies.md b/explainer/permission_document_policies.md index f43cbc51..4369323e 100644 --- a/explainer/permission_document_policies.md +++ b/explainer/permission_document_policies.md @@ -9,13 +9,18 @@ This document goes into how fenced frames interact with various ways of policy d As mentioned in the list [here](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy#directives), some of the powerful features that permission policy (earlier known as feature policy) supports are autoplay, geolocation, camera etc. The HTTP header provides a mechanism to allow and deny the use of browser features in its own frame, and in content within any <iframe> elements in the document. The way a top-level page can currently deny/allow these features in an iframe does not work with fenced frames for the following reasons. +* Some permissions-backed features (such as fullscreen and picture-in-picture) have actions that are observable from an embedder, which would create a data exfiltration channel if enabled in a fenced frame. +* If permissions are delegated to a fenced frame, the fenced frame can then invoke a number of these APIs and based on whether each of them are allowed or not, it can be used to communicate a bitmap from the embedding page to the fenced frame. +* It then prompts the question as to whether it is possible for the fenced frame to behave like a top-level browsing context and do its own header exchange to determine what needs to be allowed/denied in the fenced frame tree. If the actual top-level page had denied a feature for an origin e.g. Feature-Policy: geolocation 'none' and a fenced frame is allowed to use geolocation via its own header exchange, then it acts as a workaround for the restrictions placed on embedded frames and leads to an escalation of privilege attack. +Different fenced frame configurations still need permissions-backed features to function properly. To handle that without compromising privacy, different behaviors are specified based on the existing privacy guarantees of the fenced frame: -* We cannot allow permissions to be delegated to the fenced frame since a fenced frame can then invoke a number of these APIs and based on whether each of them is allowed or not, it can be used to communicate a bitmap from the embedding page to the fenced frame. -* It then prompts the question as to whether it is possible for the fenced frame to behave like a top-level browsing context and do its own header exchange to determine what needs to be allowed/denied in the fenced frame tree. This also does not work because: - 1. if the actual top-level page had denied a feature for an origin e.g. Feature-Policy: geolocation 'none' and a fenced frame is allowed to use geolocation via its own header exchange, then it acts as a workaround for the restrictions placed on embedded frames and leads to an escalation of privilege attack. - 2. If we only allow a feature via FF headers if it was also allowed by the top-level page, then it acts as a bitmap channel as mentioned in the above point. +* Fenced frames that guarantee k-anonymity (i.e. fenced frames loaded with opaque URNs created through an API like Protected Audience) have a fixed list of permissions that must be delegated to it by the embedder in order for it to load. This forces the embedding context to have the same permissions bitmap as any other embedding context the fenced frame would be loaded in, removing that fingerprinting channel while also preventing privilege escalation. There is [a proposal to add permissions more flexibly rather than relying on a fixed list](https://github.com/WICG/fenced-frame/blob/master/explainer/permissions_policy_for_API_backed_fenced_frames.md), but this change is not currently planned on being implemented. +* Fenced frames that do not guarantee k-anonymity (i.e. developer-created fenced frames loaded with a transparent URL) can inherit permissions from its embedder, since the fingerprinting vector is not a concern. Because the data exfiltration channel is still a concern, we only allow select permissions-backed features that do not have data exfiltration risks. +See [this permissions policy file](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/public/common/frame/fenced_frame_permissions_policies.h) for a full list of the fixed permissions (for the k-anon case) or the list of permissions that can be enabled (for the non k-anon case). + +Permissions-backed features themselves can still introduce data leaks when enabled. [This document](https://source.chromium.org/chromium/chromium/src/+/main:content/browser/fenced_frame/PERMISSIONS_POLICIES.md) outlines that in greater depth, and includes an audit of which features are safe to enable for what kinds of fenced frames. ### Summary @@ -36,7 +41,7 @@ Relatedly, [Permissions API](https://developer.mozilla.org/en-US/docs/Web/API/Pe Document policy allows the top-level page to configure features on a frame via the ‘policy’ attribute. The embedded frame’s document request will then go on the network with a `Sec-Required-Document-Policy` header and the frame will only load if the response comes back with the same or stricter document policy. Since this depends on delegation, it has the same issues as the permissions policy or CSPEE with respect to being used as a communication channel. Since this is applied per-document (vs per origin in permissions policy), it is closer to CSPEE. -Similar to [CSPEE handling in fenced frames](https://github.com/shivanigithub/fenced-frame/blob/master/explainer/interaction_with_content_security_policy.md), the embedding site should treat fenced frames differently and assume that the presence of a fenced frame on the site implies no control on the policies of that frame via the policy attribute. +Similar to [CSPEE handling in fenced frames](https://github.com/WICG/fenced-frame/blob/master/explainer/permission_document_policies.md), the embedding site should treat fenced frames differently and assume that the presence of a fenced frame on the site implies no control on the policies of that frame via the policy attribute. The escalation of privileges attack mentioned above for permissions policy does not apply to document policy since this is delegated per-embedded frame and not per-origin and the embedding site can clearly distinguish between which frames can and cannot be controlled via delegation. diff --git a/explainer/permissions_policy_for_API_backed_fenced_frames.md b/explainer/permissions_policy_for_API_backed_fenced_frames.md index ce139d67..5645c9a0 100644 --- a/explainer/permissions_policy_for_API_backed_fenced_frames.md +++ b/explainer/permissions_policy_for_API_backed_fenced_frames.md @@ -1,6 +1,7 @@ # **Permission policy for API backed fenced frames** +> **_NOTE:_** There are currently no plans to implement this feature at this time. # **Introduction** diff --git a/explainer/storage_cookies_network_state.md b/explainer/storage_cookies_network_state.md index 9238749f..c2a5d892 100644 --- a/explainer/storage_cookies_network_state.md +++ b/explainer/storage_cookies_network_state.md @@ -12,7 +12,7 @@ Note that this document does not go into how unpartitioned storage/cookie access ## Fenced frame is not a nested browsing context -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](https://github.com/shivanigithub/fenced-frame#fenced-frame-api). 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. +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](https://github.com/WICG/fenced-frame/blob/master/explainer/README.md#fenced-frame-api). 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. ## Storage