A fenced frame is an embedded context that enforces strict boundaries between it and its embedder. Fenced frames are not allowed to communicate information to and from their embedders (i.e. using something like window.postMessage()), nor are they allowed to learn information about their context that can help them form a fingerprint of where they're embedded.
This document serves as an audit for every permissions-backed feature to determine whether it's safe to enable inside of a fenced frame. To determine that, we need to answer the following questions:
If you're adding a new permissions-backed feature, please do the following:
Please feel free to reach out to third_party/blink/renderer/core/html/fenced_frame/OWNERS with any questions you have.
Protected Audience-created fenced frames have the privacy guarantee that no information can flow from the embedder into the fenced frame. Permissions-backed features pose a risk for 2 reasons:
To mitigate these risks, we only allow Protected Audience fenced frames to load with specific features enabled. These features must be enabled for the fenced frame's origin. If any of the required features are disabled, the fenced frame will not load.
See: network::kFencedFrameFledgeDefaultRequiredFeatures in services/network/public/cpp/permissions_policy/fenced_frame_permissions_policies.h.
selectURL-created fenced frames can contain information from the embedder by having the embedder add arbitrary data to the URLs that the frame is navigated to. Because of this, it is acceptable to have information flow in from the embedder to the fenced frame via permission backed features.
However, stopping data outflow from the fenced frame to the embedder is still part of the privacy story. Many permissions-backed APIs can be used to exfiltrate data out of a fenced frame, so they cannot be enabled. To be safe, we are currently only allowing a few permissions-backed features to be enabled that are required for functionality purposes.
See: network::kFencedFrameSharedStorageDefaultRequiredFeatures in services/network/public/cpp/permissions_policy/fenced_frame_permissions_policies.h.
Third-party cookie deprecation breaks useful website features like personalized payment buttons. Fenced frames offer a potential solution by allowing controlled access to cross-site user data stored in Shared Storage. To protect privacy, fenced frames must disable external communications (specifically, anything that can send data out of a fenced frame) before accessing this sensitive data. Otherwise, the sensitive information can be exfiltrated, creating a data leak.
When these fenced frames are constructed using a URL provided by the embedder and can contain information from the embedder in the URL, it is acceptable to have information flow in from the embedder to the fenced frame via permission backed features. However, Permissions-backed APIs pose the challenge of data outflow, since many of them can allow for the exact kind of data exfiltration that must be prevented to keep the unpartitioned data safe. To mitigate that risk, we are currently allowing a small subset of permissions-backed features to be enabled. This can be expanded in the future if more use cases are found that require other features.
See: network::kFencedFrameAllowedFeatures in services/network/public/cpp/permissions_policy/fenced_frame_permissions_policies.h.
Below is an audit of all permissions-backed features (as of August 2023) and whether enabling them for fenced frames (that can allow embedder information to be transferred to the FF), if needed in the future, is safe or will pose a data exfiltration risk:
Legend:
Feature: kAutoplay
Media playing in a subframe cannot be observed by its embedder, and an embedder cannot use this to influence how the media plays (outside of the feature being enabled to begin with). While allowing autoplay has the potential to be annoying, there is no risk of data exfiltration or fingerprinting by allowing this.
Feature: kCamera, kMicrophone
These involve interacting with a MediaStream object. Any interactions with MediaStreams only affect that instance, and will not affect other MediaStreams in other contexts that are pointing to the same input device.
Use of the camera or microphone itself poses both a data infiltration risk. An embedding page could encode data into a sound that is picked up by the microphone and sent to the fenced frame.
There is also a fingerprinting risk with these APIs. The embedding page and fenced frame could take a video or audio recording and use that as a fingerprint to join data server-side.
There is no additional exfiltration risk introduced with enabling this API in a fenced frame.
Feature: kEncryptedMedia
This feature deals with encrypting and decrypting media. The media information cannot be passed anywhere using this feature; it instead would have to rely on other methods of communication if it wants to exfiltrate this data.
Feature: kFullscreen
A fullscreenchange event that originates from a fenced frame is observable by its embedder and vice versa. Entering fullscreen requires user gesture, so this is less of a concern, but can still be used in conjunction with timing to leak information.
Document.fullscreenEnabled can be used as a fingerprinting vector, since it returns information about whether fullscreen is allowed in the browser/page.
Feature: kGeolocation
The API is read-only. getCurrentPosition() and watchPosition() do not modify anything about how geolocation works internally, so those calls are not observable by other contexts.
Information about a user's location can be used for fingerprinting.
Feature: kSerial, kUsb, kBluetooth, kMidiFeature, kHid
Arbitrary data can be sent out to external devices. If some other context (like the embedding frame) connects to that same device, the device can then relay that arbitrary data to the context, allowing for arbitrary data transfer.
The list of devices connected to the computer (through getPorts(), getDevices(), etc...) can be used as a fingerprinting vector.
Feature: kWebXr
Arbitrary data can be sent to a VR headset, which, in turn, can encode and send that data via its user input data to another context. Realistically, this attack will never happen, but it is theoretically possible.
Information about a connected headset + AR capabilities can be used as a fingerprinting vector.
Feature: kSmartCard
The readme for the smart card feature explicitly outlines a possible attack where one context can write arbitrary data to a smart card, and another context can read that data from the smart card.
The names of the smart cards retrieved with navigator.smartCard.getReaders() can be used as a fingerprinting vector.
Feature: kPayment
While arbitrary data can be put into the details parameter of a PaymentRequest() constructor, the payment request won’t be allowed once window.fence.disableUntrustedNetwork() is resolved. However, the main use case for this API in a subframe requires direct communication between the embedder and the subframe. Because fenced frames explicitly disallow this kind of communication, the Payment Request API will be broken inside of fenced frames if we enable them. Therefore, it should not be allowed.
Feature: kSyncXHR
This feature determines if a synchronous XML request can be made. Without network cutoff, this allows information to freely flow between the fenced frame and arbitrary servers. Once window.fence.disableUntrustedNetwork() is resolved, these requests should not succeed.
There are no API methods that can be used for fingerprinting.
Feature: kAccelerometer, kGyroscope, kMagnetometer
All properties of the Sensor and its derived classes are either read only, or only affect that Sensor instance (such as start() and stop()). This cannot be used to pass information between an embedder and its fenced frame.
Information about the availability of sensors can be used to fingerprint the browser the fenced frame was loaded in.
Feature: kAmbientLightSensor
Similar to the 3 other sensor APIs above, information about the availability of an ambient light sensor can be used for fingerprinting.
An ambient light sensor can detect changes in brightness from the contents on a device's screen when the device is in a dark room, so an embedder could use changes in content brightness to encode information that the frame can then read.
Feature: kPictureInPicture
There can only be 1 PIP window open at a time. If a different context requests PIP, the media currently in PIP mode will be removed from PIP. This change can be observed by checking the document.pictureInPictureElement property, which will become null if its PIP media is removed from PIP.
Feature: kVerticalScroll
This simply allows or disallows specific subframes from interfering with vertical scrolling. Since the act of scrolling is an entirely user-initiated action, this can’t be exploited to exfiltrate information.
Aside from the previously-mentioned 1-bit fingerprinting vector from enabling the permissions policy, there are no additional fingerprinting concerns.
Feature: kScreenWakeLock
Changes to Navigator.wakeLock are viewable externally. As an example, load this site and toggle navigator.wakeLock on in the Live Demo. Then, load the MPArch demo page, click “Add IFrame”, then in the iframe click “release”. On the first site, the “Wake Lock status” in the Live Demo will switch to “released externally”.
The timestamps of the wakeLock operations can be used for fingerprinting.
Feature: kIdleDetection
All IdleDetector methods are either read only or only affect that instance of IdleDetector.
Checking the time that a userState or screenState changes can be used as a fingerprinting vector.
Feature: kExecutionWhileOutOfViewport, kExecutionWhileNotRendered
These features enable or disable code execution under certain conditions. kExecutionWhileNotRendered can be used to allow a fenced frame to learn about its embedder (specifically whether the fenced frame is being rendered or not, which can be controlled by the embedder). The embedder isn’t able to learn anything about a fenced frame through these flags. Note that viewability is observable via the intersection observer API, which we allow for utility reasons.
Feature: kFocusWithoutUserActivation
Enabling this will have no effect on fenced frames since they will always gate focus on user activation. Allowing a developer to enable this feature could lead to confusion, so this should be disabled.
Feature: kClientHintDPR, kClientHintDeviceMemory, kClientHintDownlink, kClientHintECT, kClientHintRTT, kClientHintUA, kClientHintUAArch, kClientHintUAModel, kClientHintUAPlatform, kClientHintViewportWidth, kClientHintWidth, kClientHintUAMobile, kClientHintUAFullVersion, kClientHintUAPlatformVersion, kClientHintPrefersColorScheme, kClientHintUABitness, kClientHintViewportHeight, kClientHintUAFullVersionList, kClientHintUAWoW64, kClientHintSaveData, kClientHintPrefersReducedMotion, kClientHintUAFormFactors
This allows a fenced frame to learn about the device it’s on, but no information will flow back to the embedder. Data is only sent at navigation time, as the client hints live in the HTTP request headers. This can be used for fingerprinting at navigation time (before network cutoff). Note that this will require its own separate effort to enable.
Feature: kClientHintUAHighEntropyValues
By default, the navigator.userAgentData.getHighEntropyValues() JS API can be called by embedded frames and may pose a fingerprinting risk, and unlike other Client Hints features, is unrelated to navigation. kClientHintUAHighEntropyValues can be used to limit which origins can collect high-entropy User-Agent client hints.
Feature: kPublicKeyCredentialsGet, kOTPCredentials, kIdentityCredentialsGet
These APIs can only be called from same-origin subframes. An explicit carveout has been made to treat all fenced frames as cross-origin and disable access to navigator.credentials across the board.
Feature: kPrivateStateTokenIssuance, kTrustTokenRedemption
When a private state token is issued, its existence can be observed in all cross-origin subframes by calling document.hasPrivateToken(). This is a communication channel, as an embedder can learn information about whether a fenced frame got a trust token by calling this (and vice versa).
Each private state token can store a value between 0-5, so each token is able to put ≈2.58 (log2(6)) bits of information into the browser that is observable from all sites that are set up to work with the issuer.
There is a 2 token limit per site that is meant to reduce the possible data leak (each page can potentially leak a little over 5 bits of information). However, this also lets the fenced frame learn about its embedder by trying document.hasPrivateToken() on known issuers and seeing which ones work and which ones error out, creating a fingerprint of its context.
Feature: kAttributionReporting
While data can be exfiltrated through reporting, as long as the reporting is aggregate-level and not per-event, the report cannot be used to accurately exfiltrate information or be traced back to any one frame. This API can both send data in aggregate as well as per-event. The aggregate data is safe to send, but the per-event data must be blocked after network revocation. The API cannot be used to infiltrate data into the fenced frame, and no fingerprinting identifiers are revealed by enabling this API.
Registering sources and triggers requires network connectivity. After network revocation, the requests to the servers that establishes the sources/triggers will not go through, so no new reports can be registered, and no sensitive information guarded by network revocation can be added to reports.
Feature: kCrossOriginIsolated
This policy allows a fenced frame to use powerful features. The most concerning feature allowed with this flag is SharedArrayBuffer, which allows different contexts to get access to shared data. However, this is only possible if the SharedArrayBuffer object can be passed to a different context. Since postMessage() is already gated after network cutoff, this is okay to enable.
Feature: kClipboardRead
Information set in the clipboard by an embedder can be read by a fenced frame, allowing arbitrary data to flow into the fenced frame. This can be used to read data directly, or for fingerprinting.
Feature: kClipboardWrite
Arbitrary data can be written to the clipboard which can then be read by any frame or any open app on the system (not just the embedding frame). This can be used to pass data directly, or for fingerprinting.
Feature: kWebShare
While this explicitly allows data exfiltration, it does require user consent. A popup is shown that allows the user to choose if the data is shared, and to where it is shared. Because of that, this should be treated the same way that having a user copy/paste a body of text is treated.
Feature: kGamepad
Most features for gamepads are read-only. A notable exception is the pulse() method. In theory, it could be used to encode data which can then be read by the GamepadPose’s linearAcceleration property or some microphone, but the data will most likely be way too noisy to actually be useful (it feels more like the case outlined in this relevant xkcd).
Information returned from navigator.getGamepads() can be used as a fingerprinting vector.
Feature: kDisplayCapture
Giving a fenced frame access to getDisplayMedia() will allow it to read information from other displays, which allows for data flow into a fenced frame, not out of it. Information about the display, including dimensions and the way that pages are rendered can be used as a fingerprinting vector.
Feature: kSharedAutofill
Allowing autofill information to be shared between an embedder and its frame is not a data exfiltration risk. Autofill information lives in the browser, and having a subframe fill out information in a form does not reveal any information about a fenced frame to an embedder or vice versa. This feature won’t be particularly useful after network cutoff in unpartitioned access mode as the autofilled form cannot be submitted anywhere.
This could potentially be a fingerprinting vector if identical forms are submitted across fenced frame boundaries that include matching autofill data.
Feature: kDirectSockets
This directly involves sending TCP/UDP data into and out of a fenced frame, This is fine before network cutoff, but shouldn’t be allowed once window.fence.disableUntrustedNetwork() is resolved. However, there are a few factors at play that make disabling network for direct sockets more complicated than other types of network access:
net::IsolationInfo, which is the main tool we use to disable network access.Given the ambiguity around the status of the implementation, as well as the network stack changes required to ensure it’s disabled properly, it makes the most sense to be safe and disable the feature via permission in fenced frames.
Feature: kWindowManagement
This is a fingerprinting vector. Calling window.getScreenDetails() allows a frame to learn information about every display connected to the computer.
The one possibility for data exfiltration involves calling moveTo() on a popup that was opened by a fenced frame. However, since window.open doesn’t give a fenced frame an object of the window that was opened, this isn’t an exfiltration concern.
Feature: kKeyboardMap
This is simply used to map a keystroke to a keycode. There is no way to exfiltrate or infiltrate information using the API’s methods. Its layoutchange event originates from if the system changes its keyboard layout.
Feature: kJoinAdInterestGroup, kRunAdAuction
Arbitrary data can be exfiltrated from a fenced frame via joinAdInterestGroup() to a group-by-origin interest group. This information can then be used in other ad auctions.
If information is leaked from elsewhere to a group-by-origin interest group (using the above method), a fenced frame can gain access to that information by running multiple ad auctions that are influenced by that interest group. For each auction, the worklet will either have an auction winner or not have an auction winner based on one of the bits stored in the interest group. Because the fenced frame is made aware of the result of the ad auction, it can simply store each success or failure as a bit, building up n bits of information by running n ad auctions.
Feature: kBrowsingTopics, kBrowsingTopicsBackwardCompatible
No arbitrary data can be logged as a browsing topic; there are a fixed number of topics that can be joined. The browser also has the final say on what topics are shown to a context, which prevents arbitrary data from being exfiltrated out of a frame. The fixed number of topics removes any potential fingerprinting vectors.
Feature: kLocalFonts
There is no way to send data out of a fenced frame using this method. This just involves getting information about installed fonts from the operating system. This can be used for fingerprinting since installed fonts are unique to each computer.
Feature: kSharedStorage, kSharedStorageSelectUrl
There is no infiltration risk, as enabling this feature inside a fenced frame will have no effect on what information about the embedder is available to the frame.
There is no exfiltration or fingerprinting risk directly to the embedder with this API, as it is set up (both through worklets and rendering selectURL result in a fenced frame) to prevent the sensitive data it keeps from being exfiltrated and joined with cross-site data. However, there is the possibility of leaking 3 bits per selectURL() invocation. One of 8 URLs that can be input to selectURL() gets selected based on cross-site data, and the existence of the resulting frame and the URL that was picked can be leaked via network requests from the result rendering fenced frame. This is an ongoing privacy consideration for fenced frames.
Feature: TBD unpartitioned access feature
This must be allowed in fenced frames. This is the way that unpartitioned data will be read by a fenced frame after network revocation. There is an output gate specifically for access from within a fenced frame, so this data will not be able to be exfiltrated to first-party contexts outside of the fenced frame.
Feature: kUnload
Unload and beforeunload handlers have been previously disallowed inside fenced frames due to issues with reliability as well as a minor communication channel concern, so their permissions policy must be disallowed as well. The page deletion timestamp can be used as a fingerprinting vector, or its timing can be manipulated to send information.
Feature: kComputePressure
This API can just read the CPU load state. There is no way to use it to exfiltrate information.
In theory, an embedder or fenced frame could switch between running computationally expensive operations and not running them in order to encode bits to exfiltrate, and then some other frame can measure the differences in CPU load state to decode the message.
Having the embedder and fenced frame check computation pressure states over time can build a fingerprint of the system.
Feature: kPrivateAggregation
While data can be exfiltrated through reporting, the data is aggregated, so it can’t be traced back to any one frame or reliably joined to build a profile of the user. No data can be infiltrated into the fenced frame using this API, nor can this API be used as a fingerprinting vector.
Feature: kLocalNetworkAccess
A colluding server hosted on the local network can be used as a proxy to pass information from a fenced frame to its embedder. One side can make a request to write data to the server, and the other side can read what data was set in the server.
A site can make arbitrary local network requests, scanning for HTTP hosts and building a fingerprint of how the network (or device if checking for localhost connections) is set up.