Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google +1 tracks mouse movements?

stackoverflow.com

Post reply on HN
Print view View original

11–20 of 29 posts

Re: Google +1 tracks mouse movements?

#11

Post by glimcat »

baddox wrote: post #8
glimcat wrote: post #6

Earlier quoted context omitted.

I've always been a fan of using electronic noise. It's not complicated to build a device which does this. Weekend project to "hello world" scale if you're not too picky about specifics. Easiest way is probably with a webcam, which will also give you a pretty good bitrate. The general schema is to read out the bias noise. You do this by blocking out any incoming light to get dark noise + bias noise. Dark noise is an a…

There's no way to deploy this over the web, unless you use Flash to acquire their webcam video or audio.

Packet latency, for example.

The general idea is that there are many noise sources which technology normally needs to route around. To find random number sources, you reverse this.

Re: Google +1 tracks mouse movements?

#12

Post by andrewcooke »

glimcat wrote: post #6
Palomides wrote: post #5

cute, but surely there are less intensive ways of generating random numbers?

I've always been a fan of using electronic noise. It's not complicated to build a device which does this. Weekend project to "hello world" scale if you're not too picky about specifics. Easiest way is probably with a webcam, which will also give you a pretty good bitrate. The general schema is to read out the bias noise. You do this by blocking out any incoming light to get dark noise + bias noise. Dark noise is an a…

obsessive correction of small, largely irrelevant detail (while upvoting in general agreement): what you subtract (the constant shift, which actually does have some structure) is the bias. what you're left with is the dark noise.

you could also point the camera at a flat white surface - that would give you a lot more noise (so much you probably don't need to worry about subtracting anything, if you just take the least significant bits from each pixel)

[i hope i'm right - i wrote astronomy image reducing software for a living]

Re: Google +1 tracks mouse movements?

#13

Post by shadowfox »

obtino wrote: post #9
palish wrote: post #4

Earlier quoted context omitted.

Hah! That's so simple, yet so brilliant.

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?

#14

Post by pilif »

glimcat wrote: post #11
baddox wrote: post #8

Earlier quoted context omitted.

There's no way to deploy this over the web, unless you use Flash to acquire their webcam video or audio.

Packet latency, for example. The general idea is that there are many noise sources which technology normally needs to route around. To find random number sources, you reverse this.

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.

Re: Google +1 tracks mouse movements?

#17

Post by yid »

pilif wrote: post #14
glimcat wrote: post #11

Earlier quoted context omitted.

Packet latency, for example. The general idea is that there are many noise sources which technology normally needs to route around. To find random number sources, you reverse this.

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…

> * 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.

Re: Google +1 tracks mouse movements?

#18

Post by glimcat »

andrewcooke wrote: post #12
glimcat wrote: post #6

Earlier quoted context omitted.

I've always been a fan of using electronic noise. It's not complicated to build a device which does this. Weekend project to "hello world" scale if you're not too picky about specifics. Easiest way is probably with a webcam, which will also give you a pretty good bitrate. The general schema is to read out the bias noise. You do this by blocking out any incoming light to get dark noise + bias noise. Dark noise is an a…

obsessive correction of small, largely irrelevant detail (while upvoting in general agreement): what you subtract (the constant shift, which actually does have some structure) is the bias. what you're left with is the dark noise. you could also point the camera at a flat white surface - that would give you a lot more noise (so much you probably don't need to worry about subtracting anything, if you just take the leas…

You're right, my error.

I haven't used IRAF in a long while, but I'm still going to have to chalk that up to "stupid things I said in the absence of sufficient coffee."

Re: Google +1 tracks mouse movements?

#20

Post by pilif »

yid wrote: post #17
pilif wrote: post #14

Earlier quoted context omitted.

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…

> * 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
Post reply on HN