Time Precision Reduction in the JS Engine was handled by a small bit of
duplicated logic. With Time Jittering, and general improvements to the
logic due to float fuzziness, we want to unify the logic for the JS Engine
and the browser into one location. This patch does that.
Note that this will leave the JS Shell without a time jittering implementation.
It currently has a time clamping implementation - but I'm not actually sure if
the shell is doing anything with it, because it's probably not calling
SetTimeResolutionUsec to set it up. In Bug 1440539 we will add a jitter
implementation for the shell. (And probably turn time rounding and jittering on
for it too.)
MozReview-Commit-ID: 2BTIMzE8MjW
--HG--
extra : rebase_source : db5cd6a219e1b89988f142fc22994bf816507889
Fuzzytime deterministically generates a random midpoint between two clamped values,
and if the unreduced timestamp is above the midpoint, the time is rounded upwards.
This allows safe time jittering to occur, as time will never go backwards on a given
timeline.
It _is_ possible for time to go backwards when comparing different (but related)
timelines, such as a relative timeline in one page (with its own
performance.timeOrigin) and a relative timeline in an iframe or Worker (which
also has its own performance.timeOrigin). This is the same behavior as the 2ms timer
reduction we previously landed; jitter doesn't make this any better or worse.
MozReview-Commit-ID: IdRLxcWDQBZ
--HG--
extra : rebase_source : 40b29d34e5cc99f9b8e6d5e711a03b9fe9bfa595
Time Precision Reduction in the JS Engine was handled by a small bit of
duplicated logic. With Time Jittering, and general improvements to the
logic due to float fuzziness, we want to unify the logic for the JS Engine
and the browser into one location. This patch does that.
Note that this will leave the JS Shell without a time jittering implementation.
It currently has a time clamping implementation - but I'm not actually sure if
the shell is doing anything with it, because it's probably not calling
SetTimeResolutionUsec to set it up. In Bug 1440539 we will add a jitter
implementation for the shell. (And probably turn time rounding and jittering on
for it too.)
MozReview-Commit-ID: 2BTIMzE8MjW
--HG--
extra : rebase_source : 035f84a88413e2ea34b239ae0228e9c1ec9a39d7
Fuzzytime deterministically generates a random midpoint between two clamped values,
and if the unreduced timestamp is above the midpoint, the time is rounded upwards.
This allows safe time jittering to occur, as time will never go backwards on a given
timeline.
It _is_ possible for time to go backwards when comparing different (but related)
timelines, such as a relative timeline in one page (with its own
performance.timeOrigin) and a relative timeline in an iframe or Worker (which
also has its own performance.timeOrigin). This is the same behavior as the 2ms timer
reduction we previously landed; jitter doesn't make this any better or worse.
MozReview-Commit-ID: IdRLxcWDQBZ
--HG--
extra : rebase_source : e455f934e6e6d65d54c122a6cec9f6cabbd5ac78
This adds JS::Zone to TypeDecls.h. Arguably that is pretty borderline, but
even though the Zone type is only used in a dozen or so places in Gecko,
it's a central concept.
--HG--
extra : rebase_source : 2267ad26c8888f3db9213acdb64ce7a56b1c16e5
extra : source : 7f7eb82a83f47c8e1a4b67527c42f88e35f9ff4a
This patch is adapted from Tor bug 1517.
To offer some protection against timing attacks by JS content pages, in this
patch we round the various time-exposing APIs (such as Date and
Event.timeStamps) to the nearest 100 ms when the pref "privacy.resistFingerprinting" is on.
MozReview-Commit-ID: eGucM9nGTn
--HG--
extra : rebase_source : 3ee600b07943f3954e9a2a9561391f2f7821bb86
Tom Ritter
Dorel Luca
Jason Orendorff
Jonathan Hao
Jessica Jong
Jeff Walden
Phil Ringnalda
Emanuel Hoogeveen
Boris Zbarsky