>>164826>Hat Anubis kein Gedächtnis?
Klassischerweise sind PoW-Systeme zustandslos, damit der Servierer keine Tabelle mit einem Eintrag für jeden Klienten vorhalten muss. Soweit Felix weiß, gilt das auch für Anubis.
Felix hat jedoch, nachdem Felix sein eigenen PoW-System gebaut hat (genauer: Es versauert zu 80 % fertig auf Felixens Festplatte) erhebliche technische Kritik an Anubis. Anubis benutzt JWT-Signaturen über einen Cookie, womit der Servierer bei jeder Klient-Anfrage eine HMAC-SHA256-Signatur berechnen muss (besteht aus 2x SHA256-Berechnungen zu je 64 Runden, plus noch etwas Gedönse).
Seitennotiz: Bei Anubis kann man die ersten paar Runden der ersten SHA256-Berechnung voroptimieren, weil der Anfang jedes Cookies immer gleich ist (Felix glaubt, die erste SHA256-Berechnung geht somit in 60 statt in 64 Runden).
Man kann stattdessen das ganze auch mit Berechnung einer einzigen SHA256-Prüfsumme (über einen String, welcher insbesondere auch die Ablaufzeit beinhaltet) implementieren, womit die Rechenlast für Anubis sich auf dem Servierer halbieren würde. Felix hält Anubis für etwas zu sehr auf Show getrimmt, mit guter PR, aber technisch nicht gut umgesetzt. Es war schlicht zum richtigen Zeitpunkt am richtigen Ort *einsetzbar* vorhanden, wobei das aktuell die zweite Iteration von Anubis ist (die erste Version benutzte, ironischerweise, ein KI-generiertes Bild von Anubis).
>Suddenly, the crawlers were coming from millions of random residential or mobile IPs, all pretending to be random modern browsers. An IP like that would make 4-5 requests and then never show up in the logs again. There was no point in banning them, because by the time you figured out that they were bots, they were already done with you. You just needlessly ballooned your firewall ruleset by adding IPs that would never be back.
Das ist das erste Mal für Felix, dass jemand Seriöses™ tatsächlich (nach den AWS/Azure/Google Cloud/OVH-Heinis) den Finger auf residentielle IP-Adressen richtet, ohne Anreize, die Cloud-Anbieter in Schutz zu nehmen. Wobei, wer waren nochmal Sponsor der Linux-Foundation...
>Today, git.kernel.org receives about 6M daily requests demanding to see random commits.
Hash-Tabelle wird also nicht allzu groß werden.
Bei 6 Mio. Anfragen pro Tag ist so eine Tabelle also durchaus drin. Doch dann kann man direkt statt PoW-Challenges schlicht einen Timer bauen, und jeder neue Klient muss warten, bis der Timer auf 0 runtergezählt hat, und dann kriegt der Klient z.B. 500 Seitenzugriffe. Ein Timer ergibt Sinn, denn ein Scraper kann durchaus mehr Hardware ranschaffen, um die PoW-Challenges schneller zu lösen, aber den Fortschritt der Zeit (auf dem Servierer) kann der so nicht beschleunigen.