Even something as simple as packet latency is really hard to get from JS. the timing functions you get from the browser are way too low resolution. Also the only network latency you can test for is doing an xmlhttp request as that's the only way o do any network communication (minus web sockets which arent generally available)

Aside of that, you get no direct hardware access to measure and even if you would, there is still the timer resolution problem.

Very recent browsers provide an API to get strong random numbers, but this is even less widely available than web sockets.

So either you take the mouse movement or you use something like Java or Flash, or you use bad numbers.

> * the timing functions you get from the browser are way too low resolution.*

The JS time function returns epoch milliseconds, not seconds. At the scale of network latency (hundreds if not thousands of milliseconds), the lower order bits should be effectively uniformly distributed. Resolution isn't your problem, the number of usable bits per network call is.

The problem is that the JS engines in browsers rely on not-so-sophisticated APIs to get to their millisecond values. This means that yes, you do get time in milliseconds, but the value is only updated every 40 to 100 ms

Perhaps not on modern on browsers. In Chromium on Linux, typing this in the dev console:

    x=new Date().getTime(); for(j=0;j<10000;j++); y=new Date().getTime(); for(j=0;j<10000;j++); z=new Date().getTime(); alert(x+' '+y+' '+z)

gives me high resolution timestamps:

1311577733069 1311577733083 1311577733099

I think some browsers on Windows are using QueryPerformanceCounter for timing, which has microsecond precision.