Fenced Frame

1. Introduction

This section is non-normative.

In a web that has its cookies and storage partitioned by top-frame site, there are occasions — such as interest group based advertising as provided by the [Protected-Audience] API, or Conversion Lift Measurements ) — when it would be useful to display content from different partitions in the same page. This can only be done in a privacy-preserving way if the Document s that contain data from different partitions are isolated from each other, unable to communicate despite being re visually composed on the same page. iframe elements are not suitable for this, since they offer many intentional communication channels with their embedder. This specification introduces the fencedframe element, a new element to embed Document s on a page that explicitly prevents communication between the Document and its embedder.

This specification defines the new element, its integration with the rest of the web platform, including § 3 HTML Integration and § 4 Interactions with other specifications , and its supporting primitives like FencedFrameConfig , which is the major input to the fencedframe in place of normal URLs and " src " attributes. Given that this specification defines a new element and its integration with the rest of the platform, it should be read as largely a monkeypatch to the [HTML] , with its end goal to be merged into that standard, provided there is adequate cross-browser support.

2. The fencedframe element

Categories :

Flow content .

Phrasing content .

Embedded content .

Interactive content .

Palpable content .

Contexts in which this element can be used :

Where embedded content is expected.

Content model :

Nothing .

Content attributes :

Global attributes

width — Horizontal dimension

height — Vertical dimension

allow — Permissions policy to be applied to the fencedframe 's contents

Accessibility considerations :

TODO

DOM interface :

[Exposed=Window]
interface HTMLFencedFrameElement : HTMLElement {
  [HTMLConstructor] constructor();
  [CEReactions] attribute FencedFrameConfig? config;
  [CEReactions] attribute DOMString width;
  [CEReactions] attribute DOMString height;
  [CEReactions] attribute DOMString allow;
};

The fencedframe element represents its fenced navigable .

Descendants of fencedframe elements represent nothing.

Each fencedframe has a config , which is either a FencedFrameConfig or null. It is initially null.

The config IDL attribute getter steps are to return this 's config .

The allow attribute, when specified, determines the container policy that will be used when the permissions policy for a Document in the fencedframe 's fenced navigable is initialized. Its value must be a serialized permissions policy . [PERMISSIONS-POLICY]

The IDL attribute allow must reflect the respective content attribute of the same name.

2.1. Dimension attributes

This section details monkeypatches to [HTML] 's Dimension attributes section. That section will be updated to include fencedframe in the list of elements whose own width and height dimension attributes have the same author requirements that apply to the general width and height dimension attributes defined in [HTML] .

Furthermore, the IDL attributes width and height must reflect the respective content attributes of the same name.

2.2. Fenced frame config mapping

Each traversable navigable has a fenced frame config mapping , which is a fenced frame config mapping .

Note: This mapping is consulted during navigation , and written to by what we colloquially refer to as URN-generating APIs or config-generating APIs , that generate both urn uuids and fenced frame configs for use in navigating fencedframe and iframe elements. See for example, the [Protected-Audience] API and [Shared-Storage] specifications.

A fenced frame config mapping has three submappings:

pending config mapping

a map whose keys are urn uuids and whose values are fenced frame configs

finalized config mapping

a map whose keys are urn uuids and whose values are fenced frame configs

nested config mapping

a map whose keys are urn uuids and whose values are fenced frame configs

Note: The purpose of pending configs is to enable config-generating APIs to resolve configs asynchronously in a way that doesn’t create timing side channels, i.e., the pending config is returned to the web platform in a constant amount of time, before any computation whose duration depends on cross-site data. Because the privacy of this depends on the web platform not being able to discern when a pending config is finalized, it is important that all visibilities and values of transparent fields do not change from the pending config to the finalized config, given that they can be inspected through FencedFrameConfig 's getters. Therefore, a FencedFrameConfig that is created and exposed to the web platform is effectively immutable even if the fenced frame config represented by the config 's urn is technically "pending", and will finish resolving completely later.

Each fenced frame config mapping has a maximum number of configs , which is implementation-defined. The maximum number of configs may be a non-negative number or infinity.

Note: It is important to specify the behavior of maximum number of configs because its semantics can interact with config-generating APIs in a privacy sensitive way.

