Opened 7 years ago

Closed 7 years ago

#6041 closed defect (fixed)

Review rendering-based fingerprinting vectors

Reported by: gk Owned by: mikeperry
Priority: High Milestone:
Component: TorBrowserButton Version:
Severity: Keywords: MikePerry201206
Cc: gk Actual Points: 3
Parent ID: Points: 3
Reviewer: Sponsor:

Description

It is probably hard to estimate the bits of entropy involved in the fingerprinting investigated in http://www.w2spconf.com/2012/papers/w2sp12-final4.pdf correctly. Netherveless, these text/web font rendering issues should get fixed.

Child Tickets

Change History (5)

comment:1 Changed 7 years ago by mikeperry

Keywords: MikePerry201206 added

I'll take a look at this paper this month, but I suspect there's a high amount of joint entropy with the fonts you provide and/or your OS.

comment:2 Changed 7 years ago by mikeperry

Summary: Avoid fingerprinting a user via text and/or web font rendering on canvasReview rendering-based font fingerprinting vectors

Changing this ticket to be about just reviewing that paper and determining if there is actually substantially more info there than what CSS already provides via font name + existence.

comment:3 Changed 7 years ago by mikeperry

Points: 2
Summary: Review rendering-based font fingerprinting vectorsReview rendering-based fingerprinting vectors

Ok, few thoughts on the paper first:

  1. For the most part, I like this paper. It's reasonable and well written, has a decently thought-out defenses section, and doesn't make ridiculously outlandish claims.
  2. We still need source code to reproduce the results. It doesn't look like they tested WebGL "Minimal Mode", and we'll also want to do our own testing too.
  3. It is probably too early in the fingerprinting defenses game to bend over backwards to try to fully conceal OS for this specific vector. OS is likely to leak a ton of different ways. We should go after lower hanging fruit first, until more light is shown upon the threat landscape.
  4. Their concluding rhetorical question about fingerprints being unavoidable on the modern web is nonsense. Computers are mass produced, and are virtualizable. Even in the worst-case scenario, we can provide an anonymity set roughly equivalent to OS and graphics card userbase size. Most likely, we can do quite a bit better than that, especially if we leave WebGL click-to-play.

Now, thoughts on defenses:
I think the "Prompt for canvas image extraction" defense is probably the best option for now due to implementation effort, though I do like their idea of virtualizing the rendering surface during image extraction.

We might also want to enforce different font count limits on the canvas than for normal rendering, or switch to a default font for image extraction. Or maybe we don't care, if we prompt first. I agree that prompts suck, but hopefully this should be an uncommon thing to experience, unless you're making lolcat captions of course.

I'm going to let these thoughts bake for a bit before filing tickets for the above.

comment:4 in reply to:  3 Changed 7 years ago by gk

Replying to mikeperry:

Ok, few thoughts on the paper first:

  1. For the most part, I like this paper. It's reasonable and well written, has a decently thought-out defenses section, and doesn't make ridiculously outlandish claims.
  2. We still need source code to reproduce the results. It doesn't look like they tested WebGL "Minimal Mode", and we'll also want to do our own testing too.

https://github.com/kmowery/canvas-fingerprinting

  1. It is probably too early in the fingerprinting defenses game to bend over backwards to try to fully conceal OS for this specific vector. OS is likely to leak a ton of different ways. We should go after lower hanging fruit first, until more light is shown upon the threat landscape.

I fully agree with 1.-3.

  1. Their concluding rhetorical question about fingerprints being unavoidable on the modern web is nonsense. Computers are mass produced, and are virtualizable. Even in the worst-case scenario, we can provide an anonymity set roughly equivalent to OS and graphics card userbase size. Most likely, we can do quite a bit better than that, especially if we leave WebGL click-to-play.

Well, I read it in this way that they fear we'll loose in the long run because new fingerprintable features are added faster than we can fix them. But that remains to be seen...

Now, thoughts on defenses:
I think the "Prompt for canvas image extraction" defense is probably the best option for now due to implementation effort

+1

comment:5 Changed 7 years ago by mikeperry

Actual Points: 3
Points: 23
Resolution: fixed
Status: newclosed

Ok. I created #6253 for the defense ticket.

FYI: I spent some time trying to set up their testing server but was defeated by Ruby. If anyone manages to get an instance running, it would be useful. In particular, I'm curious if WebGL's "Minimal Mode" actually introduces any rendering output differences.

Note: See TracTickets for help on using tickets.