[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #18279 [Applications/Tor Browser]: Javascript setTimeout can be used for high resolution clock
#18279: Javascript setTimeout can be used for high resolution clock
--------------------------------------+--------------------------
Reporter: cypherpunks | Owner: tbb-team
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: #16110 | Points:
Reviewer: | Sponsor:
--------------------------------------+--------------------------
Comment (by Thorin):
Tom did all the timing into the privacy.resistFingerprinting pref (that's
what I call RFP). He put them behind two prefs (see at least
https://bugzilla.mozilla.org/show_bug.cgi?id=1217238 &
https://bugzilla.mozilla.org/show_bug.cgi?id=1369303 - in FF55/56)
- privacy.resistFingerprinting.reduceTimerPrecision.jitter
- privacy.resistFingerprinting.reduceTimerPrecision.microseconds
`dom.enable_resource_timing` & `dom.enable_performance` are two prefs I
can think of that no longer make a difference, when RFP = true. And
`dom.event.highrestimestamp.enabled` must be true - that pref has just
been removed anyway
(https://bugzilla.mozilla.org/show_bug.cgi?id=1485264).
> Hrm, you mean timing is not clamped in those cases
**Absolutely**. What I'm saying is that that without RFP=true (and there
is more tied behind it than just timing as you know), then you lose
everything. Example: disable RFP, run the two timing tests, you leak high
precision timing. Hence I think you should lock RFP :) Just saying
Might pay to ask tom, because I'm not an expert
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18279#comment:8>
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