User.js: reminder: dom.enable_performance_navigation_timing

Created on 3 Jul 2018  路  8Comments  路  Source: arkenfox/user.js

  • dom.enable_performance_navigation_timing
  • dom.enable_performance_observer
  • maybe also enforce dom.enable_performance=false regardless of RFP

hi-res timing can be a bitch

Most helpful comment

https://bugzilla.mozilla.org/show_bug.cgi?id=1485264

dom.event.highrestimestamp.enabled. default (FF61 at least) is true - maybe we should add this and enforce it, because I've seen at least a couple of times now where people get confused. The pref name is a tad ambiguous and the desired outcome is oxymoronic

All 8 comments

https://groups.google.com/forum/#!topic/mozilla.dev.platform/1OZrP1hR_SE

As of the 25th of september I landed bug 1263722 which adds a PerformanceNavigationTiming entry to the existing performance API. The implementation had a few issues which were fixed in bug 1403926, which also puts this feature behind a pref: dom.enable_performance_navigation_timing

Work on Navigation Timing 2 is tracked in bug 1043083. Link to standard: https://www.w3.org/TR/navigation-timing-2/

[Conspiracy]I have the feeling resistFingerprinting is a gimmick. I don't trust mozilla's developers. They are most probably google's employees and undercover agents working for the 3 letter agencies.[/Conspiracy]

user_pref("dom.enable_performance", false);
user_pref("dom.enable_performance_navigation_timing", false);
user_pref("dom.enable_performance_observer", false);

conspiracy lulz .. no way. I was just following some ESR-60 tor track tickets, and this sticks out, and reminds me of numerous places where high precision timing has leaked in the past.

here's a little handy link: https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=closed&status=merge_ready&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&keywords=~ff60-esr&order=priority

^^ that and dom.enable_performance_navigation_timing is not in the user.js (but no doubt covered by our diffs) - but I want to revisit a lot of things as TBB-ESR60 gets worked on

Isn't this similar to the FF58 entries:

// privacy.reduceTimerPrecision
// privacy.reduceTimerPrecision.microseconds

Found here?

Isn't this similar to the FF58 entries:

// privacy.reduceTimerPrecision
// privacy.reduceTimerPrecision.microseconds

I never added those to the user.js as I believe they should be left alone. I think these are handled at a much earlier point in the data flow, so should mitigate unknown leaks. But I also want to see what TBB ESR60 do. So I guess that also means I should watch what they set for those prefs as well. I plan on doing a compare with our user.js vs TBB ESR60 when it gets released in Sept (cue Earthlng)

https://bugzilla.mozilla.org/show_bug.cgi?id=1485264

dom.event.highrestimestamp.enabled. default (FF61 at least) is true - maybe we should add this and enforce it, because I've seen at least a couple of times now where people get confused. The pref name is a tad ambiguous and the desired outcome is oxymoronic

I'll close this and merge it with #491

Was this page helpful?
0 / 5 - 0 ratings

Related issues

GIPeon picture GIPeon  路  3Comments

Thorin-Oakenpants picture Thorin-Oakenpants  路  5Comments

earthlng picture earthlng  路  4Comments

Thorin-Oakenpants picture Thorin-Oakenpants  路  5Comments

Thorin-Oakenpants picture Thorin-Oakenpants  路  4Comments