Some PDFs trigger canvas fingerprinting warning false-positives

[xcolour]

We have observed that some PDFs cause canvas fingerprinting (https://en.wikipedia.org/wiki/Canvas_fingerprinting) warnings to trigger in certain browsers. This issue seems to trigger specifically in image-heavy PDFs.

For example: https://www.aclu.org/foia-document/some-key-sso-cyber-milestone-dates-fall-2005.

We have seen warnings trigger in the most recent version of the Tor Browser Bundle (5.5.2) as well as with the Chrome extension Canvas Fingerprint Block (https://chrome.google.com/webstore/detail/canvasfingerprintblock/ipmjngkmngdcdpmgmiebdmfbkcecdndc).

This issue was noted a while back by the Tor project (https://trac.torproject.org/projects/tor/ticket/10570). They appear to have resolved it by whitelisting the locally-available version of PDF.js provided by Firefox, but that fix doesn't seem to apply to PDF.js when it's served by the website.

We use the PDF.js provided via the "PDF" Drupal extension version "7.x-1.6" with PDF.js version "1.1.215".

I understand that canvas fingerprinting is an intentionally obfuscated de-anonymization technique and that detection is necessarily heuristic. It may be that PDF.js is doing something that is legitimately indistinguishable from canvas fingerprinting, but it would be nice if there were a way to avoid tripping the detection algorithms. Some of our more privacy-conscious site visitors have noted that it's a bit creepy to be warned by your browser that you're being tracked while trying to read FOIA docs!

Thanks for reading and let me know if this is too open-ended for your issue tracker. I'll be happy to re-submit to your dev mailing list.

I've opened a parallel ticket for the Tor Browser team: https://trac.torproject.org/projects/tor/ticket/18390#ticket.

[yurydelendik]

To understand the issue we need to know algorithm for detecting of canvas fingerprinting. If it's just a generic CANVAS access there is nothing we can do. However if it's just access to some specific function such as getImageData or toDataURL then there might be change to fix that. We are using toDataURL to generate thumbs. I wonder if we can detect that and disable this optimization for tor.

[xcolour]

I got a brief response from the Tor devs, and it sounds like any attempt to peek at the contents of the canvas will trigger their check. I haven't had a chance to dig into the code yet, but they specifically mentioned getImageData and to{Blob,Url,File,...}. I would guess there are more. I'll try to get you a complete list.

I think, from my perspective, I'd prefer an option to simply disable the features (like thumbs) that can't be implemented without peeking into the canvas over some kind of detection scheme specifically for Tor. Obviously, that only works if those features can be isolated. I could imagine disabling happening as a compile-time option that entirely eliminates the code from the library or just a flag that disables it at the time the PDF gets loaded into the page.

[yurydelendik]

Some feature can be disabled, some would have affect on the PDF display. FWIW getImageData is not used during display of the PDF above, but there are PDFs that might trigger that.

Workaround for thumbs can be their disabling for Tor browser or display them in non-optimal way.

[xcolour]

The detection function appears to be IsImageExtractionAllowed: https://gitweb.torproject.org/tor-browser.git/tree/dom/canvas/CanvasUtils.cpp?h=tor-browser-38.5.0esr-5.5-2#n47.

It gets called a few times in the canvas code. Looks like the canvas API calls that trigger the fingerprinting warning alert are:

• getImageData
• isPointInPath
• isPointInStroke
• toBlob
• toDataURL
• mozFetchAsStream
• mozGetAsFile

[xcolour]

Looks like isFontSubpixelAAEnabled calls getImageData, which is what's triggering the fingerprinting warning at https://www.aclu.org/foia-document/some-key-sso-cyber-milestone-dates-fall-2005.

https://github.com/mozilla/pdf.js/blob/master/src/display/canvas.js#L1381

[yurydelendik]

@xcolour we can disable this check (it will affect the display quality for some old windows machines). Now we need to decide how we are going to detect if reading back from the canvas might trigger the issue. Has Tor any signs to detect it?

[yurydelendik]

Probably http://stackoverflow.com/a/28202492

[Snuffleupagus]

Note that PR #7029 adds a switch to PDFThumbnailView, which makes it possible to skip the toDataURL when generating thumbnails (it just uses the canvases instead).

[Snuffleupagus]

Given that, as mentioned above in e.g. https://github.com/mozilla/pdf.js/issues/7026#issuecomment-188561443, we cannot generally remove certain canvas-accesses without affecting and/or breaking actual rendering; hence closing this old issue as WONTFIX.