The biggest and most dangerous misconception I hear from peers, venture investors, and other professionals is that browser fingerprinting is easy to do and a solved problem. Many believe that identifying users by collecting unique combinations of their device settings, browser type, plugins, fonts, and hardware specs is straightforward. This is false. Browser fingerprinting is not a “solved” problem.
Browser fingerprinting appeared to be a solved problem in between 2012 and 2019, when you just needed to perform simple attribute collection. For seven years, browser makers didn’t think about how they were leaking user data and other identifiable information. Then, three things changed: plugins died, API design got serious about privacy, and the browser market consolidated.
Browser makers didn’t use to care that their users were identifiable. Microsoft wanted Internet Explorer to win the browser wars, so it raced to add Ajax, Flash, and other capabilities. Every browser had its own quirks and features. There were no standards. Privacy wasn’t even a thought in browser engineers’ minds. Performance and feature parity took precedence.
In 2012, it was easy to reliably identify every single browser on the planet, and every company did it, including Google and Microsoft. You didn’t even need real fingerprinting tech.
The biggest anti-privacy culprits by far were plugins that provided native system access and leaked granular hardware identifiers. Flash and Java were the worst. If you wanted to play a game, you had to install Macromedia Flash, which was a privacy nightmare. Similarly, every browser used to run Java applets, and Java leaked so much information that it made the browser a very convenient tool to uniquely identify every single individual.
Today, you don’t need Flash or Java applets for anything. You can’t install them even if you wanted to. The death of Flash and Java applets was a big win for privacy and a big hit to browser fingerprinting.
Their demise contributed to a bigger trend. In 2013, identifying IE11 uniquely was very easy; it took just three lines of code. Five years later, you needed 500 lines of code to write a robust fingerprinting script. A decade after that, the level of complexity exploded so much that you needed a large engineering team. Since then, browser fingerprinting has never been the same.
Privacy progress led to API design changes
After 2019, it became financially interesting for large corporations to market privacy as a capability. Around the same time, internet users became more interested in protecting their privacy. Fast forward to today, and people use privacy tools more than ever.
Instead of ensuring APIs were simply the fastest and most developer-friendly, companies started to also design their APIs to be privacy-friendly, such as the Apple Pay API, where Apple doesn’t even see what you buy.
Today, before making it to production, every API goes through a rigorous process to reduce the uniqueness of a browser’s signature. APIs are designed, reviewed, and analyzed for their privacy impact. API design philosophy has changed so much in the past 10 years that Google, for example, now allocates entire teams to make sure none of its browser APIs leak any information. Privacy audit security review teams work around the clock to make browsers as private as possible, which is not easy since each browser has tens of thousands of browser APIs.
This simply wasn’t the case 10 to 15 years ago: companies didn’t care about browser privacy at all and there were no such teams. Since then, the sophistication of browsers has increased to such an extent that fingerprinting is a very difficult problem to solve and very few companies do it well.
As the browser market consolidated over the past decade into a few dominant players—Chrome, Safari, and Firefox—browser makers gained far more control over what data their browsers expose.
Together with plugin removal and API design changes, browser fingerprinting went from what seemed like a solved problem to a very difficult-to-solve problem. Identifying a returning visitor reliably while preserving user privacy is an engineering challenge that requires constant reassessment of the trust boundary between the client and the server.
If anyone says that it’s easy to identify a returning visitor, don’t believe them. It’s a growing misconception and completely false. Identifying return visitors reliably is not just very hard, it’s harder than ever before.
