As the two-year deadline before third-party cookies are obsolete on Chrome edges closer, ad tech and browser companies are busily proposing privacy-centered replacements so advertising can continue to work on the web.
The latest such proposal — Dovekey — comes from the Google team and was published to GitHub last week. The proposal is part of its “Privacy Sandbox” initiative that looks to replace the functionality served by cross-site tracking using privacy-focused technologies that mitigate workarounds such as fingerprinting and network-level tracking.
How did we get to Dovekey?
Here’s what advertisers and publishers need to know about Dovekey.
Dovekey is a response to a privacy proposal from ad tech company Criteo called SPARROW, which in turn was a response to Google’s privacy proposal TURTLEDOVE.
TURTLEDOVE (“Two Uncorrelated Requests, Then Locally-Executed Decision On Victory) is a framework as part of Google’s Privacy Sandbox. The key element of the proposal was that all auction decisions would take place in the browser rather than in ad servers, which in theory would stop bad actors being able to siphon off bidstream data to build profiles on users.
The industry soon saw that this effort could put a strain on bandwidth.
“You’re now making an enormous amount of decisions on the browser — it’s not clear that’s an improvement of having cookies on the browser,” said ad tech company Beeswax CEO Ari Paparo.
Also, while the proposal would allow for techniques like interest group and contextual targeting, it wasn’t clear how things like A/B testing, frequency capping and brand safety would work.
And there’s the small matter of the world’s most-popular browser Chrome being owned by Google.
“[The TURTLEDOVE engine is an] unauditible engine in a browser controlled by Google,” said Paparo.
French ad tech company Criteo’s answer to TURTLEDOVE’s drawbacks is SPARROW: “Secure Private Advertising Remotely Run On Webserver.”
Rather than being held in the browser, the auction process and logic would be looked after by an independent “gatekeeper.” Also, advertisers would receive real-time data feedback.
But there were some industry concerns about how the gatekeeper could be fully entrusted to keep user and advertiser data safe — especially if reporting is moving in real-time. Plus, there are only a limited number of companies with the capacity to be a gatekeeper.
“If you made a list of all the companies that could do it, they almost all have ad divisions — cloud companies, telcos, Google, Facebook — who is not conflicted in doing this?,” said Paparo.
So what’s Dovekey?
Google’s Dovekey proposal builds upon SPARROW.
As Google puts it in the GitHub proposal: “The key idea of Dovekey is that we can get most of the benefit of SPARROW bidding even if the Gatekeeper server just acts as a simple lookup table.”
The “gatekeeper” in this instance would be what Google describes as a “key value server” — a simplified version of an ad server, which could be run by a third-party company (not just Google). It receives a “key” — such as a contextual ad signal plus an interest group — and it returns a value — a bid.
Dovekey only covers the bidding and auction elements of the ad buy — for use cases such as an advertiser utilizing its first-party data for retargeting in a privacy-safe way — but not the measurement side of the equation.
Why’s that better than the current real-time-bidding setup?
“The primary piece is trust,” said Chetna Bindra, senior product manager for user privacy and trust at Google.
The idea is that there’s no potential for advertisers, website owners and ad tech vendors to gather information about individuals.
While the ad server does have access to that data, Dovekey proposes there will be policies or restrictions in place to ensure there is no leakage.
What will those policies and restrictions look like?
That’s still up for debate. One route could be a set of standardized policies that the industry comes together to agree on — and each ad server would subject themselves to audits to ensure they were adhering to the rules.
The other, more complicated route, would be to look at more technical restrictions, such as cryptographic protocols. Differential privacy techniques could also be applied to prevent a bad actor using a compromised ad server and linking user IDs with a specific contextual advertising request.
There’s an even more complicated route that would involve setting what’s known as a single-server Private Informational Retrieval system (so complicated it seems, even the GitHub links to a Wikipedia page) so that the server doesn’t learn anything at all about the user data it receives. This option, however, would likely involve higher setup costs.
What does the rest of the industry make of Dovekey?
“Our goal behind SPARROW was to push the industry toward building an advertising solution that balances the consumer, the advertiser and the publisher’s needs, and are encouraged to see the Google Ads team propose a design that builds upon SPARROW in their latest proposal, Dovekey,” said Charles-Henri Henault, Criteo vp of product, ads platform and analytics in a statement.
Paul Bannister, chief strategy officer at Cafe Media, said — on the surface at least — Dovekey looks like a positive enhancement to SPARROW.
“I’d say this is good progress and some early vindication for the Chrome team as it shows the value in opening up this process to the [World Wide Web Consortium, known as the W3C] and an open-source approach,” Bannister said.
It’s ad tech and it’s Google. So it’s always a possibility.
Criteo’s Henault pointed out, for example, that it’s still unclear how many contextual modalities would be made available. That would affect how much flexibility could be brought to this approach.
“Also, without any form of low latency feedback about user engagement with the ad, the proposal may keep marketers in the dark and leaves them with little room for doing anything else than always serving the same ad to the same interest group,” said Henault.
What happens next?
As with all of Google’s Privacy Sandbox proposals, the company is inviting industry feedback on GitHub and within the W3C’s cross-industry Improving Web Advertising business group.
If the business group unites on the proposal, they could take it to a suitable W3C working group — or create a new one — to begin working on a spec.