I feel like the solution is a better common crawl. As nice as it would be to block the frontier AI labs from getting access to information, we should reset the baseline of information accessibility so there's less marginal advantage on these labs. I worry a lot of the anti scraping rhetoric will just injure the open web and put somebody like cloudflare in charge.
Ironically in early 2023 a lot of websites went out of their way to block Common Crawl. Unsurprisingly that shifted scraping toward individual actors whereas the previous solution in research was to download CC dumps and process them.
An update on residential proxies and the scraper situation
131–140 of 422 posts
Re: An update on residential proxies and the scraper situation
#132Earlier quoted context omitted.
For one datapoint ... I have a custom HN CSS which includes some formatting of different sets of user accounts. Admins, for example, get orange highlighting and a dragon emoji (for one does not meddle in the affairs of ...). Also included are leaders, which is the one part of my CSS build script which is, or at least was until a few minutes ago, dynamic. Presently HN is returning "sorry" to my curl request. Given tha…
HN is exported to firebase, which you can hit directly, for that sort of purpose https://github.com/HackerNews/API
... it's starting to make sense, but ...
... the API is geared at requesting specific content items (posts, comments, users). There doesn't seem to be a way to directly make a request for a front-page history page (that is, the 30 items archived on a given date. Say, 2008-11-05:
https://news.ycombinator.com/front?day=2008-11-05>
It's the collection of 30 items from that date I'm interested in. For my scraping, I don't actually need to further query the individual posts as I've got the elements I'm interested in (title, date, story position, URL, votes, comment count, submitter, site/domain) from the index page itself, parsed out of the HTML. The "Past" entries alone are a significant (though not huge) request load. To update the past three years would be about another 1,000 requests, which, if fulfilled and modestly rate-limited would hopefully not keel the servers over.
Once I've pulled in those "Past" pages, I could of course do further API queries, though at this point I don't see any specific need to do so.
I suppose that requesting the "past" links be included in the API set could be a request I might make of HN, or the ability to request, say, all submissions (or comments!) for a given date.
There are groups which have done HN analytics in the past using the API, for example Whaly.io:
"A Year on Hacker News" https://news.ycombinator.com/item?id=31295219>
"Top Hacker News commenters of 2021" https://news.ycombinator.com/item?id=29778994>
"What Happened This Year on Hacker News (2021)" https://news.ycombinator.com/item?id=29769470>
I could look more into their methodology to see if I can use similar approaches.
The existence of "dead" and "deleted" values does seem interesting. I might do some playing with those to see what shows up (I suspect that most additional information is suppressed...)
OK, looking at a recent dead atomic128 comment:
$ curl -s 'https://hacker-news.firebaseio.com/v0/item/48820709.json?print=pretty'
{
"by" : "atomic128",
"dead" : true,
"id" : 48820709,
"parent" : 48819517,
"text" : "[flagged]",
"time" : 1783444517,
"type" : "comment"
}
So userID is visible.And from a current dead submission in the New queue:
$ curl -s 'https://hacker-news.firebaseio.com/v0/item/48868688.json?print=pretty'
{
"by" : "millwright-sw",
"dead" : true,
"id" : 48868688,
"score" : 1,
"time" : 1783743361,
"type" : "story"
}
That's missing the title and URL, as I suspected it would, though the submitter UID is available.To get top stories by date I'd actually have to submit more requests, walking through item numbers, splitting out comments and stories. Based on Whaly's 2021 retrospective, with about 4.2 million items (stories + comments) posted in total, that's about 12,000 items per day. Versus, well, one "Past" page result...
Re: An update on residential proxies and the scraper situation
#133Earlier quoted context omitted.
I know that. I've not worked with the API, and there's the blessing/curse (blurse‽) that HTML is a known, if poor, standard. API always translates to "one more thing to learn, that's applicable to a single-use case". HTML scraping / sorting I can apply across multiple sites. That said, a standard, say, JSON packaging of website contents available on request might be fun to have.
I feel less bad hammering firebase in a "while True:" loop vs hitting HN's servers.
Re: An update on residential proxies and the scraper situation
#134Earlier quoted context omitted.
> forced lowercase ??? shift is an extra key to press
https://www.businessinsider.com/lowercase-typing-altman-dors... most shibboleths are subtle like that
Re: An update on residential proxies and the scraper situation
#135Earlier quoted context omitted.
Ive been seeing a 'sorry' message occasionally when accessing older pages. Is that a side effect of whatever you are doing?
It was, but there were too many legit users getting affected, so we turned most of that off a few days ago. Are you still seeing it?
Re: An update on residential proxies and the scraper situation
#136I feel like the solution is a better common crawl. As nice as it would be to block the frontier AI labs from getting access to information, we should reset the baseline of information accessibility so there's less marginal advantage on these labs. I worry a lot of the anti scraping rhetoric will just injure the open web and put somebody like cloudflare in charge.
I'm sure there are those who would participate, either because they want their data to be captured by AI labs or as a form of compromise. That said, the approach is flawed. It looks like the people doing the scraping want everything. There are some people who do not want their data to be captured by LLMs. A common crawl would make it easier to those people to opt out, limit what is captured, or to poison the data. (I…
Re: An update on residential proxies and the scraper situation
#137> ...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…
The scraper wars are largely between script kiddies and people with both deep intimate networking and DOM knowledge. Yes greyhairs, I’m looking at you.
The problem is, you can’t PoW every page load and resource request because the user experience will suck and people will run away. And that window - the gap between what people will tolerate vs draconian enforcement - is exactly what the scrapers exploit.
And looking at the PoW options out there - I’ve seen at least one PoW WAF (honestly can’t remember if azure or amazon) have their PoW boil down to repeated trigonometric functions, ie very optimisable.
It’s a neat concept, but the answer and future to my eyes look bleak.
Re: An update on residential proxies and the scraper situation
#138Earlier quoted context omitted.
I don't think PoW scales, because if the bot authors get serious they'll start using native implementations that are much more efficient than the web ones real users are running. In theory maybe Anubis could start using WebGPU to help close that gap, but then anyone without WebGPU support is out of luck. Then again, a large portion of the problem seems to be bots making way too many requests and in general not being…
There are PoW approaches that even the playing field between data centers and desktops. RandomX is my favorite.
Re: An update on residential proxies and the scraper situation
#139Earlier quoted context omitted.
Very little of it. When you see a million IPs systematically working their way through your URL space, it's pretty clear that there's a central control node behind it all.
Your earlier article suggests you aren't using a CDN. Might be well worth looking into - not for any bot detection so much as just having a good old fashioned cache in front of you.
Re: An update on residential proxies and the scraper situation
#140Earlier quoted context omitted.
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.
As someone dealing with similar on a large site, I'd love to see a private community to discuss some of these issues.