5 ms·

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 mun

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 ¯\_(ツ)_/¯

danpalmer 3y ago
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.
- PathfinderBot 3y ago
  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.
  - danpalmer 3y ago
    Sure, but the point of the services is to be cheaper, faster, or more accurate than doing this.
- dns_snek 3y ago
  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?
  - spondylosaurus 3y ago
    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.
    - dns_snek 3y ago
      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?
      - danpalmer 3y ago
        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.
        dns_snek 3y ago
        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.
imathrowaway 3y ago
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

danpalmer 3y ago

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.

PathfinderBot 3y ago
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.
- danpalmer 3y ago
  Sure, but the point of the services is to be cheaper, faster, or more accurate than doing this.
dns_snek 3y ago
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?
- spondylosaurus 3y ago
  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.
  - dns_snek 3y ago
    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?
    - danpalmer 3y ago
      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.
      - dns_snek 3y ago
        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.

imathrowaway 3y ago

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