Moving Identity Server-Side Won’t Settle the Question of Trust
Max Baum, Chief Product Officer, Utiq
Apple’s latest WebKit restrictions have led to another round of technical changes in digital advertising. Identity providers are rebuilding parts of their infrastructure, and publishers are testing server-side options so their audiences stay addressable as browsers block more.
A recent ADZINE article looked at how the industry is responding. Apple has not published its blocklist, and it has said a forthcoming WebKit update will let it add domains remotely, without a new version of iOS. That raises a question the industry has not yet answered: who should decide whether an identifier can be created, and on what terms it is passed between companies.
Server-side identity after iOS 27
Since iOS 27, WebKit has blocked network access to domains Apple associates with identity resolution. Providers whose technology relies on browser requests to third-party domains now have to change it. ADZINE reports that ID5 is moving some identity functions onto publishers’ own infrastructure, and the IAB Tech Lab’s Trusted Server Framework is attracting renewed interest. When servers communicate directly, identifiers can be sent without passing through the browser, where the current restrictions apply.
Server-side identity is a legitimate architecture, and it gives publishers more control. At Utiq we already use it in part, combining a first-party subdomain with server-side components, and we generate an identifier only after the user has consented.
Problems start when a provider moves identity server-side mainly as a response to platform restrictions. Providers adapt and platforms respond with further controls, and ADZINE rightly makes no prediction about whether Apple will extend its restrictions to other technical layers. The article concludes that whether Apple’s block applies depends on each provider’s architecture, including where an identifier is created and how it is sent into the bid stream. Whether an identifier should be created in the first place is a separate decision, and in Europe the law gives it to the user.
Researchers tracked 145 million bid requests
ADZINE cites a September study by researchers from the New Jersey Institute of Technology, Indiana University, Adalytics and DeepSee.io. They analysed more than 145 million header bidding requests from around 616,000 websites over 41 months, and found that by May 2025, 83.76% of the websites studied sent at least one Extended Identifier. Of the 18 largest identity providers in the data, 12 created persistent identifiers that could recognise the same user across visits, websites, devices and months. The researchers’ crawler never responded to a consent banner, yet 16 of those 18 providers sent identifiers on websites with EU or UK domains.
The authors conclude that ‘identifiers generated without consent and reused across visits, websites, and devices threaten user privacy’. They call for industry standards ‘that require identity providers to state what identity signals are used’, and suggest that websites should only call on an identity provider once their compliance requirements are met.
Moving an identifier that was created without proper consent onto a server does nothing about how it was created. Deterministic identifiers created with explicit consent deserve to be judged on their characteristics and on the controls over their use. In both cases, the industry needs to know where an identifier came from and the conditions it is used under.
What GDPR and ePrivacy require
Europe’s GDPR and ePrivacy rules govern how personal data is processed and when technologies may store or read information on a user’s device, setting out individual rights and the circumstances in which consent must be obtained. A person’s informed choice should decide what happens to their data, and that choice should be respected at every stage of the advertising process.
Identity signals can pass through several intermediaries between publisher and advertiser, and each one is responsible for how it handles and shares them. Consent collected by a publisher therefore has to stay effective through every later stage of processing, including when identity data moves from one company to another.
Making consent technically enforceable
The Transparency and Consent Framework (TCF) already lets participants in digital advertising pass users’ choices to one another. Passing a choice on is only part of the job, though. The industry also needs technical controls that make sure those choices are respected whenever an identifier is processed, from encoding through to activation, and privacy-enhancing technologies (PETs) can strengthen those controls where identity data moves between organisations. We see four requirements as the minimum standard for responsible identity infrastructure, whatever the provider, and whether it runs in the browser or on a server.
- Consent must come before an identifier is created, never after it. That consent should then govern everything that happens to the identifier.
- Users need to know who creates an identifier, and they need to be able to withdraw consent at any time. Their decision has to be respected wherever the identifier is used.
- Binding standards must govern how identifiers are distributed and used. They should set out how identifiers are shared with partners, including disclosure of the signals and methods used to build them.
- PET concepts should inform how identifiers are encoded and sent between parties. Technical controls should preserve the user’s choice through every stage of processing, so that each participant can show the conditions were met.
Apple’s blocklist and the user’s choice
The industry’s response to Apple’s restrictions shows how quickly advertising technology can change its architecture. Yet a change of architecture settles nothing about consent or accountability. Common standards would give everyone a consistent way to assess identity practices and compare providers, from the signals used to build identifiers to the controls on how they are distributed.
Apple is right to challenge covert tracking. Its blocklist, however, gives one technology company considerable control over which identity practices can operate in its browser. As identity infrastructure is rebuilt, the test for any identifier should be the one European law already sets: whether the user consented, and whether that consent is still respected wherever the identifier is used. Apple protects users from tracking. Sometimes it also overrides the decisions those users have already made.
