Closed
Bug 1485264
Opened 6 years ago
Closed 6 years ago
Rip out the dom.event.highrestimestamp.enabled pref
Categories
(Core :: DOM: Events, enhancement, P3)
Core
DOM: Events
Tracking
()
RESOLVED
FIXED
mozilla67
Tracking | Status | |
---|---|---|
firefox67 | --- | fixed |
People
(Reporter: arthur, Assigned: jcit)
Details
(Keywords: good-first-bug, Whiteboard: [tor][fingerprinting][fp-triaged])
Attachments
(1 file)
To improve fingerprinting resistance, Tor Browser always uses DomHighResTimeStamp instances. We set "dom.event.highrestimestamp.enabled" to true. We would like the same behavior if privacy.resistFingerprinting is enabled.
An alternative solution would be to remove the "dom.event.highrestimestamp.enabled" pref altogether.
Comment 1•6 years ago
|
||
It's been several years; can we rip out the dom.event.highrestimestamp.enabled pref at this point?
Component: DOM → DOM: Events
Flags: needinfo?(bugs)
Updated•6 years ago
|
Whiteboard: [tor] → [tor][fingerprinting]
Comment 2•6 years ago
|
||
+1: rip it out. I know it's only exposed in about:config, but misinformed users can/do get the wrong impression and disable it believing they have reduced FP'ing. It's kind of an oxymoronic(?) name when paired with FP'ing.
Updated•6 years ago
|
No longer blocks: uplift_tor_fingerprinting
Keywords: good-first-bug
Summary: When privacy.resistFingerprinting is enabled, always use highrestimestamps → Rip out the dom.event.highrestimestamp.enabled pref
Updated•6 years ago
|
Whiteboard: [tor][fingerprinting] → [tor][fingerprinting][fp-triaged]
Updated•6 years ago
|
Priority: -- → P3
Comment 4•6 years ago
|
||
Happy to review.
https://searchfox.org/mozilla-central/search?q=dom.event.highrestimestamp.enabled&path=
and
https://searchfox.org/mozilla-central/search?q=symbol:_ZN7mozilla3domL23sReturnHighResTimeStampE&redirect=false
can be useful
Flags: needinfo?(bugs)
Assignee | ||
Comment 5•6 years ago
|
||
Currently looking into this. Could this be assigned to me?
Assignee | ||
Comment 7•6 years ago
|
||
Comment 8•6 years ago
|
||
Btw, just hint if you need someone to land the change :)
Thanks for fixing this.
Assignee | ||
Comment 9•6 years ago
|
||
Still not entirely familiar with landing changes, do I need to mark the issue as resolved now?
Comment 10•6 years ago
|
||
If you push the final patch to phabricator, I think I can land it there using Lando (assuming you don't have rights to use that).
Assignee | ||
Comment 11•6 years ago
|
||
Ok, just pushed the final version. Hopefully that should be it
Comment 12•6 years ago
|
||
In general, you can set the checkin-needed keyword and it will be landed for you. The bug will be closed once the patch merges to mozilla-central. (Initially, it will land on an integration branch.)
Comment 13•6 years ago
|
||
Pushed by rmaries@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/47629d4e3150
Removed dom.event.highrestimestamp.enabled pref r=smaug
Comment 14•6 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox67:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Comment 15•6 years ago
|
||
Josef, thank you for fixing this!
You need to log in
before you can comment on or make changes to this bug.
Description
•