Live data from Hacker News

An update on residential proxies and the scraper situation

lwn.net

281–290 of 422 posts

Re: An update on residential proxies and the scraper situation

#281

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…

GrapheneOS allows you to deny network access per app pretty trivially. Google Play services make it a bit more difficult because the app might marshall the network request through that; I'm not sure how to verify that behavior when it happens.

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.

This is called “installing a cryptominer on your web page” and is generally considered illegitimate.

Re: An update on residential proxies and the scraper situation

#283

Earlier 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.

Depending on the IP reputation as well as the kind of IP address you have, this can happen.

Google also prefers if you have a Google account logged in.

Re: An update on residential proxies and the scraper situation

#284
post #208

Earlier 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 :)

Yes, but the people with the RAM nowadays are the data centers, not the end users.

Re: An update on residential proxies and the scraper situation

#285
post #10

Residential 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.

[deleted]

Re: An update on residential proxies and the scraper situation

#286

Earlier 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.

I implemented something similar for my bot defences. If headless chrome is detected you still get the same anubis-style PoW but even if you submit the right answer you get rejected.

Re: An update on residential proxies and the scraper situation

#287
post #271

Earlier 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.

Why is that good?

Re: An update on residential proxies and the scraper situation

#288
post #69

Earlier 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.

I came up with the idea and helped build Grub, the distributed crawler. Looksmart bought it, ran it for a time, then sold it to Wikimedia. I reclaimed the name recently (abandoned mark) and have a new crawler now that is agentic. I use it for my own research runs, and it's not my main focus at this point, nor am I trying to get it attention. A lot of LLMs and coding agents can easily fetch content if it is needed and we're blind to how they do it. See the Claude plugin for Chrome as an example of using it in a user-in-the-loop solution. That said, I've been spending a little time thinking about how to bake the contract into the crawler, as opposed to expecting someone else to act ethically using it.

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

#289
Ever since bots became a problem on the internet 10-20 years ago, it has seemed like the common-sense solution is some kind of micropayment. Pay $0.01 to view the page. When money is on the line, scrapers are likely to be more well-behaved, even if they do pay. The problem is, and has always been, the friction of payment. How do you pay $0.01? The credit card processors will tack on a $6 surcharge. We need a trusted third-party that turn money into "internet article credits" that you can spend in small increments, like a video game. But I suspect that thousands of people have already though of this system, and tried it, but ran into some roadblock. I'm guessing there's some egregious regulation that makes micropayments impossible.

Re: An update on residential proxies and the scraper situation

#290
post #208

Earlier 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 :)

It doesn't make the economics any different. In a browser environment, you're maybe looking at the acceptable lease being 100MB for 1 second. Much more than that, and you start hitting limits of what browsers will let you do on low-end phones. Longer than that, and we're back to the user-observable latencies being too long.

100MB for 1 second just is not much of a deterrent.

Post reply on HN