Could you give an example of an article that was protected for reasons other than preventing vandalism? I've seen other people bring this up, but never with evidence.
You're entitled to no protection, nor are we entitled to you providing an example. But if you don't want to provide an example, your claim immediately turns to dust. This is just the fundamental core of rationalism.
The sky is green. I won't be taking any questions.
(actually the sky really was green a few days ago, related to tornado weather!)
> But if you don't want to provide an example, your claim immediately turns to dust.
That's not how it works in reality. If people disagree with the example it's dust anyway, except now you also wasted your time.
My opinion is irrelevant here since if people have made up their minds that WIkipedia is not biased and takes sides, then no example will suffice and they simple ask for an example just to have a target to shoot at.
I've been on this rodeo before. There's no guarantee of a good faith argument when politics are involved. I have no guarantee I'm not dealing with people arguing in bad faith trying to bait for a flame war, so I'd rather not even start to save time and sanity.
If you think it's dust, then so be it, I don't mind, I don't lose anything from this, nor do I gain anything from trying to convince you I'm right. I have my opinion, you have yours and we can leave it at that.
I'm very surprised Google put in so much effort to implement an approach that is basically the equivalent of client-side verification of passwords. Did no one designing it mention that it could be defeated by any rooted device?
Actually I think this approach is very forward looking! Attestation is on the cusp of becoming a very powerful technique. We just need to figure out how to build 100% bug-free and 100% secure hardware and software, and then it's gonna work great.
Well, all one has to do is look at the bigger picture of how rooted devices are being shuffled into 3rd rate/totally blocked experiences and the overall direction of things starts to take very clear shape.
Someone better figure out how to make computing devices at home from everyday parts because the only way I see this (shockingly rapid) arms race end is legally mandated, cryptographically locked down hardware and software (or even thin clients) everywhere.
RMS must be having daily nightmares at this point.
Didn't Daniel later report that curl recently started getting mostly high-quality LLM reports on their bounty program? I can imagine that there would definitely be a few "bounty spammers" trying to get hits, but it seems like most of them are doing good work.
I'd say instead that the problem is that a lot of people don't care anymore about the quality of the work being done, and LLMs are accelerating it. Bounty programs have shifted from ways for people to report security bugs to ways for people to try to make money.
> Unfortunately, the price LLM companies would have to pay to scrape every single Anubis deployment out there is approximately $0.00.
The math on the site linked here as a source for this claim is incorrect. The author of that site assumes that scrapers will keep track of the access tokens for a week, but most internet-wide scrapers don't do so. The whole purpose of Anubis is to be expensive for bots that repeatedly request the same site multiple times a second.
The "cost" of executing the JavaScript proof of work is fairly irrelevant, the whole concept just doesn't make sense with a pessimistic inspection. Anubis requires the users to do an irrelevant amount of sha256 hashes in slow javascript, where a scraper can do it much faster in native code; simply game over. It's the same reason we don't use hashcash for email, the amount of proof of work a user will tolerate is much lower than the amount a professional can apply. If this tool provides any benefit, it's due to it being obscure and non standard.
When reviewing it I noticed that the author carried the common misunderstanding that "difficulty" in proof of work is simply the number of leading zero bytes in a hash, which limits the granularity to powers of two. I realize that some of this is the cost of working in JavaScript, but the hottest code path seems to be written extremely inefficiently.
for (; ;) {
const hashBuffer = await calculateSHA256(data + nonce);
const hashArray = new Uint8Array(hashBuffer);
let isValid = true;
for (let i = 0; i < requiredZeroBytes; i++) {
if (hashArray[i] !== 0) {
isValid = false;
break;
}
}
It wouldn’t be exaggerating to say that a native implementation of this with even a hair of optimization could reduce the “proof of work” to being less time intensive than the ssl handshake.
That is not a productive way of thinking about it, because it will lead you to the conclusion that all you need is a smarter proof of work algorithm. One that's GPU-resistant, ASIC-resistant, and native code resistant. That's not the case.
Proof of work can't function as a counter-abuse challenge even if you assume that the attackers have no advantage over the legitimate users (e.g. both are running exactly the same JS implementation of the challenge). The economics just can't work. The core problem is that the attackers pay in CPU time, which is fungible and incredibly cheap, while the real users pay in user-observable latency which is hellishly expensive.
They do use SubtleCrypto digest [0] in secure contexts, which does the hashing natively.
Specifically for Firefox [1] they switch to the JavaScript fallback because that's actually faster [2] (because of overhead probably):
> One of the biggest sources of lag in Firefox has been eliminated: the use of WebCrypto. Now whenever Anubis detects the client is using Firefox (or Pale Moon), it will swap over to a pure-JS implementation of SHA-256 for speed.
Right, but that's the point. It's not that the idea is bad. It's that PoW is the wrong fit for it. Internet-wide scrapers don't keep state? Ok, then force clients to do something that requires keeping state. You don't need to grind SHA2 puzzles to do that; you don't need to grind anything at all.
The parent comment was "The author of that site assumes that scrapers will keep track of the access tokens for a week, but most internet-wide scrapers don't do so.". There's no technical reason why they wouldn't reuse those tokens, they don't do that today because they don't care. If anubis gets enough adoption to cause meaningful inconvenience, the scrapers would just start caching the tokens to amortize the cost.
The point of the article is that if the scraper is sufficiently motivated, Anubis is not going to do much anyway, and if the scraper doesn't care, same result can be achieved without annoying your actual users.
They could, but if this is slightly different from site to site, they’ll have to either do this for every site (annoying but possible if your site is important enough), or go ahead and run JS (which... I thought they do already, with plenty of sites still being SPAs?)
That's not what the author says- they said that file managers actually are somehow sorting file-9.txt before file-10.txt, and it's breaking real alphabetical ordering.
https://arstechnica.com/tech-policy/2026/02/wikipedia-might-...
https://en.wikipedia.org/wiki/Wikipedia:Archive.today_guidan...?
Besides tampering with content, the site was also using visitors to DDOS a blog that mentioned the owner of archive.today.