Fingerprinting, Identity Graphs and the Adtech Pipeline

Why the cookie was never the point

If you've read our plain-English guide to online tracking, you know the basics. This piece assumes you do, and goes further.

The industry's public conversation about cookies, the hand-wringing over Google's deprecation timeline, the consent banners, the "privacy-first" rebranding, has always been slightly beside the point. Cookies are a storage mechanism. What adtech actually needs is a stable, cross-site identifier that persists long enough to build a behavioural model. Cookies were convenient. They were never irreplaceable.

The evidence for this is structural. When Safari began blocking third-party cookies by default in 2017 and Firefox followed, the major demand-side platforms reported only modest revenue impacts. Why? Because the identifier layer had already diversified. Device IDs, hashed emails collected at login walls, probabilistic fingerprints and first-party data partnerships had been growing for years. The cookie's decline was, from the industry's perspective, a manageable transition rather than an existential threat.

Understanding tracking properly means understanding the full stack: the fingerprinting layer that creates identifiers without any storage, the network-level tricks that launder third-party requests into apparent first-party ones, and the identity resolution layer that joins everything together into a durable profile. That's what this piece covers.

Practical takeaway: Before adjusting any privacy settings, it's worth knowing which layer of the stack you're actually targeting. Blocking cookies alone addresses only one layer.

Fingerprinting: how much entropy your browser gives away

Browser fingerprinting works by collecting a set of attributes that, individually, are unremarkable, but in combination identify a device with high probability. The canonical academic treatment is the EFF's Panopticlick research (now relaunched as Cover Your Tracks), which found that the majority of browsers in their dataset were unique across the attributes they tested. More recent work, including a 2016 study by Laperdrix et al. examining nearly 120,000 browsers, found uniqueness rates above 80 per cent even without using any persistent storage.

The attributes that contribute most entropy, in rough order, are: the User-Agent string, installed fonts, screen resolution and colour depth, timezone offset, installed plugins, WebGL renderer strings, and the outputs of canvas and audio processing APIs. It's worth being precise about what canvas and audio fingerprinting actually do, because they're often described vaguely.

Canvas fingerprinting

A script instructs the browser to render text and shapes to an off-screen HTML5 canvas element, then reads back the pixel data as a base64-encoded string. The rendering differs subtly across operating systems, GPU drivers and anti-aliasing implementations. The resulting string is hashed and used as an identifier. A 2014 paper by Mowery and Shacklette at Princeton documented this technique in the wild; a 2016 study by Englehardt and Narayanan, also from Princeton, found canvas fingerprinting scripts on a substantial fraction of the top 100,000 websites at the time. The exact prevalence has shifted as some vendors have adjusted their implementations, but the technique remains active.

Audio fingerprinting

The AudioContext API, intended for web audio processing, produces slightly different floating-point outputs depending on the hardware and software stack. A script generates a simple oscillator signal and reads the processed output. The variation is tiny but consistent for a given device, and distinct enough to contribute meaningful entropy. The EFF's Cover Your Tracks tool tests for this alongside canvas, and the underlying methodology is documented in their published research.

Font enumeration

CSS and JavaScript can be used to probe which fonts are installed by measuring the rendered width of text strings in different typefaces. A long list of fonts produces a binary presence/absence vector that varies considerably across devices, particularly between operating systems and between corporate-managed and personal machines. The entropy contribution is high because font sets are sticky, they change slowly and reflect both the OS version and the user's own installations.

What entropy actually means here

Entropy in this context is measured in bits. Each attribute that halves the population of matching browsers adds one bit. Researchers have estimated that a full fingerprint can carry 18 to 20 bits of entropy, which is enough to identify one browser in a population of hundreds of thousands. Whether that translates to unique identification in a given deployment depends on the size of the operator's user base and how frequently they update their fingerprint model to account for browser updates. Fingerprints degrade over time as users update software, which is why fingerprinting is often used alongside other identifiers rather than as a sole source.

Firefox has implemented fingerprinting resistance measures that randomise some of these outputs. The Tor Browser goes further, standardising outputs across all users to make the fingerprint identical and therefore useless as an identifier. Chrome's Privacy Sandbox proposals include a "Privacy Budget" concept that would limit the total entropy a site can extract, though as of the time of writing this remains a proposal rather than a deployed feature, and its implementation details are contested.

Practical takeaway: Test your own browser at the EFF's Cover Your Tracks tool. The result tells you concretely how distinctive your current configuration is, and whether your browser's fingerprinting protections are actually working.