At a high level, in order to store a fenced frame config in the fenced frame config mapping , the creator of the config must first store a pending config, and then turn the pending config into a finalized config. Those procedures are as follows:

2.3. Fenced frame configs

2.3.1. Introduction

This section is non-normative.

A key feature of the fencedframe element is that web platform APIs can configure the behavior of the frame in a way that limits the ability of other execution contexts to modify or inspect this configuration, for security and privacy reasons. For example, the [Protected-Audience] API performs on-device ad auctions over cross-site data, and it is important that the ad that wins the auction can be loaded into a frame, without the API caller knowing which ad won the auction or being able to manipulate the environment in which the ad loads.

We achieve this using the concept of a " fenced frame config ". A fenced frame config is a collection of fields that can be loaded into fencedframe elements and that specifies the resulting environments. Fenced frame configs can only be created by specific web platform APIs, and not constructed or modified by script. Their fields also contain " visibilities ", which dictate whether the field should be "redacted" when inspected through the FencedFrameConfig interface. Config-generating APIs like the [Protected-Audience] and [Shared-Storage] APIs must specify values for all fields of their fenced frame configs in order to ensure that they have considered the privacy implications of each field, though they may choose to set the values to null.

Each time a fencedframe navigates to a fenced frame config , it is instantiated as a new fenced frame config instance , which governs the particular browsing context group inside the fenced navigable .

2.3.2. The fenced frame config struct

We now establish some preliminary types:

A visibility is either " opaque " or " transparent ".

A size is a struct with the following items :

width

a non-negative integer

height

a non-negative integer

TODO: Consider different numeric types for these members.

An interest group descriptor is a struct with the following items :

owner

an origin

name

a string

An exhaustive set of sandbox flags is a sandboxing flag set .

A pending event is a struct with the following items :

destination

a FenceReportingDestination

eventType

a string

eventData

a string

A fenced frame reporting map is a map whose keys are FenceReportingDestination s and whose values are either:

• lists of pending events (which are used to represent events that need to be reported asynchronously, because the metadata has not been finalized yet); or

• maps whose keys are strings and whose values are urls (which are used to represent the actual metadata once it is finalized).

Note: This representation is meant to allow config-generating APIs to reduce latency by resolving the values of reporting destinations asynchronously, after they’ve already constructed and returned the fenced frame config (and even after the config has been loaded, and event reports have been generated inside the fenced frame). When the config-generating API declares the fenced frame reporting map , they can mark certain destinations as pending using an empty list , and then maintain a reference to the map for later. If the fenced frame attempts to report an event to a destination while it is still pending, it stores the event in this list for later handling. When the config-generating API or its callback eventually finalizes a reporting destination through the reference it kept, it will handle all of the pending events stored in the list . If the destination is never finalized, then the pending events will never be sent.

A fenced frame reporting metadata is a struct with the following items :

fenced frame reporting map

a fenced frame reporting map

direct seller is seller

a boolean

A fenced frame reporter is a struct with the following items :

fenced frame reporting metadata reference

a mutable reference to a fenced frame reporting metadata TODO: Handle pointers/references in a more spec-y way

automatic beacon data

null, or a struct with the following items :

eventData

a string

destination

a list of FenceReportingDestination s

once

a boolean

An exfiltration budget metadata is a struct with the following items :

origin

an origin

amount to debit

a non-negative valid floating point number

An exfiltration budget metadata reference is a struct with the following items :

origin

an origin

amount to debit reference

a mutable reference to a non-negative valid floating point number TODO: Handle pointers/references in a more specy-y way

A partition nonce is an implementation-defined value.

Note: This is similar to the network partition key used by Fetch .

A fenced frame config is a struct with the following items :

mapped url

a struct with the following items :

value

a URL

visibility

a visibility

container size

null, or a size

content size

null, or a struct with the following items :

value

a size

visibility

a visibility

interest group descriptor

null, or a struct with the following items :

value

an interest group descriptor

visibility

a visibility

on navigate callback

null, or a series of steps

effective sandbox flags

null, or a struct with the following items :

value

an exhaustive set of sandbox flags

visibility

a visibility

effective enabled permissions

