[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #13021 [Tor Browser]: Review Canvas APIs for fingerprintability
#13021: Review Canvas APIs for fingerprintability
-------------------------+-------------------------------------------------
Reporter: | Owner: brade
mikeperry | Status: assigned
Type: task | Milestone:
Priority: major | Version:
Component: Tor | Keywords: ff31-esr, tbb-fingerprinting,
Browser | TorBrowserTeam201409
Resolution: | Parent ID:
Actual Points: |
Points: |
-------------------------+-------------------------------------------------
Comment (by gacar):
Replying to [comment:3 dcf]:
> Replying to [comment:2 gacar]:
> > I checked https://bugzilla.mozilla.org/show_bug.cgi?id=884226: This
brings a new canvas context property (`willReadFrequently`) that enables
reading from a software backend instead of a hardware "accelerated" one,
which turns out to be super-slow for some cases.
>
> If a browser has both accelerated and non-accelerated canvases, they
probably don't render things identically. You could draw the same
fingerprinting issue in both and hash them together, and thereby get more
discriminating power than one canvas alone.
>
> I agree that willReadFrequently doesn't add any new fingerprinting
power, because in its absence you just have to game whatever heuristic
decides whether you get an accelerated or non-accelerated canvas.
Yep, makes it easier to get a 2-in-1 canvas fingerprint from standard
browsers.
But it's not a threat for Tor Browser, I suppose. Since TB returns a white
canvas regardless of HW/SW backend.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13021#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs