The EFF Panopticlick experiment and what it proved about browser uniqueness

In early 2010 the Electronic Frontier Foundation put up a website that did almost nothing. You visited a page, clicked a button labelled “Test Me”, and a few seconds later it told you how rare your browser was. No login, no download, no cookie required to make the point. The site read a handful of things your browser already volunteered to every server it talked to, combined them, and reported back a single number: how many bits of identifying information your browser was leaking, and roughly how many other browsers on the internet looked exactly like yours. For most people the answer was that nobody else did.

That site was Panopticlick, and the question it posed was uncomfortable. Everyone knew cookies could track you, and a privacy-conscious user could block or delete them. But what if the browser itself, before any cookie was set, was already a near-unique identifier? What if the user agent string, the list of fonts, the screen size and the time zone, taken together, were enough to pick your machine out of a crowd of half a million? Panopticlick was built to measure exactly that, and the paper that came out of it gave the field of browser fingerprinting its first hard number. This post is about that experiment: where the 18.1-bit headline came from, how the measurement actually worked, what the data said about whether fingerprints could be evaded, and what happened to the project in the fifteen years since.

The sections below walk through the setup and the half-million-browser dataset, the eight things Panopticlick measured, the entropy math that turned a fingerprint into a bit count, the surprising finding that fingerprints change often but can still be tracked through the changes, the defenses Eckersley tested and the paradox that broke most of them, and finally the 2020 rebrand to Cover Your Tracks and how the picture looks now that Flash and plugins are gone.

The experiment and its dataset

Panopticlick was the work of Peter Eckersley, a technologist at the EFF, and the results were written up in a paper titled “How Unique Is Your Web Browser?” presented at the Privacy Enhancing Technologies Symposium (PETS) in 2010. The paper is careful about what it claims. It does not claim to have invented fingerprinting. The opening notes that several companies already sold products to fingerprint browsers for analytics and second-layer authentication, and that the technique was understood in the abstract. What was missing was a public number. Aside from limited results from one earlier experiment, there was, in Eckersley’s words, no information in the public domain to quantify how much of a privacy problem fingerprinting actually posed. Panopticlick existed to produce that quantity.

The data came from people who heard about the site and chose to visit it. Word spread through Slashdot, BoingBoing, Lifehacker, Ars Technica and the usual social channels of the time. The collection window for the paper ran from 27 January to 15 February 2010. Over that period the test site logged 1,043,426 hits. After discarding reloads, early buggy records, and the multi-counting that happens when the same machine is seen repeatedly, the analysis settled on a cleaned population of 470,161 distinct fingerprint instances. That is the number behind every percentage in the study.

Eckersley was explicit that this sample was biased, and the bias matters for reading the result. People who click a link promising to test their browser’s anonymity are, on average, more technical and more privacy-aware than the general population. They are more likely to run NoScript, more likely to have spoofed a user agent, more likely to be on Linux. A privacy-conscious crowd is, paradoxically, a more diverse and therefore more fingerprintable crowd than a population dominated by stock Windows machines running the default browser. So the headline numbers are best read as describing the kind of user who shows up to a fingerprinting test, not the median web user. Later studies on ordinary traffic would land on very different figures, and we get to those at the end.

The path from 1,043,426 raw hits down to 470,161 clean instances is worth following, because the de-duplication is where a naive count would have gone wrong. The core problem is that a browser which deletes or blocks cookies looks like a fresh visitor every time it returns, while a browser that keeps cookies is correctly counted once. Count both naively and you over-weight the cookie-refusers, who are exactly the privacy-conscious users with the rarest fingerprints, and you inflate the uniqueness number. The study handled this by recording, alongside each fingerprint, a three-month persistent cookie ID for browsers that accepted one, plus an HMAC of the visitor’s IP address and a second HMAC of that IP with its least-significant octet zeroed. The HMAC keys were generated and then thrown away, so the logs held a salted, irreversible token rather than a usable IP, a deliberate minimisation choice in a study about tracking.

