The article at the end talks about how is very easy for arbitrary apps from app stores can install a residential proxy on your phone. 10 years ago, apps had to explicitly state if they needed network access. And then the powers that be decided that really all apps need network access no matter what. And both ios and android make it hard to deny apps network access. But really, this finally explains the hordes of real…
An update on residential proxies and the scraper situation
281–290 of 422 posts
Re: An update on residential proxies and the scraper situation
#282> ...we have tried to minimize the impact on real readers as much as possible. We have not gone with tools like Anubis, partly because it causes annoying delays for those trying to get to the site, but also partly because it seems inevitable that the scrapers will eventually find their way around it. Indeed, there are some indications that is already happening. A proof-of-work requirement is not a huge obstacle when…
PoW can theoretically scale effectively infinite because it can mine cryptocurrency. Millions of compromised IoT devices hitting your server? Now you have enough money for a faster server. It doesn’t matter that the challenge must be verified: present multiple challenges, some are verified while others mine crypto.
Re: An update on residential proxies and the scraper situation
#283Earlier quoted context omitted.
If Google determines you're an undesirable user, doing the captcha is just an exercise to waste your time.
That explains why I can never get past Google's captchas! I don't even automate Google searches, I wonder why they don't like me.
Google also prefers if you have a Google account logged in.
Re: An update on residential proxies and the scraper situation
#284Earlier quoted context omitted.
Proof of work does not scale. It trades something fungible and incredibly cheap (CPU) for something incredibly expensive (user-visible latency). There is no set of parameters where the cost is going to be a meaningful deterrent to any kind of abuse (even something as low-yield as scraping) without adding crippling amounts of latency to real users. > The dilemma for bots: when tokens are bound to the connecting ip, sc…
> It trades something fungible and incredibly cheap (CPU) it could be RAM-bound, which is very much NOT cheap nowadays :)
Re: An update on residential proxies and the scraper situation
#285Residential Proxies are the most emblematic technology of our era- a group of people looked at something that used to be considered a crime (botnets) and realized that if they just did it openly, no one would ever punish them.
And it's made necessary because another group of people thought that selling IP blocking services would be a good idea. One party sells walls, another party sells ladders. Well, one party gives away free walls if you agree to fill your castle with surveillance cameras you don't control.
Re: An update on residential proxies and the scraper situation
#286Earlier quoted context omitted.
I looked this up and realised it’s the page I’d seen briefly on a range of websites lately. It’s not annoyed me at all. Not nearly as much as having to complete captchas with slow refreshing tiles.
A fun fact about Google captchas: they've often decided whether you will succeed or fail the captcha before you do the captcha.
Re: An update on residential proxies and the scraper situation
#287Earlier quoted context omitted.
HN is surprisingly very very guilty of a whole lot of anti-user patterns and behaviour that other companies get regularly lamented. Poor accessibility, bad mobile support, no options to delete content beyond a narrow window.
bad mobile support Good.
Re: An update on residential proxies and the scraper situation
#288Earlier quoted context omitted.
How does HN fare with scraper load? Is it just CDN and pay the extra bandwidth bill for anon hit requests?
It's really bad. I found myself identifying with everything Jonathan wrote in the OP - so much so that I thought of asking to compare notes on mitigation measures.
Grub was, in a very real way, a botnet. And, we harmed site owners when we were operating at full capacity. There were a few bugs in the early days where we would reschedule a site because the ingestion in the server broke, which then caused the page to be rescheduled. Stupid error, and we fixed it, but it's illustrative of the fact even good intentions isn't enough here.
What I've come up with over the years is similar to the idea Cloudflare is implementing with payments to site owners by charging the crawlers. My objection to Cloudflare's implementation is based on a personal opinion about Cloudflare being a single point of failure and also a decrypted choke point. Their ideas about how to handle crawlers, and pay for the load on the sites is solid. It presumes to use the 402 response to demand payment. I'm clearly biased about Cloudflare, but that's my prerogative here.
It may be possible to solve this with cryptocurrency, in a distributed way, and I've prototyped a system that uses the Lightning Network to handle the payments from a 402 response. Lightning Labs also worked on a project called Apeture for a time that did something similar.
HN's site knows every item ID, and it knows fresh IDs get read in a predictable distribution while old ones mostly sleep. Sustained access outside that is itself the scraper signal. No IP reputation needed, which matters now that residential proxies burn an address after a handful of requests.
Karma gives you a clean way to let humans through. Issue logged-in accounts with decent karma a token whose cold-content budget scales with it (the karma), so an account with history scrolling back through a 2014 thread just reads it. Karma should gate the tier, not be spent as currency, or upvote rings become a crawling business.
Anonymous readers who deep link into one old thread from a search engine get the first fetch or two free (and you watch the article IDs, not the IPs). What remains after those carve-outs is bulk traversal of cold IDs with no identity attached, and that traffic gets rate limited and answered with a 402: pay per page over Lightning, priced at a healthy multiple of what residential proxy bandwidth already costs, or come back slowly for free.
There are probably holes in these thoughts. It's one of the harder problems to solve, for sure.
Re: An update on residential proxies and the scraper situation
#289Re: An update on residential proxies and the scraper situation
#290Earlier quoted context omitted.
Proof of work does not scale. It trades something fungible and incredibly cheap (CPU) for something incredibly expensive (user-visible latency). There is no set of parameters where the cost is going to be a meaningful deterrent to any kind of abuse (even something as low-yield as scraping) without adding crippling amounts of latency to real users. > The dilemma for bots: when tokens are bound to the connecting ip, sc…
> It trades something fungible and incredibly cheap (CPU) it could be RAM-bound, which is very much NOT cheap nowadays :)
100MB for 1 second just is not much of a deterrent.