[fulafel]

Depends on who you mean by "you". In context of fingerprinting resistance the timing would have to be done by code in certain limited ways using browser APIs or side channels that transmit information outside the JS runtime.

Computations that call into native APIs can be put in the "has observable side effects" category (but in more fine grained treatment, some could have more specific handling).

[foldr]

I'm not sure what you mean. All you need to do is this:

    function computation() { ... }
    before = performance.now();
    computation();
    t = performance.now() - before;

(Obviously there will be noise, and you need to average a bunch of runs to get reliable results.)

[fulafel]

In this case the runtime would not be able to guarantee that the timing has no externally observable side effects (at least if you do something with t). It would then run in the fixed execution speed mode.

[foldr]

Lots of code accesses the current time. So I think you'd end up just running 90% of realistic code in the fixed execution speed mode, which wouldn't be sufficiently performant.

[hexo]

Runtime doesnt have full controll but could introduce a lot of noise in timing and performance. Could it help?

[fulafel]

It's hard to reason about how much noise is guaranteed to be enough, because it depends on how much measurement the adversary has a chance to do, there could be collusion beween several sites, etc. To allow timing API usage I'd be more inclined toward the virtual time thing I mentioned upthread.