5 ms·

Interesting. I've done a lot of scraping and I never did this. Do you have a treatise that explains how it's done? I've actually been experimenting with headles

by dsacco 9y ago

Interesting. I've done a lot of scraping and I never did this. Do you have a treatise that explains how it's done? I've actually been experimenting with headless Chrome recently because I like it more than PhantomJS. Practically speaking I don't think IP detection is useful at all these days, and the only Captcha that can't be bypassed is Google's most recent version. The much more successful anti-scraping tactic is to use a sophisticated reverse proxy that analyzes all requests to identify patterns and unusual behavior, indiscriminate from the IP source (because any large scale scraping will come from many IPs anyway).

heipei 9y ago
If you know how to interface with Chrome headless then you're 95% there already. Just run xvfb, start a Chrome instance on the DISPLAY with the appropriate flags (for exposing the debugging port) and you're done.
IgorPartola 9y ago
IP detection, especially IPv4, should still work fine because the cost to get a new IP will often outweigh the benefit of the scraping. Having said that, just let them scrape?
- heipei 9y ago
  There are multiple ways to hide your IP for free: Public proxies, VPNs which are not so well-known, and lastly there is a wealth of browser extensions which aim at hiding your IP to some extent. This would be one example where your traffic will exit with actual users on consumer ISP lines: http://hola.org/ http://hola.org/
  - ant6n 9y ago
    What about tor.
    - heipei 9y ago
      TOR is an easy one to detect. Case in point: Try to browse the web with TOR and see how many CloudFlare captchas you have to solve in the first 10 minutes ;) Also TOR has public lists of exit nodes (https://torstatus.blutmagie.de/ https://torstatus.blutmagie.de/), and unless you exit via a non-listed one you're trivially identifiable. Lastly, TOR is rather slow, which prohibits using for large-scale scraping tasks. Plus you get switched around different exits and countries, which might break your scraping logic.
      - crtasm 9y ago
        I believe you could use the ExitNodes option to only use a specific exit. There's no such thing as an unlisted exit node, only unlisted entry nodes (bridges). I agree that Tor isn't a good choice for scraping.
    - dsacco 9y ago
      Tor would introduce pretty intolerable latency into a professional data crawling setup.
  - ficklepickle 9y ago
    I'd say don't use Hola. They've had some issues, like selling their users bandwidth for botnets[1]. If you do some googling, you will see many reasons not to use that extension. [1]http://www.theverge.com/2015/5/29/8685251/hola-vpn-botnet-selling-users-bandwidth http://www.theverge.com/2015/5/29/8685251/hola-vpn-botnet-se...
- tyingq 9y ago
  >Having said that, just let them scrape? Depends on who you are. Hotel and airline websites, for example, are pummeled with scrapers wanting pricing and availability info. Letting them scrape with no limits is costly.
  - dsacco 9y ago
    > Hotel and airline websites, for example, are pummeled with scrapers wanting pricing and availability info. Yes, and they make it very cumbersome to discourage it. I've successfully written scrapers for airlines. It's significantly more difficult than crawling other websites for a few reasons: 1. Session management is wacky - they really like to manage state entirely through cookies, and you typically need to visit a specific set of pages in a specific sequence before you can access the resources you want, like the number of seats available or their prices. 2. Sessions have time limits because anyone who looks at the seats initiates a "soft" reservation on them (this works in a similar way for theatre, concert and movie seating). 3. You don't usually have nice JSON endpoints, so you'll be doing a lot of HTML parsing (which, given the type of HTML you encounter, can be hell).
    - tyingq 9y ago
      >You don't usually have nice JSON endpoints, so you'll be doing a lot of HTML parsing That is changing. Most scrapers haven't caught on, but the more modern things airlines are pushing out (their mobile sites and native mobile apps) often have really nice REST/JSON api interfaces. The scrapers are often still scraping the old desktop site which will be the last to get that underpinning.
      - dsacco 9y ago
        Yes, whenever I'm looking for a source to crawl I prefer mobile applications for precisely this reason. Request signing and certificate pinning are an upfront annoyance, but the maintainability is far higher.
  - IgorPartola 9y ago
    And why is that a good thing for them? I mean if they provided an API to get their pricing, wouldn't it be in their interest? Does anyone buy airline tickets from the airline website ever? I don't. I use sites like Expedia and Priceline. And if an airline is not listed or has shitty prices, I don't buy it. Wouldn't it be in their interest to be listed on there? Moreover, wouldn't they want the other companies to have similar API's to have dynamic pricing? I get that at one point not having this info out there was a good thing for them. But now the car is out of the bag. You can't keep pretending that booking sites don't exist.
- jalfresi 9y ago
  There exists an entire industry that provide rotating IPs across fleets of proxies for very cheap prices. Proxy services like this make it pretty much impossible to prevent scraping.
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
- jalfresi 9y ago
  There exists an entire industry that provide rotating IPs across fleets of proxies for very cheap prices. Proxy services like this make it pretty much impossible to prevent scraping.
skinnymuch 9y ago
I'm thinking OP meant if you want to never be detected, but like you said, you usually never get detected anyway. Bypassing captcha automatically or with captcha bypass services where you pay per captcha completion?
pebers 9y ago
It's not terribly hard using Selenium; you can use one of their Docker images (e.g. selenium/standalone-chrome) and connect to that using Webdriver. Having said that, it has flaws compared to headless Chrome (more moving parts, terrible security, extra memory usage / dependencies for the JVM to run Selenium) so unless that camouflage is proving crucial, I'd avoid it where possible. I've recently migrated a project to headless Chrome and definitely prefer it.
- taeric 9y ago
  I'm curious on what makes the security worse. The rest, I can see. Though, I have to confess I have been more critical of the whole headless browser binary push than I'd care to acknowledge. I just feel like this is solving a problem that didn't actually exist anymore. Selenium has worked solidly for quite a while. And, you almost certainly should test in multiple browsers/scenarios.
  - pebers 9y ago
    The main security issues I know of so far are: - Neither Selenium nor Webdriver (at least the Python client, but I assume others too) support HTTPS at all. - By default it opens browsers configured to accept any SSL certificate. I can see why that's useful for local testing, but it's a terrible choice to default to. - It logs way too much. Logs every keypress sent to it, including passwords. At least the latter two are fixable, but not trivially so, and better defaults with easy client-side options to opt into insecure mode would have been much better. The former is not fixable without patching both the client and server and in 2017 it's pretty poor to not even have an option for.
    - taeric 9y ago
      Odd, I'm pretty sure both of the first two are wrong. We used to have to make sure we had legit certs for selenium to work with https. That or configure the Firefox profile to have already accepted the self signed one. And, really, the first two points are clearly contradictory. I'm guessing I just misunderstand what you mean? Do you mean the communication between the driver? I'm curious why ssl would be important there? Should just be done locally and a standard ssh tunnel can help with any remote encryption you might want.
kuschku 9y ago
> and the only Captcha that can't be bypassed is Google's most recent version That can also be easily bypassed (I’ve done that, without actually planning to do so) if you can make your behaviour seem completely human. So if you have a bot that can browse in a way that seems statistically human you can actually get around that. You can still scrape the same datasets – you just need to keep instances of bots, with all cookies around, and have them browse in certain ways. Classify what category a site might likely belong to, put them into buckets of queues, and have bots pull from queues they’re likely to browse, or search for certain terms they’re likely to search for. In my case, this all happened by accidents – I had IRC bots for a few channels, each kept a perpetual session and would visit every site that was linked (to get the title) and would be able to search Google by scraping. One day I was accessing a bot remotely, and told it to access a page that was NoCaptcha protected (because the site wasn’t working on my home system), yet it passed the captchas perfectly fine. Tried a few more times, always worked. So I tried figuring out why it worked.
- _e 9y ago
  Were the irc bots able to render javascript or were the bots using a cli lib like python requests? I thought that a client which doesnt run javascript would be a huge red flag.
  - kuschku 9y ago
    They used Firefox with off-screen rendering, as otherwise they wouldn’t be able to get the title of many pages – even many blogspot blogs can’t be read without JS anymore.

by dsacco 9y ago

heipei 9y ago

If you know how to interface with Chrome headless then you're 95% there already. Just run xvfb, start a Chrome instance on the DISPLAY with the appropriate flags (for exposing the debugging port) and you're done.

IgorPartola 9y ago

IP detection, especially IPv4, should still work fine because the cost to get a new IP will often outweigh the benefit of the scraping. Having said that, just let them scrape?

heipei 9y ago
There are multiple ways to hide your IP for free: Public proxies, VPNs which are not so well-known, and lastly there is a wealth of browser extensions which aim at hiding your IP to some extent. This would be one example where your traffic will exit with actual users on consumer ISP lines: http://hola.org/ http://hola.org/
- ant6n 9y ago
  What about tor.
  - heipei 9y ago
    TOR is an easy one to detect. Case in point: Try to browse the web with TOR and see how many CloudFlare captchas you have to solve in the first 10 minutes ;) Also TOR has public lists of exit nodes (https://torstatus.blutmagie.de/ https://torstatus.blutmagie.de/), and unless you exit via a non-listed one you're trivially identifiable. Lastly, TOR is rather slow, which prohibits using for large-scale scraping tasks. Plus you get switched around different exits and countries, which might break your scraping logic.
    - crtasm 9y ago
      I believe you could use the ExitNodes option to only use a specific exit. There's no such thing as an unlisted exit node, only unlisted entry nodes (bridges). I agree that Tor isn't a good choice for scraping.
  - dsacco 9y ago
    Tor would introduce pretty intolerable latency into a professional data crawling setup.
- ficklepickle 9y ago
  I'd say don't use Hola. They've had some issues, like selling their users bandwidth for botnets[1]. If you do some googling, you will see many reasons not to use that extension. [1]http://www.theverge.com/2015/5/29/8685251/hola-vpn-botnet-selling-users-bandwidth http://www.theverge.com/2015/5/29/8685251/hola-vpn-botnet-se...
tyingq 9y ago
>Having said that, just let them scrape? Depends on who you are. Hotel and airline websites, for example, are pummeled with scrapers wanting pricing and availability info. Letting them scrape with no limits is costly.
- dsacco 9y ago
  > Hotel and airline websites, for example, are pummeled with scrapers wanting pricing and availability info. Yes, and they make it very cumbersome to discourage it. I've successfully written scrapers for airlines. It's significantly more difficult than crawling other websites for a few reasons: 1. Session management is wacky - they really like to manage state entirely through cookies, and you typically need to visit a specific set of pages in a specific sequence before you can access the resources you want, like the number of seats available or their prices. 2. Sessions have time limits because anyone who looks at the seats initiates a "soft" reservation on them (this works in a similar way for theatre, concert and movie seating). 3. You don't usually have nice JSON endpoints, so you'll be doing a lot of HTML parsing (which, given the type of HTML you encounter, can be hell).
  - tyingq 9y ago
    >You don't usually have nice JSON endpoints, so you'll be doing a lot of HTML parsing That is changing. Most scrapers haven't caught on, but the more modern things airlines are pushing out (their mobile sites and native mobile apps) often have really nice REST/JSON api interfaces. The scrapers are often still scraping the old desktop site which will be the last to get that underpinning.
    - dsacco 9y ago
      Yes, whenever I'm looking for a source to crawl I prefer mobile applications for precisely this reason. Request signing and certificate pinning are an upfront annoyance, but the maintainability is far higher.
- IgorPartola 9y ago
  And why is that a good thing for them? I mean if they provided an API to get their pricing, wouldn't it be in their interest? Does anyone buy airline tickets from the airline website ever? I don't. I use sites like Expedia and Priceline. And if an airline is not listed or has shitty prices, I don't buy it. Wouldn't it be in their interest to be listed on there? Moreover, wouldn't they want the other companies to have similar API's to have dynamic pricing? I get that at one point not having this info out there was a good thing for them. But now the car is out of the bag. You can't keep pretending that booking sites don't exist.
jalfresi 9y ago
There exists an entire industry that provide rotating IPs across fleets of proxies for very cheap prices. Proxy services like this make it pretty much impossible to prevent scraping.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
jalfresi 9y ago
There exists an entire industry that provide rotating IPs across fleets of proxies for very cheap prices. Proxy services like this make it pretty much impossible to prevent scraping.

skinnymuch 9y ago

I'm thinking OP meant if you want to never be detected, but like you said, you usually never get detected anyway. Bypassing captcha automatically or with captcha bypass services where you pay per captcha completion?

pebers 9y ago

It's not terribly hard using Selenium; you can use one of their Docker images (e.g. selenium/standalone-chrome) and connect to that using Webdriver. Having said that, it has flaws compared to headless Chrome (more moving parts, terrible security, extra memory usage / dependencies for the JVM to run Selenium) so unless that camouflage is proving crucial, I'd avoid it where possible. I've recently migrated a project to headless Chrome and definitely prefer it.

taeric 9y ago
I'm curious on what makes the security worse. The rest, I can see. Though, I have to confess I have been more critical of the whole headless browser binary push than I'd care to acknowledge. I just feel like this is solving a problem that didn't actually exist anymore. Selenium has worked solidly for quite a while. And, you almost certainly should test in multiple browsers/scenarios.
- pebers 9y ago
  The main security issues I know of so far are: - Neither Selenium nor Webdriver (at least the Python client, but I assume others too) support HTTPS at all. - By default it opens browsers configured to accept any SSL certificate. I can see why that's useful for local testing, but it's a terrible choice to default to. - It logs way too much. Logs every keypress sent to it, including passwords. At least the latter two are fixable, but not trivially so, and better defaults with easy client-side options to opt into insecure mode would have been much better. The former is not fixable without patching both the client and server and in 2017 it's pretty poor to not even have an option for.
  - taeric 9y ago
    Odd, I'm pretty sure both of the first two are wrong. We used to have to make sure we had legit certs for selenium to work with https. That or configure the Firefox profile to have already accepted the self signed one. And, really, the first two points are clearly contradictory. I'm guessing I just misunderstand what you mean? Do you mean the communication between the driver? I'm curious why ssl would be important there? Should just be done locally and a standard ssh tunnel can help with any remote encryption you might want.

kuschku 9y ago

> and the only Captcha that can't be bypassed is Google's most recent version That can also be easily bypassed (I’ve done that, without actually planning to do so) if you can make your behaviour seem completely human. So if you have a bot that can browse in a way that seems statistically human you can actually get around that. You can still scrape the same datasets – you just need to keep instances of bots, with all cookies around, and have them browse in certain ways. Classify what category a site might likely belong to, put them into buckets of queues, and have bots pull from queues they’re likely to browse, or search for certain terms they’re likely to search for. In my case, this all happened by accidents – I had IRC bots for a few channels, each kept a perpetual session and would visit every site that was linked (to get the title) and would be able to search Google by scraping. One day I was accessing a bot remotely, and told it to access a page that was NoCaptcha protected (because the site wasn’t working on my home system), yet it passed the captchas perfectly fine. Tried a few more times, always worked. So I tried figuring out why it worked.

_e 9y ago
Were the irc bots able to render javascript or were the bots using a cli lib like python requests? I thought that a client which doesnt run javascript would be a huge red flag.
- kuschku 9y ago
  They used Firefox with off-screen rendering, as otherwise they wouldn’t be able to get the title of many pages – even many blogspot blogs can’t be read without JS anymore.