Investigate blocking or mitigating fingerprintjs

[cowlicks]

Their github: https://github.com/Valve/fingerprintjs

• look into blocking //cdn.jsdelivr.net/fingerprintjs2/<VERSION>/fingerprint2.min.js
• Does our current fingerprinting detection detect fingerprintjs? Does it block it?
• Maybe tell the user "please report that ad network X is using fingerprinting"

[jsha]

I think you want fingerprintjs2 for the more recent github repo, too.

[ghostwords]

If they do canvas fingerprinting, they should trigger existing canvas fingerprinting detection.

[ghostwords]

I suggest we confirm that we do indeed catch it via canvas, and then replace this issue with more specific feature suggestions. This to me reads like "Privacy Badger should detect browser fingerprinting", which isn't so helpful.

[alexristich]

I set a breakpoint in the dispatcher() function in webrequest.js, then navigated to both the fingerprintjs2 and Panopticlick sites. I had to tweak the code slightly to not ignore first-party scripts, but when doing so I found one instance of canvas fingerprinting on fingerprintjs2 and something like 7 or 8 instances on Panopticlick.

Looking at fingerprintjs2's current canvas fingerprinting approach, it should definitely be detecting more instances of canvas-related functions.

I'm not super familiar with fingerprinting.js in PB, though I see references to getImageData, fillText and strokeText. Are these the current functions that we monitor for the purposes of detecting canvas fingerprinting?

[ghostwords]

I am not sure what you mean by "instances".

What happens if you take the Fingerprintjs2 script, make a demo page using it, and visit the page with Privacy Badger? Does Privacy Badger report tracking by the script's domain? You could also try to find these scripts in the wild via https://publicwww.com/ or something like it.

[ghostwords]

We detect canvas fingerprinting using a simple behavioral heuristic: If we have a canvas "write" (fillText, strokeText) and a canvas "read" (getImageData, toDataUrl) from the same script, and the last read got data for a rectangle greater than 16px in width and greater than 16px in height, we say it was canvas fingerprinting.

[jawz101]

A couple of add-ons for ideas.
Karma Blocker heuristic-based ad blocking for Firefox github

ScriptSafe for Chrome (fingerprinting) github

[alexristich]

@ghostwords Sorry, "instances" above turned out to be a red herring. Took another look and on the fingerprintjs2 page fpReport displays a fillText and two toDataURL calls. Looks like this:

I'm not sure why toDataUrl appears twice in here; I'd have to spend more time with this code. On first glance though it appears like it is successful in detecting the fingerprinting. Would be happy to spend more time on this next week verifying in a third-party context.

@cowlicks As far as blocking is concerned, I wonder what we might be able to use from Brave.

[ghostwords]

toDataUrl probably appears twice because it gets called twice by the script.

[cowlicks]

@jawz101 @alexristich hehe, the link to Brave you posted actually cites @ghostwords work, and Privacy Badger, as their inspiration.

It is interesting that there is a duplication of effort here. Maybe we can work together with brave to move Fingerprint blocking/detection into its own library to make collaboration and development easier.

[cowlicks]

Check out #1505 if you are interested, it will close this issue.

[ghostwords]

This issue should already be close-able. As I wrote above, "If they do canvas fingerprinting, they should trigger existing canvas fingerprinting detection."

[cowlicks]

@ghostwords fingerprintjs2, augur.io, and likely other fingerprinting tools, use numerous vectors for fingerprinting. They are configurable so that users can choose which types of fingerprinting they want. Some sites might not use canvas fingerprinting detection, especially if they want to avoid detection by Privacy Badger.

Both fingerprintjs2 and augur.io aggregate results from fingerprinting vectors. I reckon this is because the more vectors that get used, the more unique the fingerprint is likely to be. The technique used #1505 leverages this by monitoring many fingerprinting vectors. So as a fingerprinter tries to make its results more unique, the more likely it is to be detected.

[ghostwords]

I added a basic canvas fingerprinting test using Fingerprintjs2 as part of #1678. While it's true that you could configure Fingerprintjs2 to exclude canvas fingerprinting (excludeCanvas - skip canvas fingerprinting entirely (you will most likely not need to set this to true)), we already detect Fingerprintjs2 in its default configuration.

[ghostwords]

#1505 is an interesting approach for heuristically detecting suspicious JS activity for us to explore in the future.

#1527 to me presents the more urgent issue of figuring out what exactly we should learn to block when we detect non-cookie-based tracking (cdn.jsdelivr.net seems like overblocking, but that's what we do now).

I don't think we need to keep this issue open at this time, as per my previous comment.