Da gibt es in der c’t 9/08 wieder einen Beitrag über die verschiedenen Arten der Captchas, und wie sicher diese aus heutiger Sicht gegenüber der Spambots denn sind. Der Michel fragt sich nun warum wir dem User nicht einfach ein paar Optionen zur Auswahl geben. Netter Ansatz, aber immer noch eine Interaktion zuviel, und eine Chance von 1:4 das der Spam durchkommt.
Viel wird darüber diskutiert, welches Captcha nun für den Menschen noch lesbar, und für die Maschine nicht lesbar sind. Dabei könnte doch alles so einfach sein…
Maschinen sind dümmer als wir denken, und gerade hier ist es doch soooo einfach sich etwas zu überlegen das für den Menschen keine Hürde darstellt, für Maschinen aber schon. Ich habe ja bereits einmal auf die Idee hingewiesen, ein Formularfeld mittels CSS zu verstecken und später serverseitig zu überprüfen ob dort etwas eingetragen wurde. Da Spambots in der Regel jedes Feld ausfüllen das es in einem Formular gibt, kann man so recht einfach ausfiltern ob der Nutzer gerade Mensch oder Maschine ist.
Ich habe diese Technik in der Vergangenheit schon ein paar mal praktisch anwenden können und hatte damit bisher eine Erfolgsquote von 100%. Der große Vorteil ist hierbei natürlich, das keinerlei Interaktion vom Benutzer gefordert wird… für die Zugänglichkeit sollten wir natürlich noch einen ebenfalls auf gleiche Weise versteckten Text hinzufügen der darauf hinweist das das Feld doch nicht ausgefüllt werden sollte.
Natürlich wäre es bei großer Popularität dieser Technik für die Bots irgendwann auch kein Problem versteckte Felder zu ermitteln und auszulassen, doch davon sind wir aktuell noch Meilenweit entfernt, zumal es ja etliche Lösungsansätze dazu geben könnte.
Wen die zusätzliche Interaktion nicht weiter stört, der könnte es auch so machen wie der Peter, der seinen Besuchern einfach eine Frage stellt, die er selbst schon beantwortet. Für jeden mit einem IQ über dem einer Kaffeetasse machbar und ebenfalls schnell ausgefüllt. Bis Bots solch eine künstliche Intelligenz an den Tag legen um solche Fragen automatisiert zu erkennen und zu beantworten sollten wohl noch einige Jahre ins Land gehen.
Vielleicht sollten wir uns auch gar nicht alle nur auf eine Technik festlegen, sondern ein bisschen streuen, denn umso mehr populäre Ansätze es gibt, desto mehr Situationen muss ein Bot erkennen und bewältigen.
Also, vergesst bitte ein für alle mal eure Wischi-Waschi-Captchas mit 10 verschiedenen Schriftarten, Auswahlmöglichkeiten, Transparenzen oder 100 Farben, und überlegt euch einfach wie man die eigentlich doch sehr dummen Bots überlisten könnte.
Eure Serverperformance, Ladezeit und natürlich auch eure Besucher werden es euch und euren Kunden danken, versprochen!
Kommentare zum Thema Captchas - Und Nochmal...:
Patrick: War das automatisierter Spam oder sah es eher nach Handarbeit aus? Ansonsten kommt es denke ich darauf an wie man das Feld ausblendet, display: none; ist halt ne sehr offensichtliche Methode und zudem stehts bei dir auch noch Inline im Quelltext. Ich denke wenn du es mit negativer absoluter Positionierung oder einer anderen Technik zum Verstecken von Elementen machen würdest und das CSS dafür dann noch mit ins externe CSS packst sollte der automatisierte Spam bei 0 landen.
@Christian
Ja das war automatisierter Spam, aber wie schon gesagt hab’ ich das jetzt schon seit sicherlich nem 3/4 Jahr so und die 5 Spam-Kommentare, die ich bekommen hab’ wurden dann auch von Akismet erkannt.
Welche anderen Techniken zum Verstecken von Elementen gibt es denn noch?
Ich hab’ letztens auch was interessantes mit JavaScript gesehen, da wurde angenommen, dass wenn man JS deaktiviert hat, man vielleicht ein Bot sein koennte und daraufhin wurde so ein Captcha à la Peter dargestellt…
@Patrick
Schon wieder viiiiiel zu aufwendig, vorallem auch Blödsinn. Es gibt so viele User mit NoScript die offensichtlich auch kein JS haben. Zudem wäre die Wartbarkeit genauso bescheiden als würde man direkt alles mit Captcha machen :) Ausserdem ist auch fraglich wie lange es noch dauert bis Bots auch mit JS keine Probleme mehr haben.
Was man natürlich machen könnte wäre die Passage mit dem Inputfeld auch per JS direkt aus dem DOM zu löschen, wäre aber auch ziemlich unsauber. Ich würde dir eher zu folgendem Raten.
Mach ein DIV um deine zu versteckende Passage (oder irgendein anderes Element), dem Element verpasst du ne klasse und verpasst ihm folgendes CSS:
.meineKlasse{
overflow: hidden;
height: 0;
width: 0;
}
Ist noch eine relativ selten genutzt Technik zum verstecken von Inhalten und sollte daher auch kaum einem Bot bekannt sein, gerade wenn die Anweisung dann auch noch im externen CSS stehen, was ja eh kaum ein Bot durchsucht geschweige denn interpretiert.
Dass Captchas nicht das Ideal darstellen ist klar. Ich dachte mir nur, wenn schon Captcha dann wenigstens ein bisschen freundlicher und einfacher.
Seit Textpattern mach ich mir aber gar nicht mehr soviele Gedanken um Kommentar-Spam ;-)
Die “verstecktes Feld”-Methode gefällt mir auch.
Yupp, mit der Inputfeld-Technik fahre ich seit über einem Jahr komplett Sorgen und Spamfrei! (-;
Eigentlich sind (fast) alle genannten Methoden nutzlos, wenn ein Bot speziell für eine (weit verbreitete) Software programmiert wird.
Was haltet ihr denn davon den Inhalt des übertragenen Kommentars zu überprüfen? Beispielsweise die Links zu zählen, die Sprache des Kommentars zu ermitteln oder nach bestimmten Schlüsselwörtern zu suchen, die nichts mit dem Thema zu tun haben.
Das alles könnte man unterschiedlich gewichten und zusammen rechnen, was denke ich auch ein sicheres Ergebnis mit sich bringt. Was sagt ihr dazu?
@Richard Wenn ich mich recht erinnere dann macht doch Akismet und co. sowas in der Art, ein Ratingsystem das nach verschiedenen Faktoren + oder – rechnen und ab einem bestimmten sich für Spam entscheidet.
Aber auch das ist in seltenen Fällen fehleranfällig bzw. hat ne kleine false positive rate.
Das mit dem Inputfeld ist nicht so leicht zu verfolgen wie man meint. z.B. wenn das Inputfeld von Seite zu Seite einen anderen Namen, andere Beschreibung und evtl. auch andere Klasse trägt, so ist es für Bots wohl nur schwer zu vereinheitlichen.
Akismet find ich an sich ne gute Sache, nur will ich darauf hinweisen das es eigentlich viel simpler gehen könnte, zumindest aus der Administrationssicht. Und es muss ja nicht immer nur ein Blog sein. Bestellformulare oder Kontaktformulare können genauso betroffen sein.
Aber es lebe die Randgruppen Software, wie der Michel schon sagt, kann einem das z.B. bei Textpattern eh am Arsch vorbei gehen, da bleibt eh jeder Bot an der Vorschau hängen ;)
Das mit dem Wechseln der Namen macht genau Yawasp, ein neues Anti-Spam Plugin fuer Wordpress:
Also ich nutze größtenteils auch die “Feld verstecken”-Methode, von einer “neuen” Methode hab ich mal gehört: Zeit. Man misst einfach, wie lange der User braucht, um die Felder auszufüllen. Normalerweise braucht man doch 5 Sekunden bis sowas ausgefüllt ist. Weiteres Argument ist, dass die Bots sich nicht mehr großartig dafür interessieren, wenn sie warten müssen, dann wird das für sie uninteressant…
Es gab mal dazu ne interessante Folge auf gefangenimnetz.com, gibt’s jetzt leider nicht mehr :(
Wäre eine Möglichkeit, allerdings ist es natürlich bei großer verbreitung keine Schwierigkeit ein Delay in die Bots zu implementieren. Doch genau das ist es was ich meinte: Kombination.
Es gibt doch sicherlich noch 20 gute Ansätze, wichtig ist vielleicht einfach, das nicht jeder den gleichen Weg verfolgt, sondern Methoden kombiniert oder abwechselnd anwedendet. Wenn das ein Großteil der Entwickler machen, haben die Spambots so schnell keine Chance mehr.
Wie ist das bei Menschen mit Behinderungen?
Das Feld wird bei der Ausblendtechnik per CSS dennoch vorgelesen, auch wenn es kein “Label” hat. Das selbe mit bei der Zeitbegrenzungs-Variante: Nicht jeder Mensch mit motorischer Beeinträchtigung wird das Feld nicht in 5 Sekunden ausfüllen können.
@Sache Zum Inputfeld gehört natürlich ein umschreibender Text der erläutert das das Feld bitte frei gelassen werden sollte. Der gesamte Container, also label+input-feld wird dann ausgeblendet. Display:none; wird von vielen Screenreadern schon garnicht mehr beachtet, so das diese Besucher das Inputfeld auch “überlesen” würden. Wenn es doch erfasst wird, dann auch mit dem beschreibendem Text. Also bzgl. der zugänglichkeit sehe ich da keine Probleme.
Was die Zeitschaltung angeht, ist ne möglichkeit… im Zweifelsfall auch hier wieder mit einem umschreibendem Text die zeitliche Verzögerung angeben die zu beachten wäre. Allerdings denke ich das kaum jemand ein Formular in 2-3 Sekunden ausfüllt. Gerade in Blogs ließt man ja vorher noch immer einen Text oder neue Kommentare und antwortet dann nach dem lesen darauf, da sind 2-3 Sekunden wirklich keine Zeit.
Dann wäre es also doch eine Lösung mit zusätzlicher Interaktion. Genau das was ihr nicht wollt. Die Angabe der Zeit ist ebenso quatsch wie diese Einschränkung zu fordern: Wer nicht schneller schreiben kann dem bringt diese Angabe nichts, höchstens Frust.
Beide Ansätze sind zusätzliche Barrieren. Dann könnt ihr genauso gut Captchas benutzen.
@Sascha: Ich glaube du hast da was verwechselst: Der User soll nicht innerhalb von X Sekunden den Artikel schreiben, sondern ihn frühstens nach X Sekunden abschicken, du hast das hier etwas verdreht. Wenn jemand nicht schnell Tippen kann, dann darf er auch 3 Stunden dafür brauchen. Nur füllen Spambots die Formulare im Sekundentakt aus, und das ist spricht nicht für die Nutzung eines Formulars wie es Menschen tuen.
Interaktion bei einem ausgeblendetem Formularfeld? Wo bitte? Er muss es nicht ausfüllen, da findet keine Interaktion statt. Und wie gesagt: Die meisten Screenreader blenden Inhalte die mittels CSS ausgeblendet wurden ebenfalls aus und beachten sie nicht, fakto würden diese Besucher genau so das Formular bedienen können wie alle anderen auch, für die die es doch sehen steht dazu ein kleiner Text das sie das folgende Textfeld bitte frei lassen sollen. Barriere = 0. Zumal das wahrscheinlich einen Prozentsatz nahe 0 betrifft.
Ich glaube du hast den Text nicht richtig gelesen, kann das sein? ;)
Will mich ja nicht einmischen, aber mal so nebenbei bemerkt: bei mir kommen seit Jahren keinerlei Bots mehr durch und ich vertraue nicht auf externe Dienste (u.a. wegen Datensicherheit und wegen Antwortzeiten jenseits von Gut und Böse)… sondern nur auf meine Individuallösung :-)
@Christian: Was das erste angeht stimmt es, das hatte ich nicht richtig verstanden.
Das zweitere habe ich richtig verstanden. Es ist falsch zu behaupten, dass der Benutzer nichts tun müsste. Die Anweisung, das folgende Feld leer zu lassen ist defakto Interaktion/Kommunikation. Und das finde ich immer nicht sinnvoll. Die Zeit-Lösung und die erzwungene Vorschau sind die einzigen sinnvollen Ideen.
Also, nur zum Verständnis: Du findest es praktischer 2x auf einen Absende-Button zu klicken (Vorschau bei Textpattern), als wenn 0.3% aller meiner Besucher einen kurzen Text lesen müssen das sie bitte folgendes Feld leer lassen sollen?
Sorry, aber das will mir nicht in den Kopf. Wie gesagt lesen diese Info nur die jenigen die CSS ausgeschaltet haben, was doch ein verschwindent geringer Teil ist… diese müssen genau einen Satz lesen… da will ich nicht verstehen warum es besser ist erst einen Vorschau-Button zu betätigen
Man muss das immer in Relationen sehen… die zeitliche Verzögerung ist natürlich auch machbar… doch sehe ich in dem verstecktem Feld keinerlei beeinträchtigung, werder für User mit aktiviertem CSS noch für die die es ausgeschaltet haben.
Nein. Sie müssen den Satz lesen (ihn also verabeiten) das Feld, das danach vorgelesen wird (oder angezeigt) ignorieren. Mit Lesen und Ignorieren treffen zwei Dinge auf, die keinen direkten Sinn ergeben außer Spam zuverhindern, während die erzwungene Vorschau auch einen Sinn ergibt. Und zwar das kontrollieren des Abgesendeten. Zudem ermöglicht es dem Programmierer Spam-Inhalte vor dem eigentlichen Absenden zu verhindern bzw. dem Benutzer auf Verstöße hinzuweisen, wie ungültige E-Mail Adresse (für jene ohne JavaScript) etc.
Falls du aber nicht möchtest, dass der Nutzer seinen Inhalt bestätigen muss, kannst du es so gestalten, dass der Inhalt automatisch nach einer gewissen Zeit gepostet wird. Dann entfällt der Spamschutz-Aspekt zu einem Teil, logisch.
Jopp, aber du lässt dabei ausser Acht das dies nur einen winzig geringen Prozentsatz betrifft der den Text lesen muss… da 1. moderne Screenreader nunmal auch display:none; interpretieren können und zweitens jeder der eh mit CSS surft davon auch nichts sieht. Logisch ist eine Vorschau gut, aber doch nicht immer praktikabel. Wenn ich in einer Community 100 Nachrichten schreibe, dann will ich doch vielleicht garnicht jede Nachricht mir vorher anschauen, und wenn ich z.B. eh schon eine Livepreview eines Kommentars habe, dann wäre es auch doppelt-gemoppelt diese 2x ausgeben zu lassen.
Also, es stellt keine barriere dar, denn ein Satz ist noch lange keine Barriere, und wir wollen ja nicht kleinlich sein… solange man alles sachlich erklärt… (für die 3 Menschen auf die es zutrifft).
Falls du aber nicht möchtest, dass der Nutzer seinen Inhalt bestätigen muss, kannst du es so gestalten, dass der Inhalt automatisch nach einer gewissen Zeit gepostet wird.
Er wird nicht automatisch gepostet, es wird lediglich kontrolliert wie lange der User zur Eingabe der Daten benötigt hat. Hat er zum ausfüllen des Formulars nur unter 3 Sekunden gebraucht == Bot.
Also zu CAPTCHAs zurückzukehren ist eher unsinnig. Dr. Peter Purgathofer hat in einem lesenswerten Vortrag erklärt, warum die ersten nicht barrierefrei
sind und zweitens zur Spamabwehr scheitern müssen. Details siehe: http://www.bizeps.or.at/news.php?nr=8627
Dein Zitat hast du falsch verstanden. “Falls du aber nicht möchtest, dass der Nutzer seinen Inhalt bestätigen muss, kannst du es so gestalten, dass der Inhalt automatisch nach einer gewissen Zeit gepostet wird.“
Das meinte ich als Alternative zur obigen Überlegung. Der Nutzer kann, wie auf Spreeblick, seinen Beitrag eine zeitlang ändern, nach dieser Zeitspanne ist der Beitrag online.
Die Problematik bei display:none: Neue Bots werden diese Spam-Barriere umgehen können. Wenn bereits eine Live-Vorschau existiert ist es natürlich sinnlos eine weitere einzubauen. Dann verzichtige ich entweder auf die Live-Vorschau, die sowieso nur die mit JavaScript sehen (oh, oh — jetzt fange ich schon wieder an) oder auf diese Art des Spam-Schutzes.
Meine Frage ist: Wie verhindere ich Spam früh, nachhaltig und (möglichst) barrierefrei?
Du schreibst: “denn ein Satz ist noch lange keine Barriere, und wir wollen ja nicht kleinlich sein… solange man alles sachlich erklärt… (für die 3 Menschen auf die es zutrifft).“ Ich will kleinlich sein. Denn wieso die drei Menschen ausschließen, wenn es eine Möglichkeit gibt sie einzuschließen? Zudem gibt es keinen Grund darum zu bitten Elemente zu ignorieren, die sonst einen Sinn hätten. Sprich: Wozu Elemente einfügen die ignoriert werden müssen? Alles muss einen Sinn haben, seinen Sinn behalten.
Grüße, Sascha
Vielleicht wäre es besser an dieser Stelle von Barrierearmut zu sprechen? Barriefreiheit ist doch eher ein Modewort um ein Produkt besser Verkaufen zu können. Ein Produkt welches komplett Barrierefrei ist, wird es nie geben. Dafür gibt es viel zu viele verschiedene und individuelle körperliche, seelische und/oder geistige Einschränkungen die es zu beachten gilt.
Von daher ist nicht die Frage: Wie können alle Menschen eingeschlossen werden.
Es sollte eher die Frage gestellt werden: Wie können wir mit den vorhanden Möglichkeiten so wenig wie möglich ausschließen.
Zumal man an dieser Stelle davon ausgehen sollte, das eine Person die ein Formular ausfüllen kann, auch geistig im Stande ist ein solch einfaches Captcha zu bestehen.
@Alex: Wer hat diese Frage gestellt?
Mir geht es darum, dass ich niemanden aussperren will, wenn es eine Methode gibt, die es mir ermöglicht sie einzubeziehen. Klar, es ist kleinlich, jeder darf es auf seiner Seite anders machen.
Ohne dem Aspekt der Barrierefreiheit/-armut/der Zugänglichkeit betrachtet: Es macht keinen Sinn Elemente einzubringen die niemand sehen soll. Ja, auch das ist eine Wiederholung. Ich will es nur deutlich machen, dass es mir auch darauf ankommt.
Lasst uns (und Christian) überlegen welche weiteren Alternativen es zur Spam-Abwehr gibt.
OT: wie kann man die E-Mail-Benachrichtigungen wieder abbestellen?
jap, geht aber nur wenn man immer am gleichen Rechner sitzt, da das Cookie-gebunden ist ;-)
Ohne Cookie, kein Abmelden.
Ein Link in jeder E-Mail wäre was feines.
Kommentar-Feed für diesen Artikel
Ergebnisse der Webworker-Umfrage 2008 Warten auf jQuery und CakePHP
Hmm, wirklich keine schlechte Idee dass mit dem versteckten Inputfeld.
Auch die Sache mit der einfachen Frage ist nicht schlecht, erfordert aber eben leider wieder “interaktion” vom User.
Werde das “versteckte Inputfeld” mal ausprobieren, danke für den Tipp.