content/browser/fenced_frame/PERMISSIONS_POLICIES.md
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.
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. 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.
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 when fenced frames have network. Historically this was disabled for fenced frames due to the following considerations around network revocation (obsoleted). 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: Deprecated unpartitioned access feature
This was earlier allowed in fenced frames as this was the way that unpartitioned data was read by a fenced frame after revoking network. There was 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. It is no longer allowed as that feature is now removed.
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.