Firefox takes a bite out of the canvas ‘super cookie’

Fox snarls

Firefox 58, that’s the next but one version of the browser you all trust but don’t use, is going to become the first of the major browsers to do something about canvas fingerprinting – a devious, cookie-less way of tracking you on the web.

Canvas fingerprinting relies on websites being able to extract data from HTML <canvas> elements silently. In future Firefox users will be asked to give their permission before that extraction can take place, just as users of the Tor Browser are.

The similarity in behaviour to Tor Browser is no accident. That privacy-first browser is actually based on Firefox ESR (Extended Support Release) and a trickle of Tor Browser features and settings have been flowing slowing back upstream and into Firefox for a while now.

In the case of this simple feature, four years slowly.

So let’s look at why it’s better late than never.

Browser fingerprints

Browser fingerprinting has risen to prominence in recent years as the go-to approach for companies who want to track you without giving you a say in the matter.

It works by tracking your browser itself, rather than by tracking a beacon that’s placed on your browser, such as a cookie, Flash LSO (local shared object) or DOM storage value.

Beacons can be blocked or deleted, fingerprints can’t.

Fingerprints use information that’s gathered passively from your browser such as the version number, operating system, screen resolution, language, list of browser plugins and the list of fonts you have installed.

There are many different ingredients that can be used to make up a fingerprint but the more ingredients that are included, and the more entropy available from each one, the easier it is to tell your browser from anybody else’s.

One of the most popular ingredients uses the HTML <canvas> element.

Canvas fingerprints

The <canvas> element is, as you might guess, a surface a browser can draw on.

In canvas fingerprinting your browser is given instructions to render something (perhaps a combination of words and pictures) on a hidden canvas element. The resulting image is extracted from the canvas and passed through a hashing function, producing an ID.

Different graphics cards and operating systems work slightly differently, which means that if you give two different website visitors identical drawing instructions, they’ll actually draw slightly different pictures.

Complex instructions can produce enough variation between visitors to make canvas fingerprinting a potent ingredient in a fingerprinting recipe.

The more complex the instructions, the easier it is to tease out differences between individuals’ browsers, but the basic principle can be seen with a simple test.

The pictures below show the letter T as rendered by Firefox (left) and Safari (right) on my system, with hashes of the images shown beneath. The differences are just about visible, but all that really matters for the purpose of fingerprinting is that they aren’t exactly the same and will therefore produce different hash values.
T rendered by Firefox 33 on OS X55b2257ad0f20ecbf927fb66a15c61981f7ed8fc
T rendered by Safari 8 on OS X17bc79f8111e345f572a4f87d6cd780b445625d3

A step in the right direction

Fingerprinting is difficult to stop because it turns the complexity, customisability and openness of modern browsers against them. The more personalised your browser is, and the more willing it is to share information about itself, the more it stands out in a crowd.

Plugins can help by intercepting known fingerprinting scripts, but they also make things worse by adding entropy to your browser’s fingerprint.

A balance needs to be struck between the usefulness of any given feature and its potential for abuse. Browser vendors also need to stay on top of how features are actually being used, rather than how they’re supposed to be used.

A case in point is the Battery Status API. The feature exists so that “web developers are able to craft web content and applications which are power-efficient”. In fact the ability to determine which of 14,172,310 different levels of charge your battery is at has been largely ignored by developers, but adopted enthusiastically as a fingerprinting technique.

About a year ago it was summarily dumped by Firefox.

To combat canvas fingerprinting the Firefox developers have opted for the pragmatic opt-in approach of Tor Browser instead of outright rejection. That’s because although canvas fingerprinting is a bigger problem than battery status abuse, dropping <canvas> isn’t an option. It isn’t a white elephant like the Battery Status API is, it’s actually a fantastically  useful feature, but just happens to be a very popular fingerprinting technique too.

At least for a few more months, anyway.

Update as of 2017-10-02

Mozilla got in touch to tell us that although the code to ask you for permission before a website can read your canvas exists, it will only be available in nightly builds. In other words, it’s not for regular users of Firefox, for now at least.

So who is it for? It’s in there to make building Tor Browser a little easier:

By integrating this into our code, this saves the Tor Browser team work and allows them to build their browser more easily.

After a few rounds of questions with Mozilla’s PR agency I’ve not been able to determine if the privacy.resistFingerprinting setting that controls the behaviour described in this article will be missing entirely from regular Firefox builds, or will simply be off by default.

Either way it’s very disappointing that Firefox has decided that even though it has the code it needs to take a bold step forward and be the first major browser to help you fight canvas fingerprinting, it won’t.

If you want to do that then, for a while at least, you’ll have to use the Firefox-based Tor Browser instead.