null, or a struct with the following items :

value

a list of policy-controlled features

visibility

a visibility

Note: When non-null, this is a list of policy-controlled features that the generator of this config relies on exclusively being enabled inside the fencedframe that navigates to this config. Specifically, each feature in this list must be enabled by the fencedframe 's fenced navigable 's permissions policy 's inherited policy when navigating to this config for the navigation to succeed. The features in this list are not force-enabled, but rather are used to check that the embedder environment that influences the aforementioned inherited policy is relaxed enough to support these essential features. If the inherited policy value for any of these features is " Disabled ", the navigation to this config will fail. Any policy-controlled feature not in this list will not be " Disabled " in the fencedframe that navigates to this config.

fenced frame reporting metadata

null, or a struct with the following items :

value

a fenced frame reporting metadata

visibility

a visibility

exfiltration budget metadata

null, or a struct with the following items :

value

an exfiltration budget metadata

visibility

a visibility

nested configs

null, or a struct with the following items :

value

a list of fenced frame configs

visibility

a visibility

embedder shared storage context

null, or a string

2.3.3. The fenced frame config instance struct

A fenced frame config instance is a struct with the following items :

mapped url

a URL

container size

null, or a size

content size

null, or a size

interest group descriptor

null, or an interest group descriptor

on navigate callback

null, or a series of steps

effective sandbox flags

null, or an exhaustive set of sandbox flags

effective enabled permissions

null, or a list of policy-controlled features

fenced frame reporter

null, or a fenced frame reporter

exfiltration budget metadata reference

null, or an exfiltration budget metadata reference

nested configs

null, or an map whose keys are urn uuids and whose values are fenced frame configs

partition nonce

a partition nonce

embedder shared storage context

null, or a string

Each browsing context has a fenced frame config instance , which is a fenced frame config instance or null, initially null.

This fenced frame config instance should really exist on browsing context group , however until third-party cookies are deprecated , this specification supports many of the fencedframe concepts on the iframe element. This requires that for the short term, a normal content navigable be able to load a fenced frame config , and therefore have access to the navigation’s corresponding fenced frame config instance .

2.3.4. The FencedFrameConfig interface

One major input to the fencedframe element is the FencedFrameConfig interface, which maps to an internal fenced frame config struct .

enum OpaqueProperty {"opaque"};
typedef (unsigned long or OpaqueProperty) FencedFrameConfigSize;
typedef USVString FencedFrameConfigURL;
[Exposed=Window, Serializable]
interface FencedFrameConfig {
  readonly attribute FencedFrameConfigSize? containerWidth;
  readonly attribute FencedFrameConfigSize? containerHeight;
  readonly attribute FencedFrameConfigSize? contentWidth;
  readonly attribute FencedFrameConfigSize? contentHeight;
  undefined setSharedStorageContext(DOMString contextString);
};

Note: Note that FencedFrameConfig s cannot be constructed manually from JavaScript. They can only be created by config-generating APIs. However, some browsers support a developer-only flag which help developers test the fencedframe element with arbitrary URLs not produced by config-generating APIs for development.

Each FencedFrameConfig has:

• A urn , a urn uuid

• A sharedStorageContext , a string

• A containerWidth , a FencedFrameConfigSize or null

• A containerHeight , a FencedFrameConfigSize or null

• A contentWidth , a FencedFrameConfigSize or null

• A contentHeight , a FencedFrameConfigSize or null

2.4. The Fence interface

Several APIs specific to fenced frames are defined on the Fence interface.

enum FenceReportingDestination {
  "buyer",
  "seller",
  "component-seller",
  "direct-seller",
  "shared-storage-select-url",
};
dictionary FenceEvent {
  required DOMString eventType;
  required DOMString eventData;
  required sequence<FenceReportingDestination> destination;
  boolean once = false;
};
typedef (FenceEvent or DOMString) ReportEventType;
[Exposed=Window]
interface Fence {
    undefined reportEvent(ReportEventType event);
    undefined setReportEventDataForAutomaticBeacons(FenceEvent event);
    sequence<FencedFrameConfig> getNestedConfigs();
};

2.5. New request destination

