Recognition without a cookie
A browser reveals dozens of small things when loading a page – fonts, screen dimensions, time zone, graphics quirks. Individually none of them says much. Combined they yield a value that recognises a device for weeks without anything being stored.
The decisive difference from a cookie lies in the direction. A cookie is placed and found again later – the device carries the identifier with it. A fingerprint is not placed but recalculated each time, from properties that are present anyway. The device carries nothing; it is the identifier.
Two unpleasant properties follow. The fingerprint survives the deletion of all browser data, because there is nothing to delete. And it is invisible: a browser's settings hold no list that would show it, the way cookies get listed.
What a fingerprint is assembled from
The informativeness of a single attribute can be measured. The usual yardstick is entropy: by how much does knowing this attribute shrink the set of candidate devices? The time zone alone splits the world's population into a good two dozen groups – not much help. The list of installed fonts, by contrast, is in many cases already close to unique.
How strongly individual attributes narrow things down
The legal classification is clearer than expected
A widespread misunderstanding holds that fingerprinting is a grey area because nothing is stored. The wording of section 25 TDDDG says otherwise: it covers the storage of information on the terminal equipment and access to information already stored there. Reading out the font list is such an access. Whether anything is left behind makes no difference.
The Article 29 Working Party recorded this in a dedicated opinion back in 2014, long before the technique became common. The classification has been unchanged since: fingerprinting for advertising or analytics needs consent, and the very same consent a cookie would need.
Two routes to the same recognition
For running a website a plain consequence follows. A script loading before consent must not combine attributes – and whether it does can hardly be judged from outside. Only one thing is therefore reliable: loading third-party scripts after the decision rather than trusting a pre-loaded script to hold back. That restraint is a supplier's assurance, not a verifiable property of the code.
