[amelius]

> Very very hard. Because the bot author does not have the giant database that FB has to analyze how humans move the mouse around.

Don't forget that Facebook's false positive rate should be very low. There are lots of humans on their platform, and they should all pass the test.

This makes it easier to construct a bot that will pass the test.

[Klathmon]

It won't hurt if humans fail the test every so often, as long as it's under a threshold that humans regularly can overcome.

I can imagine it would be easy to trick the system a few times (either as a bot pretending to be human, or a human acting like a bot), but tricking it consistently over months or years is going to be damn near impossible.

[amelius]

Also don't forget that Facebook probably has to do all detection in Javascript on the client, i.e. with limited resources. I suspect they don't send every mouse-movement to the server. This also means they probably don't have fine-grained historical data.

[Klathmon]

Not necessarily.

I've only given it a few minutes thought, but position and time data is really small, and easy to compress (you don't need to send anything while the user isn't moving the mouse). If it's sent in batches or over an already open websocket, it's not like it's using a ton of resources on the client.

Assuming all of their users (guessing a billion daily active users) are on desktop half of the time (a wildly incorrect assumption I'm sure), and the mouse position data is 1mb per person for the data you care about (which again, seems like a lot), that's 500tb.

For $25k you could store it all. That's nothing compared to the benefits of being able to identify bots on your platform.

[taurine]

Yes, the standard way to do this a few years back for conversion optimization, was to RLE compress and send the data in intervals. Also the resolution/measurement does not need to be in the milliseconds.