[l] Als ich mich gerade mal wieder über ein Blog mit Captchas geärgert habe, fiel mir auf, daß heutige Browser dank Javascript ja eigentlich perfekt für Verfahren wie HashCash einsetzbar wären. Wieso implementiert niemand sowas? Nehmen wir an, jemand will bei mir einen Kommentar submitten. Ich schreibe als POST-URL der Form http://teergrube-fuer-fiese-spammer.fefe.de/ ins HTML, und überschreibe das dann mit Javascript. Beim Laden der Seite startet ein Javascript, der dann die Aufgabe kriegt, für den MD5-Hash e807f1fcf82d132f9bb018ca6738a19f einen String zu finden, der diesen Hash hat. Das wird er durch Ausprobieren tun müssen, und der Server kann den zu findenden String von der Länge her so wählen, daß das Javascript eine Minute dafür braucht auf einem aktuellen PC. Der gefundene String wird dann als Teil der URL übergeben, d.h. wenn der String gefunden ist, erzeugt das Javascript als POST-URL http://kommentare.fefe.de/post/1234567890 (1234567890 hat den obigen Hash). Der Server muss dann gucken, ob MD5 von dem übergebenen String dem gestellten Hash entspricht. MD5 ist hier nur ein Beispiel fürs Verständnis, eigentlich will man kein MD5 sondern eine in Javascript besonders effizient ausführbare Funktion, damit ein Spammer, der das in C nach implementiert, nicht substanziell schneller ist. Die Idee dabei ist, daß es für Spammer teuer gemacht wird, da ihren Spam abzuladen. Mehrere Fragen stellen sich: reicht eine für User erträgliche Wartezeit, um das für Spammer teuer genug zu machen? Wie stellt man das Problem so, daß der Server stateless das Problem rekonstruieren kann, das er dem Client gestellt hat, ohne da auf eine Datenbank zugreifen zu müssen?