Open Bug 1041818 Opened 10 years ago Updated 7 months ago

take steps to mitigate canvas fingerprinting

Categories

(Core :: Graphics, task, P2)

task

Tracking

()

People

(Reporter: lonnen, Unassigned)

References

(Depends on 3 open bugs, Blocks 2 open bugs)

Details

(Whiteboard: [fingerprinting][tor][fp-triaged])

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.
Product: Firefox → Core
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: → 732096
fingerprinting via fonts is not at all specific to canvas.
(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.
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?
(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.
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
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: → 967895
Whiteboard: [fingerprinting] → [fingerprinting][tor]
Priority: -- → P3
Blocks: meta_tor
Whiteboard: [fingerprinting][tor] → [fingerprinting][tor][tor-standalone]
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.
(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.
(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
Depends on: 1502831
Priority: P3 → P2
Assignee: nobody → xeonchen
Whiteboard: [fingerprinting][tor][tor-standalone] → [fingerprinting][tor][fp-triaged]

Not actively working on this, unassign myself.

Assignee: xeonchen → nobody
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 20 votes and 5 See Also bugs.
:jstutte, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jstutte)

Moving tentatively to Core: Graphics for further triage.

Component: General → Graphics
Flags: needinfo?(jstutte)
Severity: S3 → --
Type: defect → task
You need to log in before you can comment on or make changes to this bug.