With those tokens the live tally only incremented when a precise fingerprint arrived with a cookie ID not seen before, which suppressed the obvious double-counting from page reloads. Browsers without cookies were then collapsed by assuming that identical fingerprint plus identical IP meant the same machine. One exception was carved out for what the paper called interleaved cookies: if the same fingerprint appeared at one IP first with cookie A, then cookie B, then cookie A again, that pattern suggested several identical machines behind one firewall, and they were counted separately. Interleaving showed up at 2,585 IP addresses, about 3.5% of the addresses that had multiple signatures. A final correction handled hosts that roamed between IPs; 14,849 cookie-bearing users were seen changing IP, their later addresses making up 4.6% of the IPs that accepted cookies, small enough to leave as an error term rather than reweight the whole dataset.

The eight measurements

The fingerprint was built from eight browser-supplied characteristics. Some of them ride along on every HTTP request and need no JavaScript at all. The rest were collected by a small script that ran in the page and posted the values back. Here is the full set, with how each was obtained.

The eight variables Panopticlick collected, split by whether they ride the HTTP request or need JavaScript, with the mean surprisal each contributed on its own from Table 2 of the paper.

The single most informative variable was the plugin list, at 15.4 bits of mean surprisal on its own. That makes sense in 2010 terms. The browser exposed navigator.plugins, an enumerable array of every installed plugin with its exact micro-version: DivX Web Player 1.4.0.233, Shockwave Flash 10.0 r42, QuickTime 7.2.0, each one a precise string. The combination of which plugins you had and which patch level each sat at was wildly varied across machines. Microsoft’s Internet Explorer earned a note in the paper for being the honourable exception here: it offered no way to enumerate plugins, so Panopticlick fell back to probing for eight common ones with the PluginDetect library, and IE’s plugin entropy came in lower, at 16.5 bits, against 17.7 in non-IE browsers.

Fonts were close behind at 13.9 bits, and this is where Flash and Java came in. A page cannot read your installed font list directly from JavaScript, but a Flash applet or a Java applet could, and would happily hand back the complete list. The presence of an unusual font, or simply an unusual set of fonts, was strongly identifying. The user agent contributed 10.0 bits on its own, carrying browser micro-version, OS version and language. HTTP Accept headers added 6.09. Screen resolution with colour depth, the video variable in the paper’s tables, gave 4.83. Time zone, 3.04. The supercookie test, 2.12. And whether cookies were enabled at all, a near-useless 0.353 bits, because almost everyone had them on.

A point that is easy to miss: these per-variable numbers do not simply add up to the total. Surprisal only adds linearly when the variables are statistically independent, and browser characteristics are heavily correlated. A machine reporting a Windows user agent has a Windows-shaped font list and a Windows-shaped plugin set. The paper is careful about this, using conditional self-information where the dependence matters. The combined fingerprint was worth 18.1 bits, not the 55-or-so you would get by naively summing the columns.

Turning a fingerprint into bits

The number that made Panopticlick quotable is 18.1 bits, and the reasoning behind it is Shannon’s, applied cleanly to a tracking problem. The idea is to treat a fingerprinting algorithm as a function whose output, across the population of browsers, follows some probability distribution. A particular output’s self-information, or surprisal, is the negative base-two logarithm of how common that output is. Rare fingerprints carry many bits. Common ones carry few.

Self-information in bits, and the chain that gives the paper’s headline: 18.1 bits means at best one browser in 286,777 shares your fingerprint.

The entropy of the whole distribution is the expected surprisal across all browsers, the standard Shannon sum of probability times log-probability. Measuring it from a sample of 470,161 has a built-in limit: you cannot directly observe probabilities smaller than roughly one in your sample size, because a fingerprint seen once might be one in a million or one in a billion and you cannot tell which from a single sighting. So 18.1 bits is reported as a lower bound. The true entropy of the global distribution is almost certainly higher.

That 18.1 bits converts to “at best, one in 286,777 other browsers will share its fingerprint” by the simple step of two raised to the 18.1 power. The phrasing “at best” is doing real work. It is the most optimistic reading for the user, the floor on how identifiable the average browser was.

The raw uniqueness counts are starker than the entropy figure. In the full sample, 83.6% of browsers had an instantaneously unique fingerprint, one not shared with any other browser seen. Another 5.3% sat in an anonymity set of size two. The distribution was extremely skewed, an L-shape with a long tail of unique prints. Restrict to the browsers that had Flash or Java enabled, the ones whose font lists could be read, and it gets worse: 94.2% were unique, a further 4.8% were seen exactly twice, and only 1.0% sat in an anonymity set larger than two. For those machines the average fingerprint carried at least 18.8 bits. If you ran Flash in 2010, you were almost certainly one of a kind.