CNAME cloaking and server-side tagging: tracking dressed as first party

Even where third-party cookies are blocked, a tracker that appears to the browser as a first-party domain can set and read first-party cookies, which are not blocked by default in any major browser. CNAME cloaking exploits DNS to create exactly this appearance.

The mechanism is straightforward. A publisher creates a DNS CNAME record pointing a subdomain of their own domain, say metrics.publisher.co.uk, to a third-party tracker's infrastructure, say tracker-cdn.example.com. From the browser's perspective, the request goes to metrics.publisher.co.uk, which is a first-party domain. Cookies set by the response are first-party cookies. The browser has no practical way to distinguish this from a genuine first-party service.

Researchers at Inria, KU Leuven and Stony Brook published a study in 2021 that found CNAME cloaking in use across a meaningful fraction of the top 10,000 websites, with several major analytics and advertising vendors offering it as a feature. The paper identified specific implementation patterns and noted that some CNAME-cloaked trackers were setting cookies with longer lifetimes than they would have been permitted to set as explicit third parties. The Mozilla blog and subsequent Firefox release notes have documented their response, which involves checking CNAME chains before deciding whether to apply tracking protections.

Server-side tagging is a related but distinct technique. Traditionally, a tag management system runs JavaScript in the browser, making outbound requests to third-party endpoints that are visible to the browser and therefore blockable. In a server-side configuration, the publisher runs a tag management server on their own infrastructure (or a cloud instance under their own domain). The browser sends data to that server, and the server fans it out to third-party vendors. The browser sees only a first-party request. The third-party calls happen server-to-server, invisible to browser-level blockers.

Server-side tagging doesn't bypass consent requirements under UK GDPR. The legal basis for processing still needs to exist. But it does bypass technical controls that users deploy in good faith. The ICO's guidance on cookies and similar technologies, updated in 2023, makes clear that the legal obligations attach to the processing, not to the technical mechanism used to collect data. An organisation using server-side tagging to circumvent user consent signals would be in breach regardless of the technical architecture.

Practical takeaway: DNS-based privacy tools, specifically resolvers that maintain lists of known tracker CNAME targets, can catch some CNAME cloaking that browser-level blockers miss. This is one area where network-level controls add genuine value beyond browser settings.

Bounce tracking and link decoration

Bounce tracking is an identifier technique that exploits the browser's storage partitioning model. When a user clicks a link that passes through an intermediary domain before reaching the destination, the intermediary can set a first-party cookie or use other first-party storage during that brief visit. If the same intermediary is used across many sites, it accumulates a cross-site identifier in first-party storage that isn't subject to third-party cookie restrictions.

The pattern typically looks like this: a link on site A points not to site B directly, but to tracker.example.com/?redirect=siteB. The user's browser visits tracker.example.com, which sets or reads a first-party identifier, then redirects to site B. The visit is fast enough that the user rarely notices. Google's own URL shortener and click-measurement infrastructure has used variants of this pattern, as have several affiliate networks.

Link decoration is simpler. Query parameters or URL fragments are appended to outbound links, encoding an identifier. When the destination page loads, its JavaScript reads the parameter and associates the visit with the identifier. Meta's fbclid parameter and Google's gclid are documented examples. Firefox strips known tracking parameters from URLs in its Enhanced Tracking Protection configuration; Safari's Intelligent Tracking Prevention does the same for a list of known parameters.

The Privacy Sandbox's Bounce Tracking Mitigations proposal, documented in Chrome's public repository, describes a browser-level response that would delete storage for sites that match a bounce tracking pattern. As of writing, this is in development and not yet deployed at scale. The technical details, including how the heuristic identifies bounce trackers without false positives on legitimate redirects, are openly documented and worth reading if you want to understand the design constraints.

Practical takeaway: Browsers with aggressive tracking protection (Firefox in Strict mode, or browsers based on Firefox with custom configurations) strip many known tracking parameters before the destination page loads. This is one of the more concrete benefits of browser choice in this specific area.

Identity graphs: joining hashed emails, devices and purchases

All of the techniques above produce identifiers. The identity graph is what joins them. It's the layer that takes a probabilistic fingerprint from one session, a hashed email address collected at a login wall in another, a device advertising ID from a mobile app, and an offline purchase record from a loyalty scheme, and resolves them to a single profile.