The processing model of a fencedframe 's navigation request deviates from that of the normal navigation request in enough ways to justify a new request destination value. This specification updates the request destination enumeration to include a new entry, " fencedframe ". Perform the following monkeypatches to the [FETCH] Standard.

Add " fencedframe " to the non-subresource request list and to the navigation request list.

Add " fencedframe " to the RequestDestination enum.

Non-normatively, update the DOM intro destination table to illustrate that fencedframe navigation requests have the following properties:

• destination of " fencedframe "

• initiator ""

• CSP directive of fenced-frame-src

• Features as HTML’s <fencedframe>

2.6. Automatic Reporting

This first introductory paragraph is non-normative.

A side effect of the fenced boundary model is that ads will lose the ability to know if a click resulted in a successful navigation. This is because the page loaded from a top-level navigation originating from a fenced frame will not be allowed to report to the fenced frame that it loaded (through something like window. opener ). Instead, we introduce a special event-level reporting type , reserved.top_navigation , which automatically sends an event-level beacon when a fenced frame initiates a successful navigation to a top-level traversable .

3. HTML Integration

3.1. Extensions to the Window interface

partial interface Window {
  // Collection of fenced frame APIs
  readonly attribute Fence? fence;
};

Each Window object has an associated fence , which is a Fence instance created alongside the Window .

3.2. Modifications to creating browsing contexts

3.3. Policy container inheritance

When making a navigation request to a local URL , iframe s clone their policy container from the navigation request 's initiator Document . If fencedframe s were to do the same thing, that would allow information about the initiator’s policy container to leak across a fenced frame boundary. This section patches policy container inheritance to close that leak.

Note: fencedframe policy container inheritance upon initial Document creation is handled in the § 3.2 Modifications to creating browsing contexts section.

3.4. Nested traversables

3.4.1. Introduction

This section is non-normative.

The [HTML] Standard organizes navigables into two categories: child navigables and traversable navigables (also known as top-level traversables ). The introduction of features like fenced frames, and to a lesser extent portals , complicates this model by adding a new type of traversable navigable that is sometimes like a child navigable . Because these new frame types are housed in a separate browsing context group from their embedder, some concrete level of isolation is expected and required; on the other hand since they are composed visually inside of other browsing context groups , sometimes they need to behave like the normal child navigables that we see in e.g., iframe s.

The complexity here is in deciding when terms like navigable container , navigable parent , and descendant navigables need to cross the traversable navigable / browsing context group boundary, versus when doing so would be unsafe or incorrect. The examples below illustrate this point.

When a user activates content inside of a Document , ordinarily the activation notification steps give user activation to all ancestor navigables and all same origin descendant navigables . But because a fencedframe can host sensitive content that needs to be isolated from its embedder, and because user activation and consumption offer a communication vector between these two parties, for the purpose of user activation a fencedframe 's fenced navigable cannot not be considered a descendant of its embedder, nor can its embedder be considered an ancestor of the fencedframe 's fenced navigable , in the way that the user activation algorithms currently use those terms. In other words, we consider user activation to be fenced , to denote that it never crosses the fenced navigable boundary; if it were unfenced, it would behave as it would with iframe s, allowing user activation to flow freely across the frame boundary.

Unlike user activation , when a fencedframe 's fenced navigable gets created or navigated , it must inherit its embedder Document 's active sandboxing flag set as is standard for Document s in normal child navigables . If we did not do this, then the fencedframe element would be a trivial sandbox bypass. Because fencedframe sandbox flag inheritance behaves similarly to how it does in iframe elements, we consider sandbox inheritance to be unfenced .

To provide the isolation mentioned above, and its conditional relaxation, this specification defines a new kind of parent for traversable navigables called an unfenced parent , which provides a link to its embedder that algorithms can intentionally use when they need to be unfenced , as described above.

Note: Introducing a new kind of parent ( unfenced parent ) is an intentional design decision. It means that by default, the fencedframe boundary is private and isolated, since by default nothing in the web platform traverses from a fencedframe 's fenced navigable to its embedder. Care must be taken when modifying algorithms to make them capable of traversing across the fencedframe fenced navigable boundary, and each modification of this sort will be evaluated independently and appear in this specification.

