Ideas: - Make it generate cryptucurrency, so that the work is not wasted. Either to compensate for server expences hosting the content, or for some noble non-profit cause - all installations would collect the currency to a single account. Wasting the work is worse than these both options. - An easy way for good crawlers (like internet archive) to authenticate themselves. E.g. TLS client side authentication or simply…
> Make it generate cryptucurrency, so that the work is not wasted. Either to compensate for server expences hosting the content, or for some noble non-profit cause - all installations would collect the currency to a single account. Wasting the work is worse than these both options. The last time[0] we did this, everyone had a meltdown and blocked it. [0] See Coinhive, which conspicuously lacks a Wikipedia page.
Anubis: Proof-of-work proxy to prevent AI crawlers
61–68 of 68 posts
Re: Anubis: Proof-of-work proxy to prevent AI crawlers
#62I would say it doesn't prevent anything, it just makes computers warm the planet more.
A quick PoW calculation per web session is probably not going to make a dent in pollution now that generative AI has become commonplace. It'll suck for battery life if you're often browsing random website after random website, or if you're a bot farm, but in practice I don't think most welcome users will notice a thing.
Re: Anubis: Proof-of-work proxy to prevent AI crawlers
#63Earlier quoted context omitted.
You glossed over how it works. Bots don't maintain session cookies to avoid rate limits, so they will have to do the challenge over and over again, whereas humans keep the session cookie and amortise the cost of the challenge over multiple requests.
You're right, Anubis sets a week-long cookie: > exp: The token's expiry week after the token was issued This is surprising to me because it effectively nullifies Anubis. > Bots don't maintain session cookies to avoid rate limits Maybe they don't today, but there's absolutely nothing stopping them adding this, so if Anubis gets any traction, in two days' time they will.
Maybe suckerpinch can work it into a sequel to Harder Drive: Hard drives we didn't want or need[0].
Re: Anubis: Proof-of-work proxy to prevent AI crawlers
#64Ideas: - Make it generate cryptucurrency, so that the work is not wasted. Either to compensate for server expences hosting the content, or for some noble non-profit cause - all installations would collect the currency to a single account. Wasting the work is worse than these both options. - An easy way for good crawlers (like internet archive) to authenticate themselves. E.g. TLS client side authentication or simply…
> Make it generate cryptucurrency, so that the work is not wasted. Either to compensate for server expences hosting the content, or for some noble non-profit cause - all installations would collect the currency to a single account. Wasting the work is worse than these both options. The last time[0] we did this, everyone had a meltdown and blocked it. [0] See Coinhive, which conspicuously lacks a Wikipedia page.
Re: Anubis: Proof-of-work proxy to prevent AI crawlers
#65Earlier quoted context omitted.
FWIW, I was part of the gang talking with Adam about using Hashcash as a postage stamp as an anti-spam measure. I implemented an extension to Postfix using Hashcash as an anti-spam method (camram/two penny blue). The compute inflationary pressure you mentioned was only one of the challenges in deploying such a system. FWIW, none of the challenges were barriers; they were the kind of challenges you get when you take s…
> I think Anubis is a good first start, but the fact that it uses a fixed size stamp, a small one, does not have a reputation database, and from what I can tell, does not have a robust detector of good versus bad players. These shortcomings will make it challenging to provide adequate protection without interfering with good players. That's what it's intended to be right now. I've been thinking out how to do a reputa…
IMO, of course.
Re: Anubis: Proof-of-work proxy to prevent AI crawlers
#66Earlier quoted context omitted.
You're right, Anubis sets a week-long cookie: > exp: The token's expiry week after the token was issued This is surprising to me because it effectively nullifies Anubis. > Bots don't maintain session cookies to avoid rate limits Maybe they don't today, but there's absolutely nothing stopping them adding this, so if Anubis gets any traction, in two days' time they will.
You can turn Anubis into Proof of Storage by appending large amounts of random data to the session cookie and then hashing it on each request. Combined with per-session-cookie limits, you can effectively force the LLM bots to store all the data you want if they want to scrape your site. Maybe suckerpinch can work it into a sequel to Harder Drive: Hard drives we didn't want or need [0]. [0] https://www.youtube.com/wat…
Slightly more seriously though, I think for the Proof of Storage idea to pack enough punch to be a deterrent, you'd need the cookies to be quite large. Is there a way to avoid needing them to send you all the bytes each time? Because that will cost you (the site owner) too.
I had the idea of sending requestors a challenge like "Flip the bit at position i of the large chunk of stored data, hash the result and include the hash in your headers". Instead of the site owner keeping the full stored data, they would just keep the RNG seed used to generate it -- this saves on storage, though it still requires them to do the same time-consuming hash computation done by the requestor.
Re: Anubis: Proof-of-work proxy to prevent AI crawlers
#67Is there a way to alter text to poison AI training sets? I know there's Glaze and Nightshade for images but I've heard of nothing to poison text models. To be clear, this wouldn't be a defensive measure to stop scraping; it'd be an offensive honeypot: you'd want to make pages that have the same text but mutated slightly differently each time, so that AI scrapers preferentially load up on your statistically different…
Re: Anubis: Proof-of-work proxy to prevent AI crawlers
#68Earlier quoted context omitted.
You glossed over how it works. Bots don't maintain session cookies to avoid rate limits, so they will have to do the challenge over and over again, whereas humans keep the session cookie and amortise the cost of the challenge over multiple requests.
You're right, Anubis sets a week-long cookie: > exp: The token's expiry week after the token was issued This is surprising to me because it effectively nullifies Anubis. > Bots don't maintain session cookies to avoid rate limits Maybe they don't today, but there's absolutely nothing stopping them adding this, so if Anubis gets any traction, in two days' time they will.
All of these factors (total requests, rate of requests, associated IPs, associated browser fingerprints) tie in to detecting bad players, who should receive more frequent and larger challenges.