FLEDGE is a Privacy Sandbox proposal to serve remarketing and custom audience use cases, designed with the intent of preventing third-parties from tracking user browsing behavior across sites. The browser will provide protection against microtargeting, by only rendering an ad if the same rendering URL is being shown to a sufficiently large number of people. We will require a crowd of 50 users per creative within the past 7 days before the ad can be rendered. This also helps protect users from cross-site tracking by preventing reporting rendered URLs that don’t meet the minimum threshold.
This protection is referred to as 𝑘-anonymity, and is enabled by a centralized server operated by Google that maintains global counts. Once a creative meets the minimum threshold, it is cleared to be rendered to users. You can check out our explainer for further details on the 𝑘-threshold, and how the 𝑘-anonymity service is designed within FLEDGE.
While the 𝑘-anonymity service provides a key privacy protection, it also could expose sensitive user data to this centralized server, such as IP address and the browser’s User-Agent string. This is why we are improving Chrome’s privacy measures by partnering with Fastly, an edge cloud platform that provides content delivery, edge compute, security, and observability services, to operate an Oblivious HTTP relay (OHTTP relay) as part of FLEDGE’s 𝑘-anonymity server.
With data being relayed through an OHTTP relay, Google 𝑘-anonymity servers do not receive the IP addresses of end users. The 𝑘-anonymity server is an incremental step towards the full implementation of FLEDGE. Note that this doesn’t impact IP addresses exposed to publisher origins through usual browsing behavior.
With Oblivious HTTP (OHTTP), a client can make multiple requests to a server without the server being able to use the properties of the requests to identify them as originating from the same client. It not only hides the client’s IP address from the server, but also prevents TLS sessions from being used to correlate multiple requests from the same client.
To implement OHTTP, we partnered with Fastly to operate a relay resource on our behalf. The user’s Chrome browser will send an encrypted payload in the body of an HTTP POST message for the 𝑘-anonymity server to this relay. The browser encrypts the message using keys that it fetches directly from the 𝑘-anonymity server on the Google domain. The relay will forward the request to a gateway that will run on Google servers. The relay therefore doesn’t see the content of the request but is aware of the user’s IP address. Conversely, the 𝑘-anonymity server (and gateway) are unaware of the user’s identity but can see the content of the request.
No action is required from developers or users, but we wanted to share some infrastructure that we’re putting in place to improve user privacy across the entire FLEDGE process.
Google intends to operate the 𝑘-anonymity server on behalf of all Chrome users who are using FLEDGE. 𝑘-anonymity checks apply to all third-party ad tech and Google’s own advertising services. The user is the person that benefits from 𝑘-anonymity, and the browser is the software that can choose to implement and enforce it.
The privacy-preserving properties of FLEDGE apply equally to Google and the broader ecosystem. This server will be called from Chrome, with support for Android expected later in 2023.
Photo by Ian Battaglia on Unsplash
This post is also available in:
English