The rest of this section provides patches to various [HTML] definitions (and their uses) that deal with collections of related navigables, with the intention of fencing and unfencing various parts of the web platform appropriately.

3.4.2. Traversable navigables

In [HTML] 's Traversable navigables section, add the following:

In addition to the properties of a navigable , a traversable navigable has:

• An unfenced parent , a navigable or null, initially null.

Note: The unfenced parent link is what gives a fencedframe 's fenced navigable a link to its embedder, which is used carefully for things that need to be " unfenced ", like some algorithms in the focus processing model.

3.4.3. Nested traversables

In [HTML] 's Navigables section, add a new subsection titled "Nested traversables" with the following text, definitions, and algorithms.

Similar to navigable containers and their respective content navigables , other elements (so far, only the fencedframe element) present a more isolated navigable to the user. These elements are called fenced navigable containers .

A fenced navigable container has a fenced navigable , which is either a traversable navigable with a non-null unfenced parent , or null. It is initially null.

Note: The create a new nested traversable algorithm creates the first kind of traversable navigable that is not a top-level traversable . This will require removing the note about nested traversables in [HTML] 's Top-level traversables section.

3.4.4. Top-level traversables

The [HTML] Standard currently defines a top-level traversable as a traversable navigable whose parent is null, however this is an insufficient definition that this specification changes. [HTML] mentions that outside of this specification, all traversable navigables are top-level traversables , but "envisions" future specifications that may want to create a kind of traversable that is nested, and achieves the nesting through a non-null parent ; hence the distinction between top-level traversables and traversable navigables relies on the parent null-ness.

The fenced navigable this specification proposes is precisely what [HTML] envisioned when carving out space for the distinction between top-level traversables and traversable navigables , however this specification does not make use of the parent pointer for fenced navigables , for reasons described above (instead they use the unfenced parent pointer). That means by default, both top-level traversables and fenced navigables both have null parents , which renders the distinction meaningless.

To mend the intended distinction between top-level traversables and fenced navigables , patch the following definitions like so:

Note: With these new definitions, a top-level traversable is essentially "unfenced" as described in the § 3.4.1 Introduction .

3.5. Modifications to navigable-traversing algorithms

3.6. Modifications to the focusing algorithms

The [HTML] standard defines how to handle focusing elements and Window s, both by user gesture and through script-initiated APIs. Since fenced frames are designed to prevent communication across a fenced frame boundary, we need to handle focusing carefully. This is because when focus crosses a fencedframe boundary, contexts on both sides of the boundary can detect that change, which can be used to open a communication channel between a fencedframe and its embedder.

We do this by not allowing the focusing steps to move script-initiated focus across a fenced frame boundary.

When a user clicks on an element like a button inside a fencedframe while another element outside of the fencedframe is focused , the focusing steps will allow the button to gain focus , because this is specifically a user-initiated action. Without allowing that, no element inside of a fencedframe would never be able gain focus .

If we were to continue allowing all elements to be focused via the focus() method as is the status quo before this specification, a fenced navigable container and its fenced navigable could use a sequence of focus() calls to send arbitrary data across the fenced frame boundary, which is a privacy leak. To avoid this, we effectively "fence" the focus() method, which sacrifices some functionality for privacy.

3.7. Navigation

This section describes how the fencedframe element interacts with the ever-complicated process of navigation, which includes integration with various headers, isolation mechanisms, and policies.

3.7.1. The ` Supports-Loading-Mode ` HTTP response header

This section is intended to monkeypatch the [HTML] Standard, however since the ` Supports-Loading-Mode ` header has not been merged into [HTML] yet, and instead lives in the [Prerendering-Revamped] specification, this section effectively monkeypatches that monkeypatch specification.

Add the new token below to the list of valid tokens for the ` Supports-Loading-Mode ` response header:

The ` fenced-frame ` token indicates that the response can be used to create a Document inside of a fenced navigable . Without this explicit opt-in, all navigations inside of a fenced navigable will fail, as outlined in § 3.7 Navigation .

3.7.2. COOP, COEP, and cross-origin isolation

