For doing this, ServoComputedData is split into separate files, so that
files don't need to include ServoBindings.h just for accessing style
structs from ComputedStyles.
MozReview-Commit-ID: DPAd7PUUCl9
--HG--
extra : rebase_source : 7d6f739b7fb58a46e1624ba62e717412057ea9c1
Previously we used Services.appinfo.defaultUpdateChannel to determine if we were on ESR
and if so, we would assert to make sure the ESR equation hadn't changed. But that method
is a footgun. We could use UpdateUtils.getUpdateChannel, but for our purposes here, the
compile-time constant will work just as well.
If it's set correctly, for Mozilla, we will perform our assert check. If it's not set to
esr (e.g. for Tor), they'll skip the assert. They probably want to control their user agent
themselves anyway.
MozReview-Commit-ID: DLnWSEpCVJ6
--HG--
extra : rebase_source : 0559a10ba1d871a598b1004092840ddf502eef47
do_GetService("@mozilla.org/security/random-generator;1" may initialize NSS.
NSS Initialization occurs on Main Thread only.
If we lock on a subthread, then try to initialize NSS, it _might_ be the case
that the main thread is blocked on the same lock (same location or a different
one.) NSS can't initialize on Main Thread - deadlock.
Move do_GetService out of the lock. Now if NSS tries to initialize on a
subthread, the main thead can't be blocked (because the subthread hasn't locked
anything.)
Now, the only statements that occur in locks are pointer asignment, new, memcpy,
and randomGenerator->GenerateRandomBytes.
MozReview-Commit-ID: 9C1Ok910A11
--HG--
extra : rebase_source : 637ca346a343722bd7a4fc68c4fd43a85916d5a6
Previously we needed this check because we were jittering before NSS was initialized
and this was causing tests to fail (primarily xpcshell and Marionette) because
NSS was being initialied before there was a profile directory.
In Bug 1443943 we only jitter non-System Principal calls and that reduces the early
jitter causes. Ultimately we got to a place where everything was looking okay whether
or not NSS was initialized by the time we got here, so we can simply this code and
simply always perform jittering (if it's enabled and we're not in System Principal
code.)
MozReview-Commit-ID: Dgfi8Z1hHfB
--HG--
extra : rebase_source : 3fcda9b77f3452d85959a639a7361101cc071cd6
Note that by not using the same context pointer for all timestamps within a single
'communication group' (that is, all things that can communication to each other
in JavaScript), it's possible to observe time going backwards.
Imagine comparing
performance.timeOrigin + performance.now() < new File([], "").lastModified
In theory this should always be true. However, if performance.now() was jittered
up (using one context pointer, because it is a relative timestamp) and File was
jittered down (using a null context pointer, because it is an absolute timestamp)
then this may evaluate to False.
I think this is okay.
MozReview-Commit-ID: BfgbmGS8XdD
--HG--
extra : rebase_source : 1d105d9b63e61561be06dbfe2a3fccf534ee68b3
We need to include a seed for each context (origin, iframe, worker, etc) we reduce
the time precision of. This prevents a replay attack of the random midpoint sequence.
MozReview-Commit-ID: EFoHev1SrTM
--HG--
extra : rebase_source : ba92262abaa7b6b20f40423b2dfa749e2a9c43a9
Before, we would initialize LRUCache on the first instance of
calling the Timer Precision Reduction functions. We would both
allocate and initialize it, and call ClearOnShutdown.
ClearOnShutdown can only be called on the Main Thread, but it
just so happened that we always did that, so there was no
problem. Now that we are not calling precision reduction for
system callers, we were initializing on a non-main-thread and
we need to avoid that.
In the future, we could reduce memory use IF we are not using
the timer precision reduction functions by figuring out how
to initialize this lazily but still on the main thread. For
now, because we are using the timer precision reduction
functions, doing so would not save us any memory.
MozReview-Commit-ID: 6YGeAlCPReZ
Negative input times would carry a negative sign all the way
through to where we do pointer math. That's bad, and embaressing.
As far as I know, there was no way to have the resulting value be
outside [-32, 28]. We coerce it down to [0, 28] to always stay in
bounds.
Doing so caused nearly every xpcshell test to fail, as well as Marionette.
This is safe, because we're not going to be doing any web context stuff before NSS is
initialized, so anything that winds up here won't be exposed to content so we don't
really need to worry about fuzzing its value.
MozReview-Commit-ID: KiFSIbjQnN3
--HG--
extra : rebase_source : cb93648d40e75a7a736763e54dfd8c387249989a
We use a mozilla:Mutex to avoid race conditions in the LRU Cache
MozReview-Commit-ID: DyeK4RUnGhP
--HG--
extra : rebase_source : d8f134fd33c914066766cc713292cb0246b05467
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
We use a mozilla:Mutex to avoid race conditions in the LRU Cache
MozReview-Commit-ID: DyeK4RUnGhP
--HG--
extra : rebase_source : 5b7dcf41bc8053236372177585af0eb2e3b72055
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
We eliminate float fuzziness by calculating the reduced precision using
integers in microseconds. (This means we automatically lose any granularity
about nanoseconds, but that's okay.)
MozReview-Commit-ID: D9ReLknsafo
--HG--
extra : rebase_source : 5e95427877289d224441f958bc10cd5b0a3621a9
This commit adds a gtest calling ReduceTimePrecision that illustrates several
failing test cases from float fuzziness, as well as generating a ton of test
cases at random that also fail.
MozReview-Commit-ID: Epia5gm5Ahb
--HG--
extra : rebase_source : 81ec97b15343cc7d713b2445f127a8e11874cd84
This patch creates the capability to have callsites specify if timestamps
should be clamped only in Resist Fingerprinting Mode, or in the more expansive
Timer PRecision Reduction Mode.
Then it changes the CSS Animation callsite to only apply in RFP Mode.
This avoids regressing RFP.
MozReview-Commit-ID: B1pSri0kRk6
--HG--
extra : rebase_source : f3d8c1f9561fbb19d1ca8594ba2b69cffd25445b
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
Bug 1429764 details a test failure that was asserting that the performance navigation
timers were strictly increasing (or equal). fetchStart should have a timestamp before
domainLookupStart. But it didn't.
The problem is two-fold. This corrects the test and the issue by addressing one part
of the problem, the second part of the problem needs to be written up in a new bug
and addressed there. (That bug is not yet filed at writing, but see dependencies of
1429764 in the future to find it.)
The second, and underlying, problem is that calling ReduceTimerPrecision with the
same value multiple times may continually reduce it. Meaning that the first you call
it with, say, .75, (and a precision of .20), it will be reduced to .6. The second time
you call it (with .6), instead of staying at .6 it will be reduced to .4. This is
because floats are fuzzy. Inside ReduceTimerPrecision we are multiplying a decimal by
a decimal, so while floor(.6 / .20) should equal 3, sometimes it's actually 2.999...
which gets floors to 2, gets multiplied again by .2, and which results in .4
If that's the underlying problem, the first, and surface, problem is - why are we
calling ReduceTimerPrecision multiple times? We shouldn't be. That's what this
patch fixes.
TimeStampToDOMHighResOrFetchStart will return either TimeStampToDOMHighRes() or
FetchStartHighRes(). FetchStartHighRes() internally calls TimeStampToDOMHighRes
and then ReduceTimerPrecision - this is where (some of) the two reduction calls
happen - because TimeStampToDOMHighRes itself calls ReduceTimerPrecision also.
I remove the ReduceTimerPrecision from TimeStampToDOMHighRes. FetchStartHighRes
will now only call ReduceTimerPrecision once, at the end of the return.
But we have to fix places we call TimeStampToDOMHighResOrFetchStart, because the
callers of that function also call ReduceTimerPrecision. So if
TimeStampToDOMHighResOrFetchStart returned FetchStartHighRes, we'd be calling
ReduceTimerPrecision twice for those callers.
So inside first off, we remove the outer call to ReduceTimerPrecision. that
surrounds the 5 or so callsites of TimeStampToDOMHighResOrFetchStart. Then
inside of TimeStampToDOMHighResOrFetchStart we return either FetchStartHighRes
(which is has already called ReduceTimerPrecision) or we call
ReduceTimerPrecision with the value.
Now. TimeStampToDOMHighRes was used in more places than just FetchStartHighRes -
there were several other places where we were doing double rounding, and this
fixed those as well. AsyncOpenHighRes, WorkerStartHighRes, DomainLookupEndHighRes,
ConnectStartHighRes, SecureConnectionStartHighRes, ConnectEndHighRes, and
ResponseEndHighRes.
MozReview-Commit-ID: K5nHql135rb
--HG--
extra : rebase_source : e06785203f0f8b01fc7b694ce840f07dc09bc4a1
This pref does not override privacy.resistFingerprinting, but when it is set (and
privacy.resistFingerprinting is not) we will still adjust the precision of almost
all timers. The adjustment amount is the second pref, which is defaulted to
20us but now dynamically adjustable (in the scale of microseconds.)
This patch does _not_ address the performance API, which privacy.resistFingerprinting
disables.
We are landing this preffed on at the current value we clamp performance.now() at
which is 20us.
MozReview-Commit-ID: ESZlSvH9w1D
--HG--
extra : rebase_source : a8afead1bdba958c6c7b383b2216dacb3a1b135c
This patch makes Firefox not to lie about the real operating system when pref
'privacy.resistFingerprinting' is true. This will also change the testcase as well.
MozReview-Commit-ID: Gdnp2lMU3wr
--HG--
extra : rebase_source : 62c408db6dc372091510fe1adf29f529eae99cdc
This patch makes the media statistics report values with a fixed frames per second
and a dynamic dropped ratio when resistance fingerprinting is enabled. The dropped
rate is decided by the video resolution that it will report a fixed dropped rate
when the video resolution is greater than 480p. And It will report a zero dropped
rate if the video is below or equal to 480p. In addition, it adds three new prefs
that allow us to change the value of frames per second, the dropped ratio and the
threshold of target video resolution. The three prefs are
'privacy.resistFingerprinting.video_frames_per_sec', 'privacy.resistFingerprinting.video_dropped_ratio'
and 'privacy.resistFingerprinting.target_video_res'. The default values of them
are 30, 5 and 480, which means 30 frames per second, 5 percent dropped ratio and
480p.
This also adds a new helper function 'nsContentUtils::ShouldResistFingerprinting(nsIDocument* aDoc)'
for checking whether fingerprinting resistance is enabled for a given docuemnt.
If it is a chrome document, this function will indicate that fingerprinting
resistance is not enabled regardless of the pref 'privacy.resistFingerprinting'.
If it is a content document, the result will depend on the pref.
MozReview-Commit-ID: FbSuRq6Zdnn
--HG--
extra : rebase_source : a62a1be19d9b38520f9eed7164fb258e3354d228
The PR_SetEnv() needs the passing string been intentionally leaked. However,
nsRFPService::UpdatePref() uses PR_SetEnv() without leaking the input string.
This patch is going to fix this by using ToNewCString().
MozReview-Commit-ID: 97QQUk2sjM9
--HG--
extra : rebase_source : 10205fe2e9577d5c985572256a5e9842c46d39be
Since user-provided values for the e10s prefs won't be loaded
until the profile's prefs.js file is loaded, we need to wait for
this to occur. The simplest way to do this while keeping the
logic neatly inside nsRFPService seemed to be to add an observer,
but another option would be to just directly call _tzset at the
right time during start-up, or add a static method in nsRFPService
doing this that we could call. This would avoid the overhead of an
observer, but since I don't know how significant that overhead
is I just went with the observer for now.
MozReview-Commit-ID: 6yhvwEoADDy
--HG--
extra : rebase_source : fcb6bfe7136993d2a10bee4f707e4a21230fab27
The reason we call _tzset inside DateTime.cpp is to allow the
privacy.resistFingerprinting pref to mask our timezone by setting
the TZ environment variable. Without _tzset, the changes to the
environment variable won't actually change anything. However, if
a process is started with the TZ environment variable set to
something (like "UTC"), then those changes will be active in
that process. Since we're only masking timezone to JS running in
the content process, and since those content processes will be
started by the parent process which has already set its TZ to UTC,
and will copy that variable to its children, we only need to call
_tzset() when the pref changes, and only in the content process,
provided we are on e10s.
MozReview-Commit-ID: CPU99BGDUPj
--HG--
extra : rebase_source : 4cdf6b5e2aebeff34decd11efa62783f2364dd3a