The core mechanism for joining online and offline data is the hashed email address. When a user logs into a retailer's website, the retailer may hash their email address (typically with SHA-256) and pass it to an advertising platform as a match key. The advertising platform holds its own database of hashed emails collected from its own login events. Where the hashes match, the two datasets are joined. Neither party technically shares the plaintext email, but the join is functionally equivalent to sharing it for the purpose of profile building.

This is the mechanism behind Meta's Custom Audiences product, Google's Customer Match, and similar offerings from other platforms. The technical documentation for these products is publicly available and describes the hashing requirement explicitly. What the documentation doesn't always make clear is that SHA-256 of a known-format string like an email address is not a cryptographically strong anonymisation. Email addresses occupy a relatively small and enumerable space; a determined party with the hash can often reverse it by hashing a dictionary of likely addresses. The ICO has noted in its guidance on anonymisation that hashing alone does not constitute anonymisation where re-identification is feasible.

Beyond hashed emails, identity graphs incorporate device graphs, which link mobile advertising IDs (Apple's IDFA and Google's GAID, both subject to user opt-out but historically opted-in by default), IP addresses used probabilistically to link household devices, and deterministic links from cross-device login events. The resulting graph is maintained by data brokers and identity resolution vendors, some of whom operate largely outside the awareness of the individuals profiled.

The data broker economy that feeds and is fed by these graphs is covered in more detail in our piece on how personal data is collected and sold. For the purposes of this piece, the key point is that the identity graph is the reason that clearing cookies, or even switching browsers, often doesn't produce the clean break users expect. The persistent identifiers live elsewhere.

Practical takeaway: The most effective single intervention against identity graph matching is not logging into services with your primary email address where you can avoid it. Alias email addresses, used consistently per service, break the common match key.

The auction: what happens in the 100 milliseconds before an ad loads

Real-time bidding (RTB) is the auction mechanism that determines which ad you see. Understanding it matters because it's also a data distribution mechanism, and arguably the most significant one in the adtech stack.

When you load a page that carries programmatic advertising, the publisher's ad server sends a bid request to an ad exchange. That bid request contains a bundle of data about the impression: the URL, the ad slot dimensions, and, critically, identifiers and audience segment data associated with you. This bid request is broadcast to potentially hundreds of demand-side platforms simultaneously. Each DSP has a brief window, typically 100 milliseconds or so, to decide whether to bid and at what price.

The data in a bid request is defined by the OpenRTB specification, maintained by the IAB Tech Lab and publicly documented. A bid request can contain IP address, User-Agent string, a publisher-assigned user ID, third-party data segment IDs, location data at varying precision, and other attributes. Every DSP that receives the bid request receives all of this data, whether or not they win the auction and whether or not they ultimately serve an ad. This broadcast characteristic is the basis of the ICO's longstanding concern about RTB.

The ICO's 2019 report on RTB, and subsequent updates, concluded that the RTB system as commonly implemented is likely incompatible with UK GDPR in several respects: the legal basis for processing is often unclear, the breadth of data sharing exceeds what's necessary, and individuals have no practical ability to exercise their rights against the hundreds of parties who may have received their data in a bid request. The ICO has engaged with the IAB UK on this, and the IAB's Transparency and Consent Framework (TCF) has been the industry's primary response. The legality of the TCF itself has been contested in Belgian courts, with the Belgian Data Protection Authority finding it in breach of GDPR in 2022, a finding that has implications across the EU and, by extension, informs ICO thinking.

Practical takeaway: The RTB data leak happens before the page finishes loading, and it's not something browser settings alone can prevent. Network-level blocking of known ad exchange endpoints is the most direct technical countermeasure, though it will break some legitimate publisher revenue and occasionally affect page functionality.

What regulation actually bites, and what it misses

UK GDPR and the Privacy and Electronic Communications Regulations (PECR) are the primary legal frameworks. They're worth distinguishing: PECR governs the placing of cookies and similar technologies on a user's device and requires consent for non-essential tracking. UK GDPR governs what's done with the data once collected, including the legal basis, purpose limitation, data minimisation and rights obligations.

Where regulation has genuine teeth:

• Consent for cookies and device access: PECR is clear that non-essential cookies require prior, informed, freely given consent. The ICO's enforcement action against organisations using dark patterns in consent interfaces, including pre-ticked boxes and buried opt-outs, has been meaningful, if not comprehensive in coverage.
• Hashed email matching and Custom Audiences: The ICO's guidance on data sharing and the use of legitimate interests as a legal basis is relevant here. Several DPAs across the EU have found that hashed email matching for advertising purposes cannot rely on legitimate interests and requires consent.
• RTB data broadcasting: The ICO's position is documented and critical, though enforcement action specifically targeting RTB participants has been slower than the policy statements suggest it should be.

