Device Fingerprinting: Tracking Without Cookies or Consent

A report out of Carnegie Mellon’s School of Public Policy found that “87% (216 million of 248 million) of the population in the United States had reported characteristics that likely made them unique based only on [their] 5-digit ZIP, gender, [and] date of birth.” It’s mind boggling how little data is required before one becomes uniquely identifiable. In a world where cookies are highly scrutinized, it is no wonder why digital marketing technologies are turning to device fingerprinting to supplement their user profiling.

Device fingerprinting, also known as browser fingerprinting, is a method of tracking a device, not by placing any code on that device, but by learning to recognize it based on its unique features and configurations. Assuming that most devices are used by a single user, device fingerprinting allows vendors to uniquely identify and track not just a device, but a user. Fingerprinting technologies are both established and widespread; it is likely – if not probable – that your vendors are using fingerprinting today to identify your users.

When a browser loads a page, it will request information about the device loading the page in order to provide the correct content and correct formatting. A Vault JS study of major websites found that some of the most common attributes requested included the device’s screen width, screen height, and navigator language, but more highly identifying attributes might include the browser’s plugins and extensions, the installed system fonts, hardware specifications (CPU/GPU, memory) or even canvas elements.

Individually, these attributes are generic and anonymous, but combined they build up a profile of the device (and therefore the user). Many computers in the United States will have their language set to English, but fewer will have their language set to English on a machine with a 1920×1080 display with a color depth of 24 and 2 available processors. With enough generic data, the anonymous device becomes identifiable.

So how much data is required? It depends. Which data points are being collected? How large is the pool from which the user is being identified? Within that pool, how common or identifying is each component of the user’s configuration? It’s complicated. But an average browser’s outgoing User Agent string, indicating the operating system version number, the browser version number, and the user’s preferred language, is enough to identify a user uniquely among about 1,500 site visitors. That’s based on just three pieces of information. Fingerprinters can collect dozens.

(If you’re interested in seeing how unique your fingerprint is, the Electronic Frontier Foundation has a tool where you can fingerprint yourself.)

Fingerprinting clearly has privacy implications. While some fingerprinting technologies are deployed for privacy-friendly reasons, such as fraud detection, other technologies can take advantage of fingerprinting’s opacity to infringe on users’ privacy.

When cookies are used to monitor users, they are fairly transparent: users can see when they are set and can delete them after a session ends. Fingerprinting, on the other hand, is difficult for users to even identify, much less avoid, and poses a liability for website owners that is extremely difficult to manage.

Your consent management tool can block cookies when you are required to do so, but fingerprinting cannot be blocked. The vendor will still be collecting data regardless of whether a user arrives with a GPC signal or not. Furthermore, in some situations, vendors have the ability to share that data on a user further with other vendors, enabling cross-site contextualizing. Picture a web analytics vendor identifying a device and assigning a session ID to that user session, and an ad tracker sharing the key on the same user session. Those vendors would be able to share that information server to server, each building a more complete profile of the user without the website owner even knowing. Imagine that DSAR request.

So how can you address this issue in your digital marketing ecosystem? It’s tricky, but there are some best practices.

1. Identify which of your vendors are collecting fingerprinting attributes.
2. Evaluate whether or not each of these vendors should be collecting fingerprinting data. (Remember: not all fingerprinting is bad; there are legitimate use cases.)
3. Request that any vendor without a legitimate use case for collecting fingerprinting data stop collecting that data. For clarification, just because a vendor is collecting fingerprinting attributes does not necessarily mean that vendor is identifying users. However, if there isn’t a legitimate use for collecting the data, turn that funnel off.
4. Evaluate the shared keys among your vendors to identify the possibility of server to server sharing. If you have a vendor collecting fingerprinting data for a legitimate use case (such as fraud detection), then it is time to ensure that that data isn’t flowing out without your knowledge to other vendors. Look for tokens that might share IDs. And talk to your vendor if you see it.

It is quite possible that the infrastructure a site has in place to control cookie-based tracking will not adequately control fingerprint-based tracking, and that fingerprinting vendors will need direct and specific attention for a website to remain compliant. The first step has to be understanding the scope of the problem – what fingerprinting is taking place, and where that data is being sent.

At Vault JS, we spend a lot of time thinking and worrying about fingerprinting. We believe that as cookies become more and more demonized, marketing technologies will turn to fingerprinting. If you are responsible for the marketing technologies on a site or the privacy of its users, it’s worth the effort to understand this challenge sooner rather than later.