ID5's own technical documentation reads like the reason Apple's Safari now refuses to talk to its servers, according to an opinion article published on October 8, 2026 by Pesach Lattin, founder of the trade newsletter ADOTAT. Lattin also wrote that ADOTAT had learned ID5 will not be removed from the private Safari blocklist that has stopped requests to its domains since iOS 27 shipped, while The Trade Desk saw its ad-serving domain unblocked in a test build 13 days after Apple's first reply to its bug report. Apple has made no public statement about either company.

In Short

Apple's Safari browser has a hidden list of advertising web addresses it refuses to contact, and both The Trade Desk and the identity company ID5 ended up on it. An ADOTAT columnist argues that The Trade Desk could get off the list because its blocked address only delivers ads, while ID5's whole product is recognising the same person across different websites, which is the very thing Safari is designed to stop. Apple has not explained why any company is on the list, so the argument rests on comparing ID5's own published instructions with Apple's published privacy rules, and on ADOTAT's unnamed sourcing that ID5 is staying blocked.

What the column claims, and what it does not

The piece runs under the headline "ID5 Calls Its Signals Consented. Apple Blocked It Anyway, For Good." and carries the standfirst "Inside Safari's secret blocklist: The Trade Desk got off it in 13 days. ID5 is not getting off at all." It is an opinion column, written in Lattin's usual combative register, and much of its force comes from juxtaposition rather than new documents. Two of its claims are reporting rather than argument. The first is that "ADOTAT has learned that ID5 is not coming off that list. Not in the next beta. Not after a polite bug report. Not after a very sincere engineering memo." The second is that Apple's published policy "grants no exceptions to specific parties."

The first claim is unsourced in the text. Lattin does not say who told ADOTAT, whether the information came from Apple, from ID5 or from a third party, or how firm it is. Apple has not commented publicly, and the column itself says Apple "has explained neither in public." The prediction about ID5 therefore carries the weight of an anonymous tip and nothing more until either company confirms it.

The second claim refers to WebKit's tracking prevention policy, the document Apple's browser engine team has maintained since 2019. Lattin uses it to frame the asymmetry at the centre of the piece: "So one company got a fix and another company got a wall, and Apple has explained neither in public."

The attached capture of the column is cut off after the section that lists other affected companies. A subscription wall follows. Anything Lattin wrote beyond that point is not covered here.

ID5's documentation as the charge sheet

The core of Lattin's case is that Apple never needed to explain the block on ID5, because ID5 had already done so in its own integration guides. "Apple has never said why ID5 is on the list. It doesn't need to. ID5's own documentation reads like the charge sheet," he wrote.

He quotes three passages from ID5's partner documentation. The first: "Signals passed in the ID5 ID request are used to inform ID5 ID connections across domains." The second: "'Hard signals', such as hashed email addresses, take priority for cross-domain linking purposes, and help to train ID5's probabilistic algorithm." The third is an instruction to partners: "Ensure IP address and user agent are always included in the PD string." The PD string is the partner data field integrators pass to ID5 alongside the ID request.

Lattin then set those lines against Apple's own definitions. According to the column, Apple's tracking prevention policy targets cross-site tracking, which it describes as recognising the same person across unrelated websites, and names fingerprinting as one method. Apple's technical writing, Lattin noted, breaks fingerprinting down into device characteristics, network characteristics such as IP address, user settings, behavioural patterns and accumulated traits. "IP address. Browser details. Cross-domain linking. You don't need a decoder ring. ID5's product and Apple's prohibited behavior overlap almost perfectly on paper," he wrote.

The distinction between hard signals and probabilistic matching matters here. Hashed emails are deterministic signals: a logged-in reader supplies an address, and the same hash on two sites links the visits with high confidence. Probabilistic matching infers the link from weaker inputs, of which IP address and user agent are the most common. ID5's documentation, as quoted, says the deterministic signals train the probabilistic model. That is a standard design for an identity graph, and it is also, on Lattin's reading, a description of the process Apple's policy exists to interrupt.

The caveat the column concedes

Lattin does not claim the inputs alone convict ID5. "To be fair, and we will be, sending IP address and user agent does not by itself make every ID5 implementation fingerprinting. Plenty of ordinary web traffic carries both," he wrote. Every HTTP request on the web carries a user agent header, and every connection exposes an IP address unless something such as Apple's iCloud Private Relay hides it. The question, in his framing, "is what happens next, and ID5's own words describe what happens next: connections across domains."

That is an inference, not a finding. Nothing in the column shows Apple citing ID5's documentation, and nothing shows how ID5's production systems actually weigh IP address against hashed email in any given match. An August PPC Land profile of the company noted that no independent audit of ID5's match precision has been published, and that the independent studies which found low match rates for IP-based linkage did not test the ID5 ID directly.

ID5's public defence has rested on consent. The company describes its technology as connecting consented data into persistent identifiers. Its chief executive, Mathieu Roche, wrote on LinkedIn that ID5 would handle iOS 27 as it handled previous platform changes so publishers could keep monetising consenting traffic, as PPC Land reported on October 3. Roche described the change as an attack on the web's ad-funded business model, shipped without warning or consultation.