Outside of this specification, the ` Cross-Origin-Opener-Policy ` header only applies to top-level traversables instead of all navigables , and this specification continues this intention insofar as this header does not have an impact on fenced navigables , nor is it inherited from its embedder. Consequently, the browsing context group hosted inside of a fenced traversable navigable will always have its cross-origin isolation mode set to " none ".

Nevertheless, a fenced navigable respects its unfenced parent 's embedder policy , which is accomplished below:

Note: This causes navigations inside of a fencedframe to fail if they are not served with a suitable ` Cross-Origin-Embedder-Policy ` header, just as iframe s behave.

Determine if we need to fence or unfence the queue a cross-origin embedder policy inheritance violation algorithm, as leaving it unfenced may cause a privacy leak.

Determine if we need to fence or unfence the queue a cross-origin embedder policy CORP violation report algorithm, as leaving it unfenced may cause a privacy leak.

3.7.3. Actual navigation changes

The below patches make use of the previously-assigned target fenced frame config , instantiating it in preparation for use when the navigation is finalized.

Finally, the below patches make use of the navigation params 's fenced frame config instance , and handle the assignment of a browsing context 's fenced frame config instance that is initiated by a navigation.

Note: A browsing context 's fenced frame config instance is assigned in two different ways: (1) during embedder-initiated fencedframe navigation, as described by the rest of this section, and (2) inherited during initial Document creation for Document s in child navigables whose traversable navigable is a fenced navigable , as handled in the § 3.2 Modifications to creating browsing contexts section.

For any successful navigation inside of a fencedframe , regardless of whether it was initiated by content in the fencedframe or its embedder, exactly one of two things will happen:

• Embedder-initiated navigations : The navigation params 's fenced frame config instance will be unconditionally assigned to the fencedframe 's fenced navigable container 's fenced navigable 's active browsing context 's fenced frame config instance .

• Inner-content-initiated navigations : The fenced frame config instance referenced in the immediately-preceding point persists through this kind of cross- Document navigation.

TODO: Call the on navigate callback at the appropriate time.

3.7.4. Browsing context group swap

When the embedder of a fencedframe initiates navigations inside the frame, we must perform a browsing context group swap to entirely reset the context inside the frame, to ensure nothing is left over to be leaked to the next Document .

3.8. Page visibility

The Page visibility section of [HTML] is modified such that the first step of the algorithm that runs when a user-agent changes a traversable navigable 's system visibility state calls the inclusive descendant navigables algorithm with unfenced set to true.

4. Interactions with other specifications

Due to the necessarily cross-cutting nature of the fencedframe element and its interactions with core concepts like navigable and browsing context group , there are a number of specifications that rely on terms whose usages must be re-evaluated in light of this specification; this section houses the various changes that we propose to other specifications.

4.1. Prerendering

The Prerendering Revamped specification defines navigable 's loading mode and the values it can take on. Our specification adds another value for fenced frames:

" fencedframe "

This navigable is displaying a fencedframe 's content

Specify the behavior that leads to the following:

4.2. Content Security Policy

This introductory section is non-normative .

Content Security Policy [CSP] can ordinarily be used by web content associated with a Document that hosts a navigable container to limit the source of navigations in a child navigable .

In order to prevent [CSP] from being used a communication side-channel exposing the URL of navigations inside a fencedframe to the site operating its embedder, the only source expressions that can influence a fencedframe navigation are:

• The scheme-source " https: "

• The host-source " https://*:* "

• The string " * "

See our CSP explainer that describes this.

4.2.1. Algorithms

Next, we modify the behavior of the [CSPEE] specification. If the embedding frame specifies a required CSP , fenced frames will not load. This is done to prevent arbitrary data flow from the embedder to the fenced frame.

4.2.2. New fenced-frame-src [CSP] directive

Since fencedframe is a different element than iframe , using the frame-src directive wouldn’t give web sites enough control over their CSP rules. Introduce a new [CSP] directive : fenced-frame-src . The monkey-patched specification is printed below:

directive-name  = "fenced-frame-src"
directive-value = serialized-source-list

Content-Security-Policy: fenced-frame-src https://example.com/

<fencedframe src="https://example.org/">
</fencedframe>

Content-Security-Policy: connect-src 'self';
                        ...
                        worker-src 'self'

