Live data from Hacker News

It is not possible to detect and block Chrome headless

intoli.com

41–50 of 174 posts

Re: It is not possible to detect and block Chrome headless

#41
Some people seem to have figured out how to detect without relying on fingerprinting the browser. ex. Crunchbase

but headless chrome shouldn't be possible to distinguish from a regular chrome browser.

The only vector to block scraper is some sort of navigational awareness that deviates from a distribution curve + awareness of IP.

but this comes at a great cost to hurting your own real vistors by taxing them with captcha or other annoyances.

Re: It is not possible to detect and block Chrome headless

#42
post #25
post #7

"That’s when it becomes impossible. You can come up with whatever tests you want, but any dedicated web scraper can easily get around them." As long as the logic is hidden from the scrapers, i.e. not running in a web browser, scrapers are at a disadvantage. They don't have the data about the users that websites have. And even something as simple as Accept-Language header associated with an IP subnet is a data point t…

All the passive techniques are much harder to reasons about, but much easier to match. You just look at the complete request/response headers, make sure you match them, and have some good sources to request from. Much harder is stuff like Distil's script injection, where they transparently inject script tags that do fingerprinting, and they obfuscate the code that does so annoyingly (it's not really hard to reverse,…

Did you do a cost estimate for the "Wizard of Oz" solution of having real people with real browsers (and a script to pull data from the site?) Might have been worthwhile.

Re: It is not possible to detect and block Chrome headless

#43
post #26

Isn't it impossible to win the game of blocking headless browsers? What's stopping someone from creating an API that opens up a real browser, uses a real (or virtual) keyboard, types in/clicks the real address, etc. then proceeds to use computer vision to scrape the information from the page without touching the DOM?

You are in principle correct, but in practice you need to account for the side channels of information as well -- does the mouse and keyboard behave like a human or a robot? Are there thousands upon thousands of sessions coming from the same IP address?

The cat and mouse game happens at every level, not just the DOM/browser-detection level.

Re: It is not possible to detect and block Chrome headless

#44
post #26

Isn't it impossible to win the game of blocking headless browsers? What's stopping someone from creating an API that opens up a real browser, uses a real (or virtual) keyboard, types in/clicks the real address, etc. then proceeds to use computer vision to scrape the information from the page without touching the DOM?

well headless browsers exist because they are less expensive to automate than real browsers, adding in the computer vision and the scraper just added a lot of expense.

Re: It is not possible to detect and block Chrome headless

#45

Earlier quoted context omitted.

I'll eat you through a proxy network then, unless you want to slow down your legitimate users too.

I now work for a company that is gathering metadata on the IP address space (in an effort to reduce the amount of abuse that sites and service providers have to deal with). It won't be very long before it'll be possible to identify most of the common proxying networks and block those. Scrapers can respond by setting up something like an ssh tunnel from a residential high speed connection to a remote server (so that s…

Just out of curiosity, how are you going to handle Luminati? They're bot-networking home users all over the world in exchange for free VPN.

Re: It is not possible to detect and block Chrome headless

#46
post #26

Isn't it impossible to win the game of blocking headless browsers? What's stopping someone from creating an API that opens up a real browser, uses a real (or virtual) keyboard, types in/clicks the real address, etc. then proceeds to use computer vision to scrape the information from the page without touching the DOM?

Rate-limiting followed by CAPTCHAs seems to be the usual strategy.

I think Google claims to try to detect humans by parsing out their mouse movements and scroll events.

Re: It is not possible to detect and block Chrome headless

#47
post #27

Sites detecting headless browsers vs headless browsers trying not to be detected by sites, is an arms race that's been going on for a long time. The problem is that, if you're trying to detect headless browsers in order to stop scraping, you're stepping into an arms race that's being played very, very far above your level. The main context in which Javascript tries to detect whether it's being run headless is when ma…

In my experience, the most effective counter measure to scraping is not to block, but rather to poison the well. When you detect a scraper - through what ever means - you don't block it, as that would tip it off that you are on to it. Instead you begin feeding plausible, but wrong data (like, add a random number to price). This will usually cause much more damage to the scraper than blocking would. Depending on your…

That only works if the scrapers are either in a country where you can do something about it.

Also poisoning only works for a while. As soon as they detect the poisoning, they can easily figure out what tripped the scraping detection, and now you need to poison in an even more subtle way because the scrapers know what to look for.

You can't win this game. Especially the "obvious" type of browser checks, where you can tell the js is checking your browser are so easy to circumvent, because you can tell what they're doing.

Really though, I've reversed a few fingerprinting libs in the wild and also looked at some counter measures that are being sold in the blackhat world. Both sides completely and utterly suck.

The fingerprinting stuff is easy to circument if you're willing to reverse a bit of minified JS, the browser automation 'market leader?' is comically bad and it took me 15 minutes to reliably detect it.

That browser/profile/fingerprint automation thingy in the default option sometimes uses a firefox fingerprint while using chrome. Protip: Chrome and Firefox send HTTP headers in different order. Detected, passive, without JS.

Claiming you're on windows while actually running on a Linux VM, your TCP fingerprint gives it away... Detected, passive, without JS.

Really, both sides, step up your game, this is still boring! Or, just stop fighting scrapers, you can't win.

Re: It is not possible to detect and block Chrome headless

#48

Sites detecting headless browsers vs headless browsers trying not to be detected by sites, is an arms race that's been going on for a long time. The problem is that, if you're trying to detect headless browsers in order to stop scraping, you're stepping into an arms race that's being played very, very far above your level. The main context in which Javascript tries to detect whether it's being run headless is when ma…

Scraping is not a real concern for most people. Detecting advertising fraud is the much more pressing issue.

Re: It is not possible to detect and block Chrome headless

#49
post #47
post #27

Earlier quoted context omitted.

In my experience, the most effective counter measure to scraping is not to block, but rather to poison the well. When you detect a scraper - through what ever means - you don't block it, as that would tip it off that you are on to it. Instead you begin feeding plausible, but wrong data (like, add a random number to price). This will usually cause much more damage to the scraper than blocking would. Depending on your…

That only works if the scrapers are either in a country where you can do something about it. Also poisoning only works for a while. As soon as they detect the poisoning, they can easily figure out what tripped the scraping detection, and now you need to poison in an even more subtle way because the scrapers know what to look for. You can't win this game. Especially the "obvious" type of browser checks, where you can…

> Claiming you're on windows while actually running on a Linux VM, your TCP fingerprint gives it away

This is interesting, I’d not heard of this approach. What’s the technique for generating such a fingerprint?

Re: It is not possible to detect and block Chrome headless

#50
The author's navigator.webdriver fix is easily detected, though of course it is fixable with changes to Chrome. This cat and mouse game probably isn't worth pursuing against dedicated adversaries.

    if (navigator.webdriver || Object.getOwnPropertyDescriptor(navigator, 'webdriver')) {
        // navigator.webdriver exists or was redefined
    }
Post reply on HN