Live data from Hacker News

It is not possible to detect and block Chrome headless

intoli.com

51–60 of 174 posts

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

#51
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…

> let lose the lawyers.

I agree with you there.

Also relevant: Courts: Violating a Website’s Terms of Service Is Not a Crime (https://news.ycombinator.com/item?id=16119686)

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

#52
post #39

Earlier quoted context omitted.

Wow, that is the most evil thing I've heard in a while

Mailinator does the same thing -- http://mailinator.blogspot.com/2011/05/how-to-get-gmailcom-b... I don't see anything wrong with it.

I don't see anything wrong with it, I am just impressed the approach.

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

#53
post #49
post #47

Earlier quoted context omitted.

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?

http://lcamtuf.coredump.cx/p0f3/

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

#54
post #49
post #47

Earlier quoted context omitted.

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?

I don't know the actual fingerprint here but check out nmap: https://nmap.org/

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

#55
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…

Poisoning the well is very effective. We employed it at a large ecommerce company that was getting hit by carders testing credit cards on low price point items(sub $5). We were playing cat and mouse with them for six months. Found certain attributes about the browser that the botnet was using and fed them randomized success/fail responses. After two weeks of feeding them bad data, they left and never came back. They did DDOS us though in retaliation.

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

#56

Earlier quoted context omitted.

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.

wow. hadn't seen this before.

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

#57
post #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.

>Are there thousands upon thousands of sessions coming from the same IP address?

As someone who routinely works behind proxies, I can sympathize strongly with this statement:

"The one thing that I was really trying to get across in writing that is that blocking site visitors based on browser fingerprinting is an extremely user-hostile practice."

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

#58
post #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.

So record actual user input data and generate similar input patterns stochastically.

That said if you try to scale this up beyond what a reasonable, normal user world do in one sitting, you are bound to stand out.

Although that said, I find that I trigger such rate-limiting mechanisms already as a human just when searching Google as a human being and clicking through every last search result page.

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

#59
post #15
post #9

if you want to block scrapers, just add rate limiting...

That's old hat and ineffective. Scrapers usually proxy through large lists of rotating ip addresses. There are lots of services for it.

depends. if you also do tracking for valid navigation paths then rate limiting may be effective.

For instance: if you have a search result with a 1000 pages that someone is trying to scrape if you don't allow people to jump into the middle of the result set then just rotating IPs doesn't work.

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

#60
post #35

Crawlers & scrapers that rely on headless browsers like Chrome often initiate playback of video on the pages they access. The company I work for (Mux) has a product that collects user-experience metrics for video playback in browsers & native apps. It's been a non-trivial effort developing a system to identify video views from headless browsers so that we might limit their impact on metrics. Being able to make this d…

How are they initiating playback? Are they pressing play, or just triggering auto-play behavior?
Post reply on HN