Google Analytics does it too, which makes approx. 85% of all web sites you visit.
Google +1 tracks mouse movements?
21–29 of 29 posts
Re: Google +1 tracks mouse movements?
#22Earlier quoted context omitted.
> * 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
Re: Google +1 tracks mouse movements?
#23Earlier quoted context omitted.
Mouse movements have been long used as a source of entropy in desktop applications.
Indeed. Putty's keygen thing has been using it for quite a long time for example
Re: Google +1 tracks mouse movements?
#24I'm not sure how often research papers reflect reality, but Bing may be doing this as well, according to this Microsoft Research paper: http://jeffhuang.com/Final_CursorBehavior_CHI11.pdf
Re: Google +1 tracks mouse movements?
#25Re: Google +1 tracks mouse movements?
#26Re: Google +1 tracks mouse movements?
#27Re: Google +1 tracks mouse movements?
#28According to the link, this is being used as a source of entropy to generate random numbers. Fascinating.
For example, most people on facebook move their pointers to check their notifications/new messages/friend requests. Wouldn't that produce a lot of "not so random" random numbers?
(I am not looking to start a conversation on how random random numbers are, just curious on why they used this specific technique)
Re: Google +1 tracks mouse movements?
#29Earlier quoted context omitted.
> * 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
x=new Date().getTime(); for(j=0;j
gives me high resolution timestamps:1311577733069 1311577733083 1311577733099