Google in the next few days plans to begin testing fenced frames, a proposed web API to help its Privacy Sandbox ad technologies meet commitments to privacy of a sort.
Fenced frames are designed to take the place of inline frames, or iframes, for specific scenarios like delivering interest-based ads without betraying interest data to the web page in which they’re embedded.
Inline frames are web pages contained within other web pages, often across different domains. Unfortunately from a privacy perspective, they’re porous, supporting APIs like window.postMessage that enable the exchange of data between the enclosing parent frame and the iframe within.
For example, a publisher website might send a visitor-specific identifier to an embedded iframe served by an ad tech firm. This sort of behavior is commonly used for tracking people across domains.
Google’s Privacy Sandbox – dismissed by rivals as more private only in the context of Chrome’s baseline – aspires to rewrite online ad tech. Google wants to keep targeted advertising alive while offering greater privacy than the surveillance bonanza made possible by third-party cookies.
Google has quite a bit of browser tech to test and has been running rather behind given its goal of dropping support for third-party cookies in Chrome by the end of 2023, competition regulators permitting. Its initial experiment with FLoC, or Federated Learning of Cohorts – for serving interest-based ads – was allowed to expire in July, 2021, in order to allow further technical refinement. In March, 2022, Google announced testing for its FLEDGE API, for remarketing, and its Topics API, a FLoC replacement for interest-based advertising.
Fenced frames are an essential part of Google Privacy Sandbox vision because they’re the mechanism that, hopefully, will deny data accessible to one web domain from being piped to a different web domain.
“Once third-party cookies have been removed, [embedded] 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,” wrote Shivani Sharma, a Google software engineer, in a message announcing the testing plan to the Google Blink developer group.
“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.”
Google’s FLEDGE API, for example, calls for using a fenced frame to render the interest-based ad that wins an ad auction run on-device (which prevents private data from being captured as it could be in an auction run on a remote server). The idea is that the publisher webpage embedding the fenced frame ad does not know the ad’s URL and the ad provider does not know what sites the web user is visiting, a far more privacy-preserving scenario than the current cookie-based model of advertising.
Fenced frames share some conceptual similarity to Firefox’s Total Cookie Protection, which creates separate spaces for cookies so they can’t communicate. Both are partitioning mechanisms. The similarity extends to the need for exceptions – ways to communicate across the barrier for certain desirable or necessary functions.
The section on Privacy Considerations in fenced frames points out that it may be useful to share some data across the so-called fence. The problem is how to do so in a way that can’t be abused to violate privacy.
For example, it may be useful to send window size data to the embedded Fenced Frame, but to do so, Google has to limit the values that can be sent to preclude possible usage as a covert communication channel. Similarly, the IntersectionObserver API, used for determining how page elements overlap – e.g. detecting when display ads are obscured – has the potential to be used for repositioning frames to communicate a user identifier to a fenced frame. So fenced frames have to limit the scope of that API.
Then there are concerns about side channel communication that’s possible over the network, via data derived from URL navigation, or the way permissions get delegated among top-level frames and embedded contexts. A lot of work still needs to be done to integrate fenced frames into the web platform, and it’s unclear whether other browser makers will support the idea.
The fenced frames origin trial is expected to begin during Chrome 102’s beta period, which ends May 5th, and to run until at least the Chrome 105 beta period (August 4th through Aug 11th), before the API gets transitioned to Chrome’s stable channel. ®