The browsers that fared best were the ones with the least to say. Phones of the era, iPhone and Android browsers, were far more uniform than desktops, because they had a narrow range of plugins and limited configuration surface. Desktop browsers with JavaScript disabled, often via NoScript, also clustered into large anonymity sets, since turning off scripting silenced five of the eight measurements at once. The single largest anonymity set in the data, 1,186 browsers, was a stock Windows Firefox 3.5.7 with cookies on and JavaScript off.

Sample uniqueness is not global uniqueness

There is a statistical trap in reading 83.6% unique as 83.6% of all browsers on Earth are unique, and the paper confronts it head-on because a reviewer had raised exactly this objection. Jonathan Mayer, then at Princeton, had argued that you essentially cannot draw conclusions about global uniqueness from a finite sample. The argument runs through the multinomial theorem. The maximum-likelihood estimate for the probability of a fingerprint that appeared exactly once in a sample of size N is one in N. But the global population of browsers is vastly larger than N, so a fingerprint that is one in 470,161 in the sample could easily be shared by many machines that simply never visited the test site. Maximum likelihood, applied this way, assigns probability zero to every fingerprint not yet seen, which is obviously wrong the moment you collect a larger sample and watch new fingerprints keep appearing.

Eckersley accepted the critique of point estimates and reframed the claim. What the experiment could honestly assert was a measured property of the observed distribution: a lower bound of 18.1 bits of entropy, and a description of the sample’s shape, the L-curve with its long tail. What it could not assert was a precise global uniqueness percentage. The paper sketches the honest way to get one, fitting a long-tailed probability density to the observed frequencies and running Monte Carlo simulations to extrapolate uniqueness to a population of any chosen size, with confidence intervals on whether a fingerprint unique in N stays unique in a larger G. He chose not to run that analysis, for a candid reason: the sample was so biased toward technical and privacy-conscious users that extrapolating it to the whole internet would be close to meaningless. Better to report the bound and flag the bias than to manufacture a global figure the data could not support. That restraint is part of why the paper held up. It claimed exactly what it measured.

Fingerprints move, and that should have helped

The most interesting result in the paper is not the uniqueness number. It is what happened over time, because it contained both the best news for privacy and the catch that took the news back.

Fingerprints turned out to be unstable. Among 8,833 users who accepted cookies and visited the site more than once over a span longer than 24 hours, 37.4% showed at least one fingerprint change. A browser auto-updated, a plugin upgraded, a font got installed, a laptop got plugged into an external monitor and the screen resolution changed. Any of these flipped one of the eight values and produced a new fingerprint. On its face this is a strong argument against fingerprinting as a tracking tool. If more than a third of users look different within a day or two, a fingerprint is a poor substitute for a cookie, which persists until deleted.

Eckersley then tested whether that instability actually protected anyone, and the answer was mostly no. He wrote a deliberately crude heuristic to guess, when a new fingerprint appeared, which previously seen fingerprint it had evolved from. The logic was simple. Take the new print, scan the dataset for old prints that match it on seven of the eight components, and if exactly one candidate remains, check whether the one differing component changed in a plausible way. For the high-churn string fields, user agent, Accept headers, plugins and fonts, it required the old and new values to be at least 85% similar by Python’s difflib.SequenceMatcher ratio. For the low-churn fields like time zone or cookies it accepted the change outright.

The heuristic linked an upgraded fingerprint back to its predecessor by requiring seven of eight components to match and the eighth to have changed plausibly. When it did commit to a guess, it was right 99.1% of the time.

When this heuristic was run over returning users whose fingerprints had changed, excluding those who changed because they had disabled JavaScript, it made a correct guess in 65% of cases, a wrong guess in 0.56%, and declined to guess in the remaining 35%. Counting only the cases where it committed, 99.1% of its guesses were correct, with a false-positive rate of 0.86%. A crude algorithm, written quickly, could re-link an evolved fingerprint to its earlier self almost every time it tried. So fingerprint churn was not the escape hatch it first appeared to be. The fingerprint changed, but the change was followable, and a tracker that bothered would rarely lose you.

The defenses and the paradox that broke them