Where regulation is weaker or enforcement is thin:

• Fingerprinting: The ICO's guidance on cookies explicitly states that device fingerprinting used for tracking is subject to PECR consent requirements, since it accesses information stored on or generated by a device. However, enforcement specifically targeting fingerprinting is not well documented in the public record. The technique is technically harder to audit than cookie-setting.
• Server-side tagging and CNAME cloaking: These are not separately addressed in published ICO guidance as of writing. The underlying legal obligations still apply, but the technical opacity makes enforcement harder.
• Identity graphs held by data brokers: Where brokers are processing data about UK residents, UK GDPR applies. In practice, many brokers operate from jurisdictions where enforcement is difficult, and the ICO's resources for pursuing cross-border cases are constrained.
• The Privacy Sandbox: Google's replacement infrastructure for third-party cookies introduces new APIs (Topics, Protected Audience) that perform some of the same functions as third-party cookies with different technical characteristics. The ICO engaged with Google's Privacy Sandbox proposals and published findings noting concerns about whether the new APIs adequately protect user privacy. This engagement is ongoing.

The honest summary is that regulation has moved the industry on consent UI and has created genuine liability for the most egregious practices. It hasn't yet caught up with the technical sophistication of the tracking stack described in this piece.

Practical takeaway: The ICO's complaints process is available to UK residents who believe their data has been processed unlawfully. It's slow, but it creates a record. The ICO's published guidance on cookies, RTB and legitimate interests is worth reading directly if you're making compliance decisions, rather than relying on vendor summaries of it.

Countermeasures that hold up under this model

Given everything above, what actually works? The honest answer is that no single measure is sufficient, and the threat model matters: are you trying to reduce commercial profiling, or something more specific? This section addresses the commercial tracking case.

Browser choice and configuration

Firefox in Strict Enhanced Tracking Protection mode, or a hardened Firefox-based browser with appropriate extensions, currently offers the strongest combination of fingerprinting resistance, tracking parameter stripping, and CNAME chain checking of any mainstream browser. The Mozilla documentation on what Strict mode blocks is specific and worth reading. Safari's Intelligent Tracking Prevention is meaningful but operates differently, focusing on partitioning rather than blocking. Chromium-based browsers, including Chrome itself, offer less protection by default and are structurally less likely to implement aggressive tracking protection given Google's advertising business model.

DNS-level filtering

A DNS resolver that maintains lists of known tracker domains, including CNAME targets, blocks requests before they reach the network. This catches server-side and CNAME-based tracking that browser extensions cannot see. It also applies to all devices on a network simultaneously. The tradeoff is that DNS filtering can produce false positives and doesn't help with tracking that uses the same domain for both tracking and legitimate functionality.

Email aliasing

Using a unique alias email address for each service you register with breaks the primary match key used by identity graph resolution. If each service has a distinct address, hashed email matching can't join your profiles across services. This is one of the more structurally effective interventions because it targets the deterministic join rather than the probabilistic fingerprint.

Consent signals and opt-outs

Global Privacy Control (GPC) is a browser-level signal that communicates a user's opt-out preference to websites. The ICO has indicated that GPC should be treated as a valid opt-out signal under PECR where it's implemented correctly, though the legal weight of this position is still developing. Some jurisdictions (California under CPRA) have given GPC explicit legal standing. In the UK, the position is less settled but the signal is worth enabling.

Industry opt-out registries, such as those maintained by the IAB and the Digital Advertising Alliance, rely on cookies to record your opt-out, which means they're fragile across browser sessions and don't address fingerprinting-based tracking. They're not meaningless, but they're not a strong countermeasure against the techniques described here.

What doesn't hold up as well as claimed

Private browsing mode prevents local storage of browsing history but doesn't affect fingerprinting, server-side tracking or identity graph matching based on IP address or login events. VPNs change your IP address, which reduces the effectiveness of IP-based probabilistic linking, but don't affect fingerprinting or any identifier that travels in the request payload. Both are useful for specific threat models, but neither addresses the tracking stack described in this piece in any comprehensive way.

Practical takeaway: The highest-leverage combination for most readers is: Firefox in Strict mode with a DNS-level filter on your home network, plus email aliasing for any service that asks for your address. That combination targets three different layers of the stack simultaneously, without requiring significant ongoing maintenance.