take steps to mitigate canvas fingerprinting

NEW
Unassigned

Status

()

Core
General
P3
normal
4 years ago
a month ago

People

(Reporter: lonnen, Unassigned)

Tracking

(Blocks: 2 bugs)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fingerprinting][tor][tor-standalone])

(Reporter)

Description

4 years ago
Canvas fingerprinting is described in this paper (https://securehomes.esat.kuleuven.be/~gacar/persistent/the_web_never_forgets.pdf) as being present on 5% of the top 100,000 websites.

We should take steps to mitigate this fingerprinting technique in FF.
Component: General → General
Product: Firefox → Core

Comment 1

4 years ago
The first mitigation that comes to mind for me would be to bundle a default serif, sans-serif, and monospace font with Firefox and then prevent canvas from accessing system fonts.

That way, sites would be forced to use either the bundled defaults or web fonts they provided via @font-face, neither of which would vary from system to system.
bug 732096 is related (fonts), though not directly.
See Also: → bug 732096
fingerprinting via fonts is not at all specific to canvas.

Comment 4

4 years ago
(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #3)
> fingerprinting via fonts is not at all specific to canvas.

True. That's why it's a good place to start. Once you've got a set of good, bundled defaults, you can work on mitigation everywhere.

Plus, ensuring that the "system" fonts are the same on all platforms would simplify testing for web developers.
I don't see why that makes it a good place to start.  I also expect there's a bunch of Web content that relies on canvas and CSS having access to the same set of fonts, by doing things such as using canvas for text measurement of text that's going to become part of the document.  (Hacky, yes, but people do it.)
Another option is to  make canvas (and webgl) introspection a per domain permission (similar to click to play), defaulted to ask first.

Comment 7

4 years ago
My point was that preparations for cutting off access to system fonts *in general* are a good place to start.
(In reply to Stephan Sokolow from comment #1)
> The first mitigation that comes to mind for me would be to bundle a default
> serif, sans-serif, and monospace font with Firefox and then prevent canvas
> from accessing system fonts.

And what happens to all those languages that aren't supported by the "default serif, sans-serif and monospace" fonts, and rely on other fonts from the host system for proper display? Are you proposing that Firefox should bundle a set of default fonts for every script/language?

Comment 9

4 years ago
(In reply to Jonathan Kew (:jfkthame) from comment #8)
> (In reply to Stephan Sokolow from comment #1)
> > The first mitigation that comes to mind for me would be to bundle a default
> > serif, sans-serif, and monospace font with Firefox and then prevent canvas
> > from accessing system fonts.
> 
> And what happens to all those languages that aren't supported by the
> "default serif, sans-serif and monospace" fonts, and rely on other fonts
> from the host system for proper display? Are you proposing that Firefox
> should bundle a set of default fonts for every script/language?

I think it should at least be investigated as an option.

Comment 10

4 years ago
Note that e.g. the new google spreadsheets relies on canvas for all its rendering, including changing fonts etc.
I think comment 1 is a valid approach towards addressing the issue of font fingerprinting via canvas, though it's a massive amount of work.  If we were to pursue it, we ought to have a plan for addressing other sources of entropy on the Web platform so that the fix doesn't end up being useless in the end anyway.

I don't think canvas-specific approaches for addressing the font fingerprinting aspects are worth pursuing since they don't actually reduce amount of entropy detectable from presence or absence of fonts on the system or any version differences within fonts that affect the presence or absence of specific glyphs.

What other big sources of data (other than font fingerprinting) were obtained through canvas in this paper or elsewhere?  (I'm assuming that avoiding leaking the major OS version is probably hopeless, and probably the same for type of CPU, and it's not clear to me how much additional entropy the type of GPU provides on top of the type of CPU; probably not all that much.)
OS: Mac OS X → All
Hardware: x86 → All
Version: 30 Branch → Trunk

Comment 12

4 years ago
A couple of users have raised this issue on SuMo as the news has made the rounds:

https://support.mozilla.org/questions/1011864
https://support.mozilla.org/questions/1015514

Has anyone considered taking the change implemented in the Tor browser, which prompts the user to permit a host to retrieve the image created on the canvas: https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0021-Add-canvas-image-extraction-prompt.patch
(In reply to Jefferson from comment #12)
> Has anyone considered taking the change implemented in the Tor browser,
> which prompts the user to permit a host to retrieve the image created on the
> canvas

See bug 967895.
See Also: → bug 967895
Whiteboard: [fingerprinting] → [fingerprinting][tor]

Updated

2 years ago
Priority: -- → P3

Updated

2 years ago
Blocks: 1260929

Updated

2 years ago
Whiteboard: [fingerprinting][tor] → [fingerprinting][tor][tor-standalone]

Updated

a year ago
Blocks: 1329996

Updated

11 months ago
See Also: → bug 1337157, bug 1217290
Bug 967895 is introducing a user prompt that blocks canvas image extraction. But a better solution would be if we can make the canvas fingerprinting homogeneous for each OS. See discussion at bug 967895, comment 40.

Comment 15

5 months ago
(In reply to Arthur Edelstein (Tor Browser dev) [:arthuredelstein] from comment #14)
> Bug 967895 is introducing a user prompt that blocks canvas image extraction.
> But a better solution would be if we can make the canvas fingerprinting
> homogeneous for each OS. See discussion at bug 967895, comment 40.

homogeneous for each OS? But that then gives away the OS, right? Why make life easy?

I have concerns about this prompt. How often is it going to come up? Is it site remembered (nothing in the site permissions panel)? Will there be a default setting for it in the revamped permissions UI?

This => https://trac.torproject.org/projects/tor/ticket/23227
^^^ THIS .. with a twist. Blocking could lead to breakage (take for example panopticlick where the script fails to complete unless to allow canavas or spoof it. I believe a better approach is to spoof the same value all the time, regardless of OS and be done with it. No prompts, no UI, no site permissions to remember (or get wiped on close). What the spoofed value is, IDK. TBB has a specific value AFAIK.

Using a static enforced spoofed value for the subset of all RFP users will not raise entropy in that subset. Or am I missing something?
FWIW I suggested adding the canvas permission to the site permission panel in bug 967895 comment 31. We could make that a follow-up bug.

Comment 17

3 months ago
(In reply to Johann Hofmann [:johannh] from comment #16)
> FWIW I suggested adding the canvas permission to the site permission panel
> in bug 967895 comment 31. We could make that a follow-up bug.

For reference: see Bug 1413780
You need to log in before you can comment on or make changes to this bug.