The paper does not stop at measurement. It works through what a user could do to fight fingerprinting, and the central finding is awkward for the whole privacy-tool category. Eckersley named it the paradox of fingerprintable privacy-enhancing technologies. Many measures meant to make you harder to track make you more distinctive, because distinctiveness is exactly what fingerprinting feeds on. Anything that makes you stand out from the crowd helps the tracker, even when the thing making you stand out is a privacy tool.

The examples were direct. Spoofing your user agent does not blend you in. It makes you part of a tiny, weird minority. The paper noted, in passing, 378 browsers sending iPhone user agents while running Flash, which the iPhone of the day did not support, and 72 browsers claiming to be Firefox while supporting Internet Explorer’s userData supercookie. Those mismatches were not camouflage, they were a flag. A small group of users had “Privoxy” in their user agent strings, and that token alone averaged 15.5 bits of surprisal. All seven users of the privacy-branded “Browzar” browser were unique in the dataset. Flash blockers were counterproductive in a subtle way: a machine with Flash installed but a Flash-blocking add-on showed Flash in the plugin list yet failed to return a font list through it, a combination distinctive enough that the mean surprisal of Flash-blocker users was 18.7 bits.

The tools that came out well were the ones that removed information rather than adding contrarian signal. Disabling JavaScript, as NoScript did, knocked out five of the eight measurements and pushed users into large anonymity sets. The Tor project’s TorButton was singled out for already designing against fingerprintability, treating uniformity as a goal so that all Tor Browser users look alike. The pattern is that subtraction toward a common configuration helps, and personalisation toward a rare one hurts, which is the opposite of what most privacy tooling of the era was doing.

Two structural observations from the paper outlived the specific 2010 tooling. The first is the distinction between enumerable and testable characteristics. Some APIs let a page enumerate a list, dumping the whole plugin array or the whole font set in one call. Others only let a page test for a specific value, asking is this one font present rather than list every font. Enumeration leaks far more entropy, because the shape of an entire list is enormously varied, while a yes-or-no probe leaks one bit at a time and can be rate-limited. The paper recommended browsers move to confirm-only testing for fonts and plugins, with an exponential backoff to stop a malicious script from brute-forcing the full set anyway.

The second is the trade between fingerprintability and debuggability. Most of the entropy in a browser came from precise micro-version numbers. Reporting Java 1.6.0_17 rather than Java 1.6, or a four-part plugin version rather than a major version, exists so developers can excavate the exact build when chasing a bug. Useful for the developer, expensive for the user, because every extra digit of precision is extra identifying information. The paper’s verdict is that browsers had parked themselves close to the extreme-debuggability end of the spectrum, and that the choice deserved revisiting, especially in private-browsing modes. That argument shows up later in the entropy budget that fingerprint defenders now reason about explicitly: every reported value is a withdrawal from a fixed allowance, and version precision is one of the more wasteful withdrawals.

There is a small, almost wry result tucked in the defenses section about font ordering. Flash and Java returned font lists in filesystem order rather than alphabetical, and Eckersley wondered whether that ordering was itself a fingerprint. Testing it, he found the order was stable for almost everyone, except a cluster of around 200 Mac OS X machines where some application rewrote the font files and shuffled the Lucida family. Sorting the font list before recording it dropped the font entropy from 17.1 bits to 16.0, a saving of about 1.1 bits for free. The lesson is general. Ordering, casing, and the incidental arrangement of a list carry information that the list’s contents alone do not, a theme that runs straight through to modern header order and casing fingerprints and TLS extension ordering.

From Panopticlick to Cover Your Tracks

Panopticlick the website kept running and kept changing after the paper. In 2015 the EFF added a second job to it, testing whether your tracker-blocking add-ons actually worked, by simulating tracking domains and seeing what got through. The tool now had two missions wearing one name, and the name no longer fit. In November 2020 the EFF rebranded it. The site became Cover Your Tracks, and the shift in name tracked a shift in purpose: Panopticlick had been built to prove that fingerprinting was possible, while Cover Your Tracks was built to help people do something about it, with explainers attached to each measured characteristic and a clearer read on whether your defenses held.

The set of signals it reads grew with the web. The original eight were a 2010 snapshot. Cover Your Tracks added canvas and WebGL fingerprints, the Do Not Track header, platform and language, touch support, and more. Canvas in particular became the workhorse the plugin list used to be, and the story of how rendering text to a hidden surface turns into a stable per-device value is its own deep dive on canvas fingerprinting. The throughline from Panopticlick to today is covered in the longer history of browser fingerprinting, of which this experiment is the opening chapter.

The research did not stop with the EFF either. In 2016 a team at Inria published “Beauty and the Beast,” running the AmIUnique site, and found 89.4% of their fingerprints unique while showing how HTML5 features, the canvas API above all, opened new and highly discriminating attributes that Panopticlick predated. Then in 2018 came the result that complicated the headline. Gomez-Boix, Laperdrix and Baudry deployed a fingerprinting script on a major French commercial website rather than a privacy-test site, collected more than two million fingerprints from ordinary visitors, and found only 33.6% unique using the same seventeen attributes as AmIUnique. The gap between 94.2% and 33.6% is almost entirely the sampling bias Eckersley had warned about in 2010. Privacy-conscious volunteers are rare and weird. The general public, browsing on a phone or a stock laptop, hides far better in the crowd. The fingerprinting threat is real, but its severity depends heavily on who is in the population, and the people who show up to test their browser are the worst case, not the average.

What the experiment settled, and what it did not

Panopticlick’s lasting contribution is that it moved fingerprinting from a thing people suspected to a thing with a number attached. Before 2010 you could argue about whether the user agent and the font list were enough to track someone. After, you could point at 18.1 bits and 83.6% unique and 94.2% with Flash, and the argument was about magnitude, not existence. The method, treat a fingerprint as a sample from a distribution and measure its Shannon entropy in bits, became the standard way the field talks about identifiability, and every later study, including the ones that cut the uniqueness figure to a third, used the same yardstick.

The specific 2010 fingerprint has aged out almost completely, and that is worth saying plainly. Flash reached end of life at the end of 2020 and Chrome removed it in version 88 in January 2021, which killed the font-reading trick that drove the worst-case 94.2% number. The navigator.plugins array, once worth 15.4 bits, now returns a hardcoded list of a few PDF-viewer entries in Chrome and leaks almost nothing. Two of the most informative variables in the original study are gone. The entropy did not vanish though, it migrated. Canvas, WebGL, audio, and the precise behaviour of dozens of JavaScript APIs took up the slack, and the browsers spent the next decade in an arms race to claw bits back through partitioning, randomisation, and uniformity targets that TorButton pioneered. Panopticlick measured a configuration surface that no longer exists, using a method that turned out to be permanent. That is the right way for an experiment to age: the data becomes a historical artifact, and the way of thinking it introduced stays.

Sources & further reading

Eckersley, P. (2010), How Unique Is Your Web Browser? — the PETS 2010 paper with the 18.1-bit result, the eight measurements, the entropy math, and the fingerprint-following heuristic.
Electronic Frontier Foundation (2020), Introducing Cover Your Tracks! — the announcement of the Panopticlick rebrand and the shift from demonstrating fingerprinting to defending against it.
Electronic Frontier Foundation, About Cover Your Tracks — current description of what the tool tests, including canvas and WebGL signals and tracker-blocker effectiveness.
Laperdrix, P., Rudametkin, W. and Baudry, B. (2016), Beauty and the Beast: Diverting Modern Web Browsers to Build Unique Browser Fingerprints — the AmIUnique study, 89.4% unique, and the rise of HTML5 canvas as a fingerprinting source.
Gomez-Boix, A., Laperdrix, P. and Baudry, B. (2018), Hiding in the Crowd: an Analysis of the Effectiveness of Browser Fingerprinting at Large Scale — the WWW 2018 paper finding only 33.6% unique on ordinary commercial traffic.
Laperdrix, P. et al. (2019), Browser Fingerprinting: A Survey — a survey placing Panopticlick in the wider arc of fingerprinting research.
Google (2020), Saying goodbye to Flash in Chrome — Flash’s end of life, which removed the font-enumeration vector central to the 2010 study.
Chrome Platform Status, Return fixed lists for navigator.plugins and navigator.mimeTypes — the change that neutered the plugin list, once the highest-entropy variable.
web.dev, Fingerprinting — a current explainer on active and passive fingerprinting surfaces in modern browsers.
EFF, Cover Your Tracks — the live successor to Panopticlick, where you can still run the test on your own browser.