Standards & regulation

Trusted Server’s Edge Cookie Can Outlive A Cleared Browser. IAB Tech Lab Says The Publisher Decides Who Receives It

Hamit Tümer ·4 min read·How we report Share Print
In this piece
    Below the waterline, only the keeper knows which outlet is running.
    Below the waterline, only the keeper knows which outlet is running.

    The story. Trusted Server is IAB Tech Lab’s open-source software for running ad calls on a publisher’s server and not in the browser. On the Digiday Podcast, Tech Lab’s Rowena Lam answered the privacy question that follows: once the browser cannot see the calls, the user has to trust the publisher. (Digiday, 10 November 2026)

    01What happened

    • The server-side move answers Apple. Digiday describes the industry rallying around server-side methods in response to Apple’s identity resolution crackdown, with Trusted Server the biggest example.
    • It removes the browser as a witness. A browser can see, and block, the calls a page asks it to make. Calls that run on the publisher’s server are out of the user’s sight.
    • The edge cookie is the sharp point. Trusted Server’s server-side identifier is created in part by hashing the user’s IP address with a secret key specific to the site’s domain.
    • Clearing cookies may not clear it. Digiday notes that a user who returns on the same IP address, to a site using the same key, gets an edge cookie that can be matched to the old one.
    • Sharing is a publisher decision. Lam: “Nobody downstream would automatically receive an edge cookie.” The publisher “would have to proactively decide” to send it to anyone.
    • Nothing is preset. Lam says there are “no defaults per se” and that Tech Lab is “not trying to make legal determinations on behalf of publishers.”
    • Logging ships with it. Lam says “pretty robust logging and auditing” comes “out of the box,” and that the software was designed from the start to integrate with consent management platforms.

    Lam’s wider argument is that server-side is “more privacy-preserving in general,” because the publisher can be “pretty surgical” about which partner is called and what data it gets. Digiday’s counterpoint is that the user has to take that on trust.

    02What it means inside a GAM network

    Our earlier pieces on Trusted Server covered what it fixes after Safari’s blocklist and what it costs a small publisher to run. This one is about who answers for it. In a client-side stack, a tag that fires before consent is visible to anyone with a browser inspector, including a regulator, a researcher or a journalist. In a server-side stack the only record is the one you keep.

    That shifts the weight onto three things you own. The first is the edge cookie’s behaviour. An identifier that can be rebuilt after a user clears cookies is, in plain terms, a persistent identifier, and a persistent identifier needs a lawful basis and an honest line in your privacy notice. Whether it comes back depends on your key and your configuration, so it is your decision, not the software’s.

    The second is the list of who receives it. “No defaults” means every downstream partner that gets the identifier got it because someone on your team switched it on. Each of those is a data-sharing decision that should match your consent string and your partner contracts.

    The third is the log. If the browser can no longer show what happened, your server log is the evidence that consent was respected. Lam says a misconfigured server-side setup “could be an issue.” When it is, the issue sits with the publisher, because the publisher made every choice.

    One caution on scope. Digiday’s piece is a podcast write-up. It does not test a live deployment, and it does not say how regulators will treat an IP-derived identifier. Read it as the list of questions to settle before you deploy.

    Moving ad calls to your server gives you control the browser never allowed, and the accountability comes with it.

    03What publishers should do about it

    04The bottom line

    Moving ad calls to your server gives you control the browser never allowed, and the accountability comes with it. Trusted Server ships the switches and the logs. It does not ship the decisions. A publisher who can show the configuration, the sharing list and the log has a good answer when someone asks. A publisher who cannot is asking readers for trust with nothing behind it.

    If you want a second read on a server-side setup and its consent wiring, see our publisher services. Earlier in this series: what Trusted Server fixes after Safari’s blocklist and what moving identity server-side costs a small publisher.

    Sources & caveats

    Sources: Digiday, “Can web users trust ad tech’s server-side shift?” (10 November 2026), for the description of Trusted Server and the edge cookie, the account of how a cleared cookie can be matched again, and every quotation from Rowena Lam, senior director of product, privacy and data at IAB Tech Lab, speaking on the Digiday Podcast. The reading for GAM publishers and the recommendations are APH desk analysis, not legal advice.

    The weekly

    One letter a week, from the desk that runs the auctions.

    What actually moved in yield, CTV and curation across our publishers — written by the people who saw it, not a content team. No digests, no roundups, one email.

    One email a week. Unsubscribe in one click. We never share or sell the list.

    More from this issue

    Ran alongside this piece in the Weekly of 11 November 2026.