Understanding the browser privacy proposals and the tradeoffs, and the technical consequences for publishers, advertisers, and the future of the ad-supported web is paramount.
Why it matters — The advertising industry has a massive stake in the deprecation of third-party cookies, and unfortunately, there's no silver bullet. While the alternatives offer the media industry attractive solutions, we need to understand the core design decision of each proposal to separate the essential statement of each proposal from the technical consequences of its thesis. In this piece, we look at the design decisions and how they balance protecting user privacy while preserving the value of personalized advertising.
Chrome’s announcement to deprecate third-party cookies and provide alternative rails for some functionality that currently relies on third-party cookies via Privacy Sandbox hit the advertising industry like lightning. The Privacy Sandbox is a set of proposals to make the internet more privacy-friendly for users.
At the same time, providing a route for ad-supported content creation for publishers and a valuable advertising channel for brands. To know what’s possible, the Chrome team publishes and iterates on proposals under the auspices of the W3C community groups. Most of the coordination is happening via W3C regular meetings and Github. Additionally, other companies have carefully crafted proposals to protect user privacy while preserving the value of personalized advertising.
Understanding the differences between the proposals requires awareness of where the conflict lies. Each proposal puts a stake in the ground. All of the details flow from that. However, knowing which proposal elements were deliberate and which elements simply flow from deliberate decisions takes some investigation.
Here we analyze each proposal’s core design decision and separate its essential statement from its thesis’s technical consequences. The core Privacy Sandbox question is, “Who can the browser trust, and with what information?”
On one side is the status quo. Most parties can send and receive information from the browser if the publisher permits or delegates the interaction. Conversely, the user’s browser sits between the user and every website they visit. The browser extracts information from the site but prohibits the site from understanding its audience.
Each Privacy Sandbox proposal answers this question at its core, with substantial consequences for publishers, advertisers, and the future of the ad-supported web.
Google’s Bird of a Feather
The bird name puns began on August 19, 2019, when Google published the original FLOC proposal. FLOC, or Federated Learning of Cohorts, provides some of the value of cross-site behavioral advertising. Although, without enabling cross-site identity for anyone other than the browser. FLOC places users into cohorts based on common web browsing behaviors and patterns. There are no predefined buckets of “similar” browsing patterns; they emerge organically, and browsers are grouped based on common observations. Chrome doesn’t know what a particular cohort ID represents, but users in the same cohort exhibit similar browsing behaviors. This would enable advertisers to identify which cohorts appear valuable for their campaigns. And, therefore, target advertising to those cohort IDs on other sites, but without needing a user identifier.
Advertising audience data can be split into two sources: publisher-side and advertiser-side. The publisher has some information about the impression that may be relevant to advertisers. Advertisers have some information about the kinds of users they want to reach. This audience’s intersection creates a good ad opportunity. FLOC provides publisher-side information about an ad impression’s value to advertisers that may not have previously interacted with this particular browser. Therefore, it’s intended for prospecting use cases. Chrome ran an origin trial for FLOC in early 2021 and is redesigning based on participants’ and interested parties’ feedback.
FLOC’s answer to the question of whom to trust and with what information is to trust the browser with cross-site browsing information and to distrust all other parties. This includes the publisher, but with the promise that the results will be available to the publisher and its advertisers.
Just One TURTLEDOVE
The bird name puns continued when Chrome published the original TURTLEDOVE proposal on January 16, 2020. TURTLEDOVE stands for Two Uncorrelated Requests, Then Locally-Executed Decision On Victory. In Turtledove, the browser holds the auction on-device by soliciting bids in two separate requests. The first is a contextual request that includes items like the website URL. The second request includes information about what ads the user may be interested in seeing.
Whereas FLOC is helpful to advertisers for general interest-targeting or prospecting, FLEDGE attempts to fill the use-case gap of retargeting or advertiser-driven audience selection.
TURTLEDOVE’s Origin Trial is known as FLEDGE (“First Locally-Executed Decision over Groups Experiment”). So, when you hear about FLEDGE changes, those changes are the direct evolution of TURTLEDOVE via the FLEDGE experiment.“The FLEDGE proposal” is TURTLEDOVE plus modifications made in the trial stages.
So, where does TURTLEDOVE draw the line between trust and openness? TURTLEDOVE’s core thesis trusts only the browser. This is evidenced by the design decision to have all InterestGroups live on the browser, regardless of membership size. To protect individuals’ privacy and mitigate de-identification attacks based on placing users in very small segments, TURTLEDOVE took the extreme design decision of keeping all InterestGroups on the browser, whether they presented a privacy risk or not.
SPARROW — Criteo Spreads its Wings
Next, Criteo’s SPARROW, published on GitHub on April 22nd, 2020, offered a different path to achieving the same privacy desiderata as TURTLEDOVE. But with an alternative mechanism. SPARROW stands for Secure Private Advertising Remotely Run On Webserver. SPARROW’s primary iteration on the slightly-earlier TURTLEDOVE is the introduction of a publisher-side “Gatekeeper” function fulfilled by a server. This Gatekeeper is a server trusted by the publisher and browser to protect the user’s privacy. It enables a solution that relies on server-side processing instead of keeping everything in-browser, regardless of privacy impact.
In SPARROW, the browser sends a bid request to the Gatekeeper server that contains contextual and behavioral information colocated in that request. But the Gatekeeper ensures that the colocated behavioral and contextual data doesn’t leak further. Contrary to TURTLEDOVE, which triggers two bid requests, one with and one without contextual data, SPARROW posits separating contextual from behavioral data in a bid request doesn’t need to occur on the browser. By enabling an off-device server to perform the separation, SPARROW offers some advantages without compromising the user’s privacy guarantees.
First, reporting, pacing, and some attribution can occur in real-time or near-real-time instead of delayed or not in a world where the browser has no trusted off-device server to trust.
Second, SPARROW claims introducing this Gatekeeper function into the ad tech ecosystem can occur much more quickly. This is because it can be implemented in parallel with the current infrastructure, causing smoother and less disruptive fast adoption.
What core argument is SPARROW making about whom to trust? SPARROW makes two arguments. First, SPARROW argues the trust boundary can be enlarged to include the browser. Parties that act on the users’ and publishers’ behalf can be fortified with technical guarantees that don’t require blind trust. SPARROW’s second core argument is for a substantial amount of online advertising, individual profiles are unnecessary. They say advertisers want to buy audiences and measure the effectiveness of the audiences. They don’t need large-scale individual-level cross-site analysis to be effective.
PARAKEET — Microsoft Edge’s Final (Bird) Word
Finally, Chrome isn’t the only browser adopting new privacy-protecting measures. The Microsoft Edge team published the PARAKEET proposal in February 2021. PARAKEET stands for “Private and Anonymized Requests for Ads that Keep Efficacy and Enhance Transparency.” Building on TURTLEDOVE’s goals and SPARROW’s insights, PARAKEET zeroes in on limiting the amount of granular high-fidelity information leaving the browser. However, it attempts to optimize user privacy and ad efficacy simultaneously. PARAKEET rejects the assumption that user privacy and ad effectiveness can’t coexist and redefines the challenge of solving for both.
The PARAKEET proposal, like SPARROW, introduces the idea of a trusted server doing some off-device computation to gain the benefits of an aggregated view of what information has been shared with parties previously. It’s something the browser can’t feasibly do alone today. Think of PARAKEET as a filter that constantly checks how much information about a particular browser has been shared with each recipient. And in real-time, it obfuscates or removes key pieces to ensure that the recipient can’t meaningfully single out that browser. This obfuscation and information removal can be done in a way that’s mathematically guaranteed to make it nearly impossible for a bad actor to re-identify a browser.
What’s Next
Each proposal has clarified the options in front of us and which tradeoffs are unavoidable. By Q3 2023, we expect the Privacy Sandbox APIs to be launched and generally available in Chrome. As developers adopt these APIs, we now intend to begin phasing out third-party cookies in Chrome in the second half of 2024. You can always find up-to-date timelines and milestones on the Privacy Sandbox website. The immediate path forward continues iterating on these proposals. It develops technical specifications that work for all major publishers and advertisers to continue monetizing content. This also includes advertising products to potential customers and protecting consumer privacy.