Content-Security-Policy: connect-src 'self';
                        ...
                        fenced-frame-src 'self';
                        ...
                        worker-src 'self'

4.3. Permissions Policies

This introductory sub-section is non-normative.

The policy-controlled features available to Document s inside of a fencedframe are determined exclusively by the fenced frame config that the fencedframe navigates to. Specifically, the fenced frame config 's effective enabled permissions defines the exclusive list of policy-controlled features that will be enabled in the Document (all others will be disabled).

During navigation, the fenced frame config instantiates a fenced frame config instance that is stored on the browsing context in the fenced navigable . This browsing context’s fenced frame config instance 's effective enabled permissions is consulted during navigation . A fencedframe navigation can only succeed if the permissions policy for the navigation’s resulting Document has an inherited policy such that the inherited policy value is " Enabled " for each feature in the effective enabled permissions . Otherwise the environment the fencedframe is embedded in is deemed unsuitable for the fenced frame config , and the navigation is blocked.

At the same time, to make sure that a fencedframe 's embedder does not directly influence content in the frame based on that navigation’s origin (since the origin is derived from cross-site data), this specification modifies various [PERMISSIONS-POLICY] algorithms such that a fencedframe Document 's inherited policy is computed without consideration of whether its origin is same origin with its embedder’s. Therefore a feature can only be enabled inside of a fencedframe if its embedder explicitly delegates it via the special value * allowlist .

Considering all of the above, we get the following interesting implications:

• If a feature that exists in the effective enabled permissions has a default allowlist of the special value * , and no ` Permissions-Policy ` header is served on the fencedframe embedder, and the allow attribute is empty, the navigation inside the fencedframe will succeed, and the resulting Document will be allowed to use the feature (i.e., it will be enabled).

• If a feature that exists in the effective enabled permissions has a default allowlist of 'self' , and no ` Permissions-Policy ` header is served on the fencedframe embedder, and the allow attribute is empty, the navigation inside the fencedframe will be blocked.

  Note: This is because ordinarily this feature would only be enabled if the subframe’s Document was same origin with its embedder, a check this specification avoids for fenced frames, since the fencedframe s Document 's origin is derived from cross-site data. Therefore, we simply "fail close".

• If a feature that exists in the effective enabled permissions has a default allowlist of 'self' , and the fencedframe 's allow attribute contains the feature but no allowlist , the rules described in The allow attribute section , the default allowlist for the feature will be 'src' which is meant to represent the embedder-supplied navigation URL , for which there is none when navigating a fencedframe , as the navigation URL is determined by the fenced frame config . The navigation will be blocked.

• If a feature that exists in the effective enabled permissions has a default allowlist of 'self' but either the ` Permissions-Policy ` header served on the fencedframe 's embedder OR the allow attribute sets that feature 's allowlist to the special value * , then the navigation inside the fencedframe will succeed, and the resulting Document is allowed to use the feature .

• If a navigation inside a fencedframe would otherwise succeed, but the response on the navigation inside the fencedframe is served with a ` Permissions-Policy ` header that sets the allowlist to " none " or an otherwise incompatible origin for a feature in the effective enabled permissions , the navigation still succeeds, but the Document in the fencedframe is not allowed to use the feature.

  Note: This is OK because it is the fencedframe 's content itself that is making the decision to disable a particular feature, not its embedder environment.

The patches in the below section "fence" the appropriate [PERMISSIONS-POLICY] and [HTML] algorithms to achieve the outcomes described in the above explanatory content.

4.3.1. Algorithm patches

4.4. CSSOM View

The [CSSOM-VIEW] specification defines the scrollIntoView() method that calls the scroll a target into view algorithm. This will not only scroll the Element or viewport to make the target visible, but will also scroll ancestor s if necessary to make the target visible, essentially causing the scroll to "bubble up". This means that scrollIntoView() performed in a child navigable or fenced navigable can be observed by its embedder, allowing for collusion across a fenced frame boundary. This section patches the scroll a target into view algorithm to prevent that collusion at the expense of some utility.

5. Security & Privacy Considerations

This material is being upstreamed from our explainer into this specification, and in the meantime you can consult the following resources:

• Security considerations

• Privacy considerations

• TAG Security/Privacy Questionnaire