With the imminent demise of third-party cookies in Chrome, and other browsers blocking them already, everyone is talking about “cookie-less” solutions. But what exactly are “cookie-less” solutions? And how will they help – or hurt – publishers?

For the most part, when someone says they have built a “cookie-less” solution, they mean that they don’t rely on third-party cookies. Instead, they use first party cookies or locally store some bit of information they can use later to identify the user.

There are obvious challenges with using first party cookies or local storage compared to third party cookies. Notably, that they aren’t accessible across domains. Therefore, identifying a user from one site to the next is not possible without additional technology or signals.

However, the benefit is that all browsers currently still allow them to be set with JavaScript. (Though, in some cases, set with shorter TTLs). For our purpose here, and to keep things focused, let’s make the false assumption that any platform offering a cookie-less solution can successfully and accurately connect these first party cookies across domains at scale.

First parties and risk

So, if third party cookies are essentially dead and first party cookies can work as a viable replacement, this sounds perfect. Well: Not exactly.

Any identity provider that can read and write a first-party cookie to store their own identifier, also has access to all of the publisher’s own cookies. (With the exception of HTTP cookies with HttpOnly properly set). They also have access to any other first-party cookies set by any other technologies (ad tech or otherwise) on the page.

There are three problems with this level of exposure:

1. Data from first-party cookies could be leaked to other platforms who are incorrectly reading first-party cookies that they did not set.
2. Platforms can overwrite the publisher’s own first-party cookies or the first-party cookie of another platform, causing issues.
3. Cookies set by the publisher and all platforms writing first-party cookies are included in HTTP requests to the publisher’s servers. Cookies can become so large that the browser starts to limit them. (~4kb is the limit in most browsers.) Or they will cause network latency and increase consumers’ bandwidth usage.

Too many cookies

If there were only a handful of identity providers being used by the publisher, these may not pose too much of a risk. The publisher could properly audit the code and manage the cookie space accordingly.

Unfortunately, there are already 15-20 different companies offering identity solutions using first-party cookies. Standards have not been established. And that  means it is open season for identity providers to manage first-party cookies as they wish. Yes, even though these cookies are supposed to belong to the publisher.

Prebid.js is the exception. It employs a standard implementation for identity providers to read/write cookies and publishers have control over the name of the first-party party cookie used by default. But even here, several of the modules handle cookie naming, reading, and writing on their own.

Check your IDs

This leads to the question: Why do we have so many “identity providers”? Are they all doing something unique and special? Some are. But many are just ad tech companies “offering a first-party cookie solution.” Unfortunately, these solutions are simply a means to an end for platforms to get their own ID in the bid stream to make it usable for themselves.

This may seem necessary and feasible today. But what happens when every ad tech platform decides they need their own ID in the bidstream? Publishers would need to support hundreds of IDs on their page. SSPs would need to pass these IDs to DSPs. And Data Platforms and DSPs would need to be able to ingest and understand all of these IDs. Beyond just these technical challenges, having this many IDs poses significant privacy challenges, like we have today with 3P cookies. And it certainly does not move the industry in the right direction for consumers.

Shared solutions

At ID5, we believe there are identity providers that deserve to be on publisher pages and in the bidstream: those that are providing a shared ID for all platforms to use. However, vendors that are creating “cookie-less” solutions simply to power their own platform should instead use these shared IDs as a currency to transact across platforms while using their own ID for internal purposes and building their own graph.

Publishers need to push back on any platform-specific “cookie-less solutions.” They are not beneficial to the industry and are causing confusion and technical challenges. Shared ID solutions improve technical efficiencies and provide a common language to communicate about users across platforms. They also allow the various platforms in our industry to focus on what they do best. Identity should be a commodity and not a differentiator and should be handled by companies who focus solely on providing shared identity solutions.