f9b50b59cbd881d2bfa2f866f7a3fbfb3894e936: Bug 1440195 Actually integrate the context mix-in into the hash function calculation r?baku draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 16:26:56 -0600 - rev 765648
Push 102130 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:50:03 +0000
Bug 1440195 Actually integrate the context mix-in into the hash function calculation r?baku MozReview-Commit-ID: 4k7w683UJOY
0967e573f9fa600e9a93ce722930afa5a553b88f: Bug 1440195 Address CSS Animations r?birtles draft
Tom Ritter <tom@mozilla.com> - Mon, 05 Mar 2018 15:58:46 -0600 - rev 765647
Push 102130 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:50:03 +0000
Bug 1440195 Address CSS Animations r?birtles For now, we are going to make _all_ CSS Animations related timer fuzzing only applicable in Resist Fingerprinting Mode (addressing the last couple that had not already been configured that way.) We hardcode their content mix-ins as zero, but leave comments indicating how they should behave. MozReview-Commit-ID: KhmV7wO8Pt5
4214ef8ca7c339042e3bfa54f0974de543a06580: Bug 1440195 Add a random context seed to the Performance APIs r?baku draft
Tom Ritter <tom@mozilla.com> - Mon, 05 Mar 2018 16:29:40 -0600 - rev 765646
Push 102130 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:50:03 +0000
Bug 1440195 Add a random context seed to the Performance APIs r?baku We attach it to WorkerPrivate and DOMNavigationTiming so it will be re-used when it should. WorkerPrivate is used in the Performance APIs, Performance Storage Worker, and Event. DOMNavigationTiming is used only in the Performance APIs, but the crucial part is that when the individual DOMNavigationTiming object is re-used, so will the context seed. This in particular came up with the nav2_test_document_open.html Web Platform Test which illustrated the fact that even if you .open() a new document, the performance navigation data is not supposed to change. MozReview-Commit-ID: GIv6biEo2jY
e7f4a86dbeffd51099c48b3b63004a65f4986aeb: Bug 1440195 Add a random context seed for AudioContext and MediaStream r?baku draft
Tom Ritter <tom@mozilla.com> - Thu, 01 Mar 2018 11:00:12 -0600 - rev 765645
Push 102130 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:50:03 +0000
Bug 1440195 Add a random context seed for AudioContext and MediaStream r?baku MozReview-Commit-ID: sHpVCgd8Fs
9a8b0cfe6712ff98288e3839359037ca87a051b7: Bug 1440195 For timestamps that are absolute, specify a null context pointer r?baku draft
Tom Ritter <tom@mozilla.com> - Wed, 28 Feb 2018 15:37:26 -0600 - rev 765644
Push 102130 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:50:03 +0000
Bug 1440195 For timestamps that are absolute, specify a null context pointer r?baku 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
8f6a401cdc1a03d8d420e186acd26da0daad1dfc: Bug 1440195 Add a per-context mix-in value for our Timer Precision Reduction Functions r?baku draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 16:22:37 -0600 - rev 765643
Push 102130 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:50:03 +0000
Bug 1440195 Add a per-context mix-in value for our Timer Precision Reduction Functions r?baku 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
71a81aa2d64a24a6708ac5c7614dfd1ecbae996c: Bug 1443943 Do not clamp/jitter event timestamps if it's a system principal draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 10:00:23 -0600 - rev 765642
Push 102130 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:50:03 +0000
Bug 1443943 Do not clamp/jitter event timestamps if it's a system principal This patch has an annoying gap in it. I follow the pointer chain up like so: mPresContext->Document()->NodePrincipal() However, sometimes either mPresContext or mPresContext->Document() is null. I don't know why. MozReview-Commit-ID: KvVJpvu4elN
34443301a12ab18cf7c29f555f8ed1b735c3586a: Bug 1443943 Do not clamp/jitter in the JS Engine if it's system context draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 09:49:28 -0600 - rev 765641
Push 102130 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:50:03 +0000
Bug 1443943 Do not clamp/jitter in the JS Engine if it's system context MozReview-Commit-ID: LqL7xaYoHCT
f84f41e061aa0293c2f79ee2d865cc7d1ed1c804: Bug 1443943 Port the performance APIs only to only clamping/jittering on non-System Principal draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 09:29:33 -0600 - rev 765640
Push 102130 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:50:03 +0000
Bug 1443943 Port the performance APIs only to only clamping/jittering on non-System Principal MozReview-Commit-ID: FKYLI5Yc1kX
a288b5547cd6e875c254393d46c7508dbd4f2a32: Bug 1440346 - Replace abbreviated strings in the sync bookmark mirror's tree log with full names r?kitcambridge draft
Thom Chiovoloni <tchiovoloni@mozilla.com> - Fri, 09 Mar 2018 14:19:15 -0800 - rev 765639
Push 102129 by bmo:tchiovoloni@mozilla.com at Fri, 09 Mar 2018 22:45:10 +0000
Bug 1440346 - Replace abbreviated strings in the sync bookmark mirror's tree log with full names r?kitcambridge MozReview-Commit-ID: 2TqZPWVHIUm
f48b1c12b6c73d1476c9bc1785c5e4facf0508ac: Bug 1440195 Actually integrate the context mix-in into the hash function calculation r?baku draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 16:26:56 -0600 - rev 765638
Push 102128 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:42:54 +0000
Bug 1440195 Actually integrate the context mix-in into the hash function calculation r?baku MozReview-Commit-ID: 4k7w683UJOY
bc99459dd4f0e6f9d1818c4a31d948e56aed46ce: Bug 1440195 Address CSS Animations r?birtles draft
Tom Ritter <tom@mozilla.com> - Mon, 05 Mar 2018 15:58:46 -0600 - rev 765637
Push 102128 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:42:54 +0000
Bug 1440195 Address CSS Animations r?birtles For now, we are going to make _all_ CSS Animations related timer fuzzing only applicable in Resist Fingerprinting Mode (addressing the last couple that had not already been configured that way.) We hardcode their content mix-ins as zero, but leave comments indicating how they should behave. MozReview-Commit-ID: KhmV7wO8Pt5
ff7e31550f51d199f5e45437436b6f35403a67c7: Bug 1440195 Add a random context seed to the Performance APIs r?baku draft
Tom Ritter <tom@mozilla.com> - Mon, 05 Mar 2018 16:29:40 -0600 - rev 765636
Push 102128 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:42:54 +0000
Bug 1440195 Add a random context seed to the Performance APIs r?baku We attach it to WorkerPrivate and DOMNavigationTiming so it will be re-used when it should. WorkerPrivate is used in the Performance APIs, Performance Storage Worker, and Event. DOMNavigationTiming is used only in the Performance APIs, but the crucial part is that when the individual DOMNavigationTiming object is re-used, so will the context seed. This in particular came up with the nav2_test_document_open.html Web Platform Test which illustrated the fact that even if you .open() a new document, the performance navigation data is not supposed to change. MozReview-Commit-ID: GIv6biEo2jY
c299c2a139f372aa5d8fb29ccadd082f5c1aea7a: Bug 1440195 Add a random context seed for AudioContext and MediaStream r?baku draft
Tom Ritter <tom@mozilla.com> - Thu, 01 Mar 2018 11:00:12 -0600 - rev 765635
Push 102128 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:42:54 +0000
Bug 1440195 Add a random context seed for AudioContext and MediaStream r?baku MozReview-Commit-ID: sHpVCgd8Fs
428e04d9e6bf0b5eab398fb181bda71ae61a6bf3: Bug 1440195 For timestamps that are absolute, specify a null context pointer r?baku draft
Tom Ritter <tom@mozilla.com> - Wed, 28 Feb 2018 15:37:26 -0600 - rev 765634
Push 102128 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:42:54 +0000
Bug 1440195 For timestamps that are absolute, specify a null context pointer r?baku 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
472daabc44f8335b1dc3ea101c6bc4d7626e8176: Bug 1440195 Add a per-context mix-in value for our Timer Precision Reduction Functions r?baku draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 16:22:37 -0600 - rev 765633
Push 102128 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:42:54 +0000
Bug 1440195 Add a per-context mix-in value for our Timer Precision Reduction Functions r?baku 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
02ca5e37370782e7f5b994cf22bad82fee8d8a4f: Bug 1443943 Do not clamp/jitter event timestamps if it's a system principal draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 10:00:23 -0600 - rev 765632
Push 102128 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:42:54 +0000
Bug 1443943 Do not clamp/jitter event timestamps if it's a system principal This patch has an annoying gap in it. I follow the pointer chain up like so: mPresContext->Document()->NodePrincipal() However, sometimes either mPresContext or mPresContext->Document() is null. I don't know why. MozReview-Commit-ID: KvVJpvu4elN
e7de78db2e79be5bf640380a6e5ef4c9cd1b96bc: Bug 1443943 Do not clamp/jitter in the JS Engine if it's system context draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 09:49:28 -0600 - rev 765631
Push 102128 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:42:54 +0000
Bug 1443943 Do not clamp/jitter in the JS Engine if it's system context MozReview-Commit-ID: LqL7xaYoHCT
d2603ecc3efd0872c773bf6ff350ad8c10b0567a: Bug 1443943 Port the performance APIs only to only clamping/jittering on non-System Principal draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 09:29:33 -0600 - rev 765630
Push 102128 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:42:54 +0000
Bug 1443943 Port the performance APIs only to only clamping/jittering on non-System Principal MozReview-Commit-ID: FKYLI5Yc1kX
3408a8fae11d2750d1f9e8bd6be0be5436035257: Bug 1443943 Move LRUCache Initialization to startup rather than lazily draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 11:52:33 -0600 - rev 765629
Push 102128 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:42:54 +0000
Bug 1443943 Move LRUCache Initialization to startup rather than lazily 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: GqkfouVSeG8
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip