[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #30541 [Applications/Tor Browser]: webgl readPixels FP entropy
#30541: webgl readPixels FP entropy
-------------------------------------------------+-------------------------
Reporter: Thorin | Owner: tbb-
| team
Type: defect | Status:
| needs_review
Priority: Very High | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: tbb-fingerprinting, | Actual Points:
TorBrowserTeam201905R, GeorgKoppen201905 |
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Changes (by gk):
* priority: Medium => Very High
* cc: acat, mcs, brade (added)
* status: new => needs_review
* keywords: tbb-fingerprinting, tbb-fingerprinting-os => tbb-
fingerprinting, TorBrowserTeam201905R, GeorgKoppen201905
Comment:
Replying to [comment:4 Thorin]:
> Stock standard: I never play with the slider, as I'm looking for worst
case scenarios.
Okay, yes, going with the worst case scenario is a good idea. However,
using the Tor Browser default was *not* the worst case scenario
fingerprinting-wise which we support (however, I agree, it should have
been). The worst case scenario here was someone allowing to run WebGL via
click-to-play. That would have triggered this bug already as it is not a
new one. In fact, Arthur has even pointed out that issue in
https://bugzilla.mozilla.org/show_bug.cgi?id=1422890#c3 a while back.
This bug has a cautionary tale to tell (and hopefully some lessons for us
to learn):
1) It's a bad idea to use the security slider for privacy means as it
makes the result harder to analyze. I've been holding that opinion for a
while now but this bug is a strong example for this problem: It seems in
part we relied on WebGL being click-to-play to not escalate an underlying
privacy issue (we did not even create a ticket for the `readPixels()`
issue until yesterday). Tests until up to 8.5a11 showed we were good and
then 8.5a11 adjusted the *security* settings for WebGL.
2) We did not file the bug right away to have it on our radar. I guess
when working on #16005 it would have been a good time. Or once
https://bugzilla.mozilla.org/show_bug.cgi?id=1422890#c3 came up. There is
#26198 but that would likely not have caught this issue.
3) While we put the final fix out in an alpha which gave 4 weeks for
finding this issue, that was not enough. There are tests like
https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#canvas and
folks are using those frequently, but we should be able to do better here
by adding a respective test to our own test suite.
Anyway, here comes a patch for review: `bug_30541_v2`
(https://gitweb.torproject.org/user/gk/tor-
browser.git/commit/?h=bug_30541_v2&id=299097102f6f90757e9b10a21ad34e0a11a640f8).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30541#comment:5>
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