[blink-dev] Intent to Prototype: Fenced Frames for Ads
Shivani Sharma
Contact emails
shiva...@chromium.org, jka...@chromium.org, d...@chromium.org
Explainer
https://github.com/shivanigithub/fenced-frame
Specification
None yet
Summary
Fenced frames are frames isolated from their embedding page to prevent cross-site information joining. This mode of fenced frames is for advertisement use cases (detailed below) and any subsequent modes of fenced frames for other use cases will be communicated via a separate I2P.
Blink component
Motivation
Third party iframes can communicate with their embedding page using mechanisms such as postMessage, attributes (e.g., size and name), and permissions. A number of recently proposed APIs (such as Interest group based advertising, Conversion Lift Measurements) provide some degree of cross-site (unpartitioned) information to embedded documents. Once third-party cookies have been removed, such documents should not be allowed to communicate with their embedders, else they will be able to join their cross-site information with the embedder’s user identifier, which would allow for user tracking. This solution proposes a new form of embedded document, called a Fenced Frame, that these new APIs can use to render the ad and isolate the rendered ad from the embedding document, preventing cross-site recognition.
Note that for this fenced frames mode the cross-site information mentioned above is essentially the interest group (for FLEDGE) and the experiment group (for Conversion Lift Measurement) and this mode never gets access to storage like cookies, local storage etc.
The I2P for the primary use case (FLEDGE) can be found here.
Privacy considerations
A follow-up design document will go into more details of how cross-site information joining and exfiltration is mitigated but a high level description is given below.
Fenced frames do not allow any usual communication channels with their embedding context like postMessage, script access, frame tree access via window.top etc. thus removing any channels of communication from the fenced frame to the embedding page. The actual url of the frame is also not visible to the embedding page as it is mapped to a urn:uuid by the browser and the urn:uuid is what is visible to the embedding context (details).
Similarly, in the direction from the embedder to the fenced frame, the usual channels like postMessage and script or frame tree access are not allowed. In terms of the attributes that are allowed to be set, publishers are able to set a very limited set of attributes e.g. only a subset of size values are allowed.
In addition to the communication channels mentioned above, there are side-channels that will need to be guarded against as well. The design document will go into more details there.
Note that the explainer mentions restricting network access in fenced frames for mitigating some side channels, but since rendering without network access would require a significant change in the ads ecosystem, fenced frames MVP will allow network access.
Initial public proposal
https://github.com/shivanigithub/fenced-frame
TAG review
None yet; a TAG review will be filed soon.
TAG review status
Pending
Risks
Interoperability and Compatibility
Since this proposal introduces a new HTML element, there may be some concerns and interoperability risks from the ads ecosystem or other browsers. There has been ongoing engagement via WICG for the FLEDGE use case and fenced frames have been part of those discussions.
From other browsers perspective, there may be medium-term interoperability risk with regards to having an architecture that enables the separation of fenced frames from the embedding page. Chrome's fenced frame design is based on a significant architecture project that makes this possible (Multiple Page Architecture).
(Note that there have been discussions with other browsers for fenced frames in the context of other use cases like unpartitioned storage access e.g. this issue, but that is not applicable to this fenced frame mode.)
Gecko: No signal
WebKit: No signal
Web developers: No signals
Is this feature fully tested by web-platform-tests?
No
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1111084
Launch bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1171739