Hacker News Reader

Comment by LewisJEllis | Hacker News Reader

I used to work for a bot mitigation vendor 8-10 years ago, researching / implementing signals for this cat and mouse game.

This will get you past some very mundane bot detections, but really this is like, the very first baby step of a long rabbit hole.

The people who are taking this game seriously are 5-10 years ahead of this step. Good luck ¯\_(ツ)_/¯

View on HN

Yeah that’s my reading. No way this is passing Akamai bot detection.

There are lots of signals like timings, user tapping and scrolling behaviour, signed sessions cookies that represent browsing flows which may be legitimate or not. And that’s all assuming you’re on a good looking IP. To do this you need a large supply of residential IPs which then leads to the dodgy underworld of botnets.

I’d be surprised if this works for anything but the most basic bot protection, this is an advanced space.

If it does work for those cases, they should be either keeping it quiet and making bank, or boasting about having a secret sauce, not basic stuff like this.

Edit: for apps, Akamai provides an SDK that uses things like your motion data to create a signature that suggests that you're a real user. This signature is either injected into API requests or into a webview session. I'm sure it's crackable if you dedicate significant reverse engineering resources to it, but then you've got to crack every version, crack every other implementation from other companies, etc. Non-starter.

I'm just an outsider, but I wonder if these sort of bot-blocker-bypass services can be done by employing people to go to those pages manually.

Sure, but the point of the services is to be cheaper, faster, or more accurate than doing this.

When it comes to "motion data", are you referring to the client's movement around the website, i.e. which URLs they access and in which order? Their taps, clicks, scroll events, and other inputs?

Motion data (especially in the context of an SDK, which I assume means they're talking about in-app environments rather than browser environments) usually refers to gyroscope readouts on a phone or tablet.

A device that stays rock-steady throughout an entire browsing session isn't necessarily suspicious on its own—for example, you could have your phone laid flat on the table while your browse with your pointer finger—but it can be a useful tell in combination with other suspicious factors.

That was my first thought as well but I couldn't believe it. Doesn't access to gyroscope data require some sort of permission prompt in the browser?

It does for the browser APIs, however Akamai provide an SDK to embed in your app, and apps do not require permission for gyro data. Then the standard practice is to a) pull a token out of the SDK for any API requests you make, and b) connect the SDK to any web view instances via the JS bridge so that any requests made in the embedded browser also get the same tokens.

For web-only, I believe they have a JS only bundle that your site can include which I would imagine does different things, but which would also bring a higher risk profile associated with it. Sites use these risk profiles to determine things like whether to offer specific services, whether to ask for more authentication, etc.

Ah! That makes more sense, I thought we were talking about the web.

That said, since I wrote that comment, I found out that on Android, both Firefox and Chrome grant access to gyroscope data without a permission dialog, which is extremely surprising. I don't have an iOS device to verify, but apparently Safari gates the API behind a permission dialog.

Asking out of almost total ignorance of this field, what prevents someone from running a script that sets their agent to a phone browser and then sending fake gyro data? Surely there's a way to emulate enough to make it look like a phone that's being held by someone, right? We can do realistic camera shake in blender to the point where something looks like it's being held by a person, why couldn't we fake minute movements like the device is held?

Why do we even need an actual device? We can emulate if we even need to and set our headers to look like we're coming from a device browser.

I'm sure that happens, but I haven't done any work with gyro data myself. There's similar logic for mouse cursor movements, there are libraries out there that will generate a natural looking curve that moves the cursor from one position to another, with imperfections that emulate human hand movement.

> Why do we even need an actual device? We can emulate if we even need to and set our headers to look like we're coming from a device browser.

This one is much harder, your browser, OS, and hardware leave a uniquely identifiable fingerprint (with Javascript enabled). A website can render some graphical pattern on a <canvas> or audio in an audio context, and the resulting output will have minute differences that originate from your rendering and audio pipelines.

Check out: https://amiunique.org/fingerprint https://browserleaks.com/ https://fingerprint.com/ https://coveryourtracks.eff.org/

You can try to fake these, but it all depends on the sophistication of the target website. You can quickly end up in really deep rabbit holes: https://www.nullpt.rs/devirtualizing-nike-vm-1

Thanks for the well thought answer and interesting links!

It's likely referring to gyroscope, intended to guard against racks of devices sitting somewhere that don't physically move.

Humans move their devices even when typing.

iOS requires explicit permission to grant access to gyroscope info: I tried this page right now in Mobile Safari 16 and got a prompt:

https://sensor-js.xyz/demo.html

I think (though am uncertain) that it’s similar for App Store apps too.

I am aware, yes.

My assumption about an SDK like that is that it's getting that access through some assumed mean(s) that the user just clicks past without thinking.

Very interesting, on Android it's granted by default in both Firefox and Chrome.

It's a never ending battle. Lots of tools aren't as sophisticated as they claim to be, and the current mechanisms inject a lot of "other stuff" that can be easily found. We're trying to do this in a more novel way that's faster, less prone to needing frequent updates, and is more akin to how actual users interact with browsers. Definitely work to be done, but it's exciting to see, and I appreciate the good luck!

Source: Founder@browserless.io

Reply on news.ycombinator.com