In the wake of recent news of CPU bugs like Meltdown and Spectre which rely on precise(-ish) measurments of elapsed time, I find myself in the mood for disabling things like window.performance.now() in my browser (apart from other mitigations, obviously).

  • Is it possible to disable a particular JS API function in either recent Firefox or Chromium? (Preferably by configuration, but I'm also up for compiling from sources if needed.)
  • If so, does it make sense to do so?
  • 6
    It certainly makes sense, Firefox is going to reduce timer resolution because of this: blog.mozilla.org/security/2018/01/03/… – mr.spuratic Jan 4 '18 at 10:46
  • performance.now() isn't as high-res as you might think: performance.now()-performance.now() == -0.005 in chrome – dandavis Jan 4 '18 at 19:10
  • @dandavis That difference is not representative of the timer's actual obtainable resolution, refer to the Mozilla statement linked by mr.spuratic and the paper linked therein. – kralyk Jan 5 '18 at 10:20
  • @kralyk: how is calling it twice in a row not representative, or is there a way to call it faster? – dandavis Jan 5 '18 at 19:49
  • @dandavis There isn't a way to call it faster, but you can still extract high precision by measuring the timer rounding edges. If you want to know how this is done please read the linked paper. – kralyk Jan 6 '18 at 10:27

Before the browsers get patched, you can write a user script to replace these DOM objects with dummies or delete the performance property altogether.

This is mostly a development feature and public website shouldn't need it to function anyways.

However, due to stupid "features" like NaCl/WebAssembly and WebGL, there may be many other ways to do a timing side channel attack in a browser.

| improve this answer | |
  • 4
    Just a note: It may be difficult to truly make these properties inaccessible. The user script would need to run before any other code in every context (frames, web workers, etc.), and ensure they are not still accessible through object prototypes. An attacker might not go that far though. – Alexander O'Mara Jan 4 '18 at 12:08
  • don't forget about web workers: altered dom/bom handles will be fresh in the clean worker context. – dandavis Jan 4 '18 at 19:08
  • @AlexanderO'Mara: An extension could do the work? – Crouching Kitten Jan 5 '18 at 13:22
  • @CrouchingKitten Maybe. I'm not really sure if either a user script or a Web Extension have the necessary API's. – Alexander O'Mara Jan 5 '18 at 13:59
  • @AlexanderO'Mara: if it runs first the script only need to break/clobber the window property. A cleaver hacker can restore new copies, say from a new iframe's window object, but it should stop "drive bys" – dandavis Jan 5 '18 at 19:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.