Lattin accepts that consent is a real legal position. "That's a real legal posture, and nothing here says ID5's consent framework is invalid or unlawful," he wrote. His argument is that Apple stopped treating consent as relevant to fingerprinting years ago. He quotes Apple's documentation for required-reason APIs, the set of iOS interfaces app developers must justify using: "Regardless of whether a user gives your app permission to track, fingerprinting is not allowed."

He is careful about the limits of that quote. "That's an app rule, not a Safari rule, and it would be sloppy to call it the legal basis for this block," he wrote. "But it tells you exactly how Apple thinks. In Cupertino, a consent string is not a permission slip. You can be compliant with GDPR and still be the thing Apple's browser is built to stop."

That last sentence captures the practical problem for any vendor whose product rests on a consent signal. Under European law, a valid consent record is the basis for processing personal data. Under Apple's browser policy, as Lattin reads it, the technique is the problem, regardless of what the user agreed to. The two systems do not ask the same question, so passing one test says nothing about the other.

Plumbing versus product

The column's explanation for why The Trade Desk escaped is the most concrete part of the argument. Apple's block hit adsrvr.org, the domain The Trade Desk uses to serve ads. The Trade Desk's engineers, Lattin wrote, "made a narrow, technical case: an ad delivery endpoint is not an identity endpoint, and blocking it breaks ordinary advertising, which Apple's own policy says it doesn't intend to break. They sent documentation. Apple investigated. A beta shipped."

ID5, in his account, has nothing equivalent to offer. "Its endpoint is not plumbing sitting next to an identity business. The endpoint is the identity business," he wrote. "There's no ad-delivery function to carve out, no innocent pipe to separate from the guilty one. When the product is cross-domain recognition, asking Apple to narrow the rule to 'just the tracking part' means asking Apple to unblock the whole company." The phrase he uses for the distinction is "the difference between a misclassified domain and a classified company."

The technical detail supports the shape of the argument. PPC Land's analysis of the WebKit code found that the block operates at the registrable domain level, or eTLD+1, so every subdomain of a listed domain is covered. The bug report filed by The Trade Desk's Ian Meyers listed two ID5 domains, id5-sync.com and eu-1-id5-sync.com. Both exist to synchronise and resolve the ID5 ID. Neither delivers creative. Any carve-out Apple might make for ad delivery, of the kind Meyers argued for adsrvr.org, would have nothing to attach to on ID5's side.

What it means commercially

Lattin frames the outcome as a sales problem rather than a browser problem. "A universal ID that doesn't resolve in Safari is a universal ID with an asterisk the size of the iPhone," he wrote. "Every sales call now starts with a footnote. Every publisher integration now comes with a question about which browsers actually return an ID. Every buyer who paid for addressable reach is entitled to ask what fraction of it was ever addressable."

That last question has particular edge for ID5, whose pitch has long been built on Safari. In December 2024, ID5 and OpenX said their integration raised reach across Safari desktop by 58% and mobile web by 37% compared with cookie-based solutions, figures supplied by the companies themselves. Safari was the environment where an alternative identifier was supposed to earn its fee, because third-party cookies there had been blocked by default since March 2020. A block on the identity domain removes the use case where the product was most differentiated. Permutive's August data, cited in PPC Land's coverage of ID5's response, put the CPM penalty for impressions without an identity signal at 41%, a vendor estimate rather than an independent measurement.

The 13 days

The Trade Desk's route off the list is documented in public because it ran through WebKit's bug tracker. Lattin's reconstruction matches the timestamps PPC Land recorded on October 6. Bug 324771 is titled "Inclusion of adsrvr.org in IS_REQUEST_UNCONDITIONALLY_BLOCKABLE domain list." Lattin dwelt on the constant name. "Note the phrase. Unconditionally blockable. Not 'blocked if it fingerprints.' Not 'blocked when suspicious.' Unconditionally."

Apple's John Wilander replied on September 22: "Thanks for filing, Ian! I also got your email. We're investigating." On September 28 he wrote: "I will let you know if and when any changes are available for you to test." On October 5 he wrote: "A new iOS 27.2 beta went out today. Please test with it. And thank you for the technical documentation you provided." Meyers answered the same day: "Thanks, John! Acknowledged I see the changes in the 24B5099f build. We will test and report back if there are any issues."

September 22 to October 5 is 13 days, which is the figure in the headline. "That's it. That's the whole public record of Apple responding to anyone about this list," Lattin wrote. "Polite, quick, and completely silent on the one question that matters: why was the domain there in the first place?"

Where the column goes further than the record

Lattin describes The Trade Desk as "unblocked in a test build." The public thread supports something narrower. Meyers said he could see "changes" in build 24B5099f and that The Trade Desk would test. Neither party has said in the thread that adsrvr.org was removed from the list, and as of PPC Land's October 6 capture the bug remained open with status NEW. A beta change is also not a shipping change: the fix reaches ordinary iPhone users only when iOS 27.2 is released, a date Apple had not given. The column's framing of The Trade Desk as having "walked" is a reasonable reading of where the thread pointed on October 8, but it is a reading.

The same caution runs the other way. Lattin's claim that ID5 is "not getting off at all" is stated as fact in the standfirst. It depends entirely on ADOTAT's unnamed sources.

Correcting the trade press

Lattin used part of the column to separate what Apple has said from what others have attributed to it. He pointed out that the description of the blocklist as a hard block on domains that power "post-cookie" identity came from Meyers's complaint, not from Apple. "Apple didn't say that. Apple didn't say anything about intent. Wilander talked about remediation and nothing else," he wrote.

He then drew a line between two sentences the industry tends to merge. "'Apple has long opposed fingerprinting' is true and documented, in the WebKit policy since 2019, in a July 2023 developer announcement, and in Apple's Safari privacy writeups," according to the column. "'Apple accused ID5 of fingerprinting' is not." Lattin wrote that ADOTAT found no public Apple statement naming ID5: not in the WebKit policy, the 2023 developer announcement, the Private Browsing 2.0 explanation or the bug tracker.

His summary of ID5's position is the most precise paragraph in the piece: "its own documentation describes behavior that closely matches what Apple prohibits, Apple has put it on a blocklist, Apple is keeping it there, and Apple has not said what conduct put it there." Only the third clause depends on ADOTAT's own reporting. The other three can be checked against public sources.

Apple's fingerprinting record is indeed long. Safari's Private Browsing 2.0, presented in July 2024, introduced Advanced Fingerprinting Protection, which adds noise to web APIs and varies the fingerprint presented in each private session. With Safari 26, Apple extended that protection to all browsing by default, restricting scripts it classifies as fingerprinting tools from high-entropy APIs including Canvas, WebGL and Web Audio, the surfaces used in canvas fingerprinting. In July 2026, a review of the Safari 27 beta found the browser cutting connections to LinkedIn and Bing tracking endpoints by IP address. The domain list that caught The Trade Desk and ID5 is the next step on a path that has been visible for years, even if the specific list is not.

Who else is on the list

The column names LiveRamp and Experian's Audigent as other companies reported as affected. Both appeared in the nine-domain reproduction Meyers posted to the bug: rlcdn.com and pippio.com for LiveRamp, ad.gt for Audigent. Experian acquired Audigent in December 2024. PPC Land's first report on the block, on September 30, also listed Permutive. "Who else is on it, nobody outside Apple can tell you," Lattin wrote.

That uncertainty is larger than the column lets on. AdExchanger reported on October 2, citing two sources, that the short list had been replaced by a remotely updated library covering hundreds of customer data platforms, ad tech and martech companies, data sellers and identity graph operators. Apple has not confirmed that. If it is accurate, the list can change without an iOS release, and the 13-day turnaround The Trade Desk received could in principle be repeated, or reversed, for any vendor without public notice.

Why the column matters for the market

For identity vendors, the argument shifts the question from "is this consented?" to "what does this do?" Early in the column, Lattin turns to vendors still reachable in Safari, who in his words "should stop gloating and start reading." The implication is that any vendor whose documentation describes cross-domain linking from IP address and user agent could be read the same way, whether or not Apple has acted yet.

For publishers, the column adds a reason to separate identity partners by function. Apple appears, on the single public precedent, to accept a technical case for a domain that delivers ads. It has given no sign of accepting one for a domain whose job is recognition. Publishers that route ID resolution and ad delivery through the same partner may find the two functions treated very differently.

For buyers, the open question is measurement. Campaigns bought on addressable reach that included Safari traffic since September 14 may have reached fewer identified users than reported. Lattin's line about buyers being "entitled to ask what fraction of it was ever addressable" applies to every vendor on the list, not only ID5.

What the column cannot settle is the one fact both sides would need: Apple's reason. Until Apple publishes its criteria, or ID5 or Apple comments on ADOTAT's claim that the block is permanent, the argument remains a well-documented inference.

Timeline

Summary

Who: Pesach Lattin, founder of ADOTAT, writing about ID5, the London-based identity provider, and The Trade Desk, whose engineer Ian Meyers filed WebKit bug 324771. Apple, through WebKit engineer John Wilander, is the only other party on the public record.

What: An opinion column arguing that ID5's own documentation, which tells partners to always pass IP address and user agent and describes cross-domain linking trained on hashed emails, matches what Apple's tracking prevention policy prohibits. The column reports, citing no named source, that ID5 will not be removed from Safari's private domain blocklist, and contrasts that with The Trade Desk receiving a test build with changes 13 days after Apple's first reply.

When: The column was published on October 8, 2026. The Trade Desk's exchange with Apple ran from September 21 to October 5, 2026, after iOS 27 began rolling out on September 14.

Where: Safari on iOS 27 devices, the WebKit public bug tracker, and ID5's partner documentation.

Why: Lattin argues the difference between the two outcomes is that The Trade Desk's blocked domain delivers ads, while ID5's domains exist only for cross-site recognition, so no narrow fix is available. Apple has not explained either decision, and consent records under European law do not answer the question Apple's browser policy asks.