Third-party cookies are currently an indispensable part of the online advertising ecosystem. As a user visits a website, code on the site makes an http call to a “third-party” server (i.e. a different domain from that of the site itself); the third-party server then serves a cookie back to the browser, and logs the user, plus a certain amount of information about them and the site they’re visiting. It’s this mechanism that means that you can be looking at jeans on target.com and then receive endless jeans ads across the internet – the retargeting networks are able to see that you’ve viewed jeans and use this to bombard target you with jeans ads.
Third-party cookies are also very useful for advertisers who are looking to understand the behaviour of users who’ve viewed or clicked on their ads, because they enable user behaviour on the advertiser’s site to be linked back to the ads that those users have seen, wherever they were served them.
So the function of third-party cookies is essentially to hand off a little bit of information about the user from one organisation to another. But it’s not the only way to achieve this – the other approach is to use server-side cookie sync. With this approach, if I visit the jeans page on target.com, this is logged by Target’s own data collection servers, and these servers (or at least other servers within Target) exchange this info at the back-end with, say, Criteo’s servers. This does create some challenges with user matching, because there is no common ID, but those issues are surmountable (and 3P data companies have two years to build a matching table from their current third-party cookie ID data).
Server-side cookie sync is already an established approach – it’s how companies like LiveRamp and other DMPs build connections between their data and their customers’ data. The disappearance of third-party cookies, however, will make this technology much more pervasive. This is worrying because, for all their issues, the data streams created by third-party cookies (or at least third-party tagging) are at least somewhat discoverable.
This week the Electronic Frontier Foundation published a piece of research they have done into the third-party data collection that is present in Ring’s Android app. They discovered that the app, without notifying users, is sending user data to a host of third-party sites, including Facebook, MixPanel and AppsFlyer. To unearth this information, the EFF researchers had to perform some pretty nifty tricks to intercept and unpack the encrypted traffic that the app was sending to these locations. Although it wasn’t easy to do this, it was at least possible, because the data flows were passing from the client device (the phone) through the researchers’ local network (where they could install sniffers) to the internet. By modifying the app locally to circumvent its encryption, the researchers were even able to see what attributes the app was passing to the third parties.
For server-to-server data flows, none of this is possible; the servers on each end are running in private data centres, and without access to the local network or codebase, decrypting encrypted traffic is not possible (a good thing generally, by the way). Even determining that company A is transmitting data to company B is like finding a needle in a haystack.
So if advertisers, publishers and DSPs/networks move to server-to-server data flows for user data, it will likely become harder to identify careless or malign sharing of user data, like the example of Ring. Users and regulators may feel better about the disappearance of “all those weird cookies”, but the unintended consequence could well be that protecting user privacy may become a lot harder in future.