Yes we should uptake this 3 line change[although with test rebases]. This was discussed before in the security threads before (cced you).

@ksakamoto@chromium.org, can you please help with this. I see you have made changes to this file lately.

I guess we should reduce resolution of User Timing (http://www.w3.org/TR/user-timing/) as well. What about Resource Timing (http://www.w3.org/TR/resource-timing/)?

inferno@, can you also cc: me the security thread?

forwarded you the old thread. 

maybe we can use a shared helper that covers all these 3 cases. Maybe checkout if "The Spy in the Sandbox -- Practical Cache Attacks in Javascript" mentions these ?

I am unable to cc "yos@cs.columbia.edu" here.

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=198348

------------------------------------------------------------------
r198348 | ksakamoto@chromium.org | 2015-07-06T23:47:52.352809Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/misc/webtiming-resolution.html?r1=198348&r2=198347&pathrev=198348
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/timing/PerformanceBase.cpp?r1=198348&r2=198347&pathrev=198348
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/misc/webtiming-resolution-expected.txt?r1=198348&r2=198347&pathrev=198348

Reduce resolution of performance.now to prevent timing attacks

This is a backport of the following WebKit patches by
Alex Christensen <achristensen@apple.com>:
http://trac.webkit.org/changeset/186208
http://trac.webkit.org/changeset/186219

BUG= 506723 
TEST=http/tests/misc/webtiming-resolution.html

Review URL: https://codereview.chromium.org/1214063008
-----------------------------------------------------------------

Note that performance.now() is not the only high-resolution timer available in Chrome on the web.  PNaCl also provides one via clock_gettime().

While we could reduce the resolution of clock_gettime() under PNaCl too, that wouldn't help much, because PNaCl allows multi-threading, and it's easy to build your own high-res timer by creating a thread that increments a memory location in a tight loop.

Similar multi-threading support is proposed to be added to Blink soon via Shared Array Buffers, which adds shared-memory concurrency to Javascript Web Workers.  (See https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/d-0ibJwCS24 and https://www.chromestatus.com/feature/4570991992766464.)

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=198381

------------------------------------------------------------------
r198381 | ksakamoto@chromium.org | 2015-07-07T09:12:12.740108Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/misc/webtiming-resolution-expected.txt?r1=198381&r2=198380&pathrev=198381
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/misc/webtiming-resolution.html?r1=198381&r2=198380&pathrev=198381

Add test for time resolution of User Timing

Resolution of performance.now() is reduced in r198348 to prevent
timing attacks. Since User Timing uses PerformanceBase::now()
internally, its resolution should be now 5 microseconds.

BUG= 506723 

Review URL: https://codereview.chromium.org/1216643007
-----------------------------------------------------------------

Mark, can you please file a new bug to track multithreading issues with Nacl and Web Workers. Do you think a solution is feasible ?

@inferno: OK, I've filed issue 508166.  I don't think a solution is feasible, unfortunately.

Do you mind CC'ing me on the security threads about this? We should be very careful when we make APIs less powerful. The security benefit needs to be clear and measurable because we're also limiting legitimate use-cases in the process. It sounds like this is a case where we might be plugging an attack that is easily done in another way?

Manually move Cr-Blink-Performance-APIs to Cr-Blink-PermissionsAPI

Noting for the record that AFAICT, credit for this discovery goes to Yossef Oren et al from Columbia University based on this paper: http://arxiv.org/abs/1502.07373

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d07a1105b9dfb932278b54c66ca73ff1fce9453f

commit d07a1105b9dfb932278b54c66ca73ff1fce9453f
Author: rmcilroy <rmcilroy@chromium.org>
Date: Tue Sep 29 10:15:51 2015

Clamp PerformanceResource and PerformanceTiming to 5us.

All DomHighResolutionTimes should be clamped to 5us. Do this for
PerformanceResource and PerformanceTiming.

BUG= 506723 

Review URL: https://codereview.chromium.org/1375683002

Cr-Commit-Position: refs/heads/master@{#351277}

[modify] http://crrev.com/d07a1105b9dfb932278b54c66ca73ff1fce9453f/third_party/WebKit/Source/core/timing/PerformanceResourceTiming.cpp
[modify] http://crrev.com/d07a1105b9dfb932278b54c66ca73ff1fce9453f/third_party/WebKit/Source/core/timing/PerformanceTiming.cpp

I think there might be a more 'elegant' solution to the problem of timing attacks…?

To state the problem: The problem is “timing attacks” inside the web browser (the problem is not the resolution of performance.now).

The solution is NOT to just fix performance.now().  Doing so is only playing “whack a mole”, because the timing attack can STILL be performed in other ways.  What about the other issues (moles) raised in #7 by mseaborn?  Like PNaCl/lock_gettime() and SharedArrayBuffer?  (or what about Java applets in other web browsers where Java provides a nano time).  And there are probably other techniques to accurately time events.

In fact, there is now working JavaScript code (running in a fully mitigated Chrome and Canary) showing that a cache hit/miss can be detected without a single call to performance.now() – so the 5us mitigation implemented by this issue has not worked to prevent timing attacks inside of Chrome.

A core problem with timing attacks is that the end user is somehow enticed to open up a web page controlled by an attacker while doing something else important (more and more, presumably in the web browser?).  Just as there is an “incognito mode” in Chrome today, might a solution to this problem be for Chrome to implement a new “banking mode”?

Simplistically, in this new “banking” mode Chrome would (1) enforce that it is the only application running, and (2) only permit a single open tab (or allows multiple tabs, but to a same domain?). [I know this can be done because my daughter has to run a lock down browser for her school that does this very thing].

In fact, if Chrome detects that a 'banking' web page is being visited, Chrome could (should then) recommend (via the yellow bar that appears right below the address bar) that the user enter “banking” mode for extra security.

Is preventing something else (attacker code) from running, while on important 'banking' websites, an effective way to mitigate timing attacks?

This also cripples profiling pretty heavily. I need to profile some code and with clamped time it is entirely useless to me. At the very least there should be a flag to allow full resolution.

See this comment from the relevant spec issue:

https://github.com/tc39/ecmascript_sharedmem/issues/1#issuecomment-175315327

This is not an appropriate solution. The real solution is to address actual info leaks and not the timer resolution.

Since SharedArrayBuffers are landing in Chrome, is this going to be reverted? Otherwise, it's just false security.

You are absolutely right -- it is false security.

A SharedArrayBuffer allows JavaScript to very accurately determine cache hit/miss (the core idea in the security paper).  I know because I have a working implementation of that (tested in Chrome and FF) -- that I shared with the author of the security paper.

Once SAB lands, 'reducing the resolution of performance.now to prevent timing attacks' is a fiction, since the same timing attack can then be made via SAB.