[Form] Anti-Spam

[Workaholic]

Ik ben totaal geen ster op het gebied van scripting in html,javascript,xml of website design in het algemeen.

Ik heb een simpele form in xml met :

code:

<form action="(asp)/sendform.asp" caption="Antwoordformulier partnerprogramma" form-e-mail="[e-mail]" follow-up="contact">
<hr/>
<input type="text" maxlength="30" name="Name" caption="Naam"/>
<input type="text" maxlength="25" name="Function" caption="Functie"/>
<input type="text" maxlength="30" name="Company" caption="Bedrijf"/>
<input type="text" maxlength="15" name="PhoneNumber" caption="Telefoonnummer"/>
<input type="text" maxlength="30" name="e-mail" caption="E-mail adres"/>
<hr/>
<label caption="Uw belangstelling gaat uit naar:"/>
<input type="checkbox" name="checkAlgemeen" caption="Algemeen"/>
<input type="checkbox" name="checkProduct1" caption="Product1.Web"/>
<input type="checkbox" name="checkProduct2" caption="Product2"/>
<!--    <input type="checkbox" name="checkBugTracker" caption="BugTracker"/> -->
    <hr/>
<!--    <textarea name="comment" caption="Eventuele opmerkingen" rows="4" cols="40"/> -->

Nu krijg ik hier erg veel spam op binnen.

Omdat ik liever geen gebruik maak van CAPTCHA of andere image verifcation software (irritant!) bedacht ik me dat ik het telefoonnummer veld graag van een check wou voorzien.

Ongeveer 75 % van de spam berichten komen ana met random characters in alle velden. Indien ik dus de gebruiker zou verplichten om een telefoon nummer als volgt in te vullen : 024-6771540 (of iets in die trend) dan zou ik al een hoop minder spam krijgen.

Kan iemand mij vertellen of dit mogelijk is met xml? Ik kon alleen javascript opties vinden, of gewoon het object required maar dan verplicht ik de gebruiker om het in te vullen.. ik wil dus meer..

Kan iemand mij in de goede richting sturen? Wellicht de juiste keywords en of het uberhaupt wel kan met de huidige code? of moet ik hier voor alles aanpassen?

[ Voor 4% gewijzigd door Workaholic op 24-06-2008 09:45 ]

[Cruz]

Offtopic: Beuningen \o/

Ontopic: Kan je dat niet beter in de asp code regelen?
Het is te lang geleden dat ik met asp gewerkt heb, maar in php zou het zoiets zijn:
$telnr = $_POST['telefoonnr'];
$clean_telnr = preg_replace("/[^0-9]/", "", $telnr);
if (strlen($clean_telnr) != 10) die('Ongeldig telefoonnummer, niet 10 cijferig!');
if (strpos($clean_telnr,'0') !== 0) die('Ongeldig telefoonnummer, start niet met 0!');

etc.
Om het af te maken moet je geen die gebruiken maar het netjes afvangen met een mooie foutmelding e.d.

[André]

Waarom zet je er niet een extra veld bij: "Wat is de som van 2 en 5", een goede spambot die dat kan raden

[Workaholic]

Cruz schreef op dinsdag 24 juni 2008 @ 09:52:
Offtopic: Beuningen \o/

Beuningen!

André schreef op dinsdag 24 juni 2008 @ 09:54:
Waarom zet je er niet een extra veld bij: "Wat is de som van 2 en 5", een goede spambot die dat kan raden

Dat is inderdaad wel erg simpel.. maar wellicht dat er hier toch uiteindelijk een oplossing voor komt.

Bij nader inzien wil ik toch maar overstappen op een image verificatie. Dit is tegenwoordig toch redelijk een geacepteerde methode op websites.

Kan iemand mij vertellen of er een simpele methode is hiervoor? Of kan ik dit beter uitbesteden voor 100 euro aan een extern bedrijf die dit voor mij regelt?

[ Voor 59% gewijzigd door Workaholic op 24-06-2008 10:30 ]

[TeeDee]

Helemaal veilig zal het nooit zijn, maar je zou ook een form element kunnen toevoegen. Deze verbergen (display:none ofzo) met CSS. Vervolgens controleren op het feit of dit element wel of niet ingevuld is.

Een captcha was een goed idee. Maar captcha crackers worden beter en sneller. Neem nu eens een voorbeeld aan bijvoorbeeld Rapidshare. Daar is het vaak (bijna altijd) onmogelijk om het verschil tussen een kat en een hond eruit te halen.

[ Voor 36% gewijzigd door TeeDee op 24-06-2008 10:39 ]

[SchizoDuckie]

http://recaptcha.net/whyrecaptcha.html ?

[_Thanatos_]

Waar gaat de site over? Misschien kun je aan je bezoeker een vraag stellen die betrekking op de site heeft. Een site voor nerds kan bijveerbeeld iets over een pc vragen (meerkeuze-antwoorden dus) terwijl een site over wiskude de bezoeker een vergelijking kan laten oplossen. Een "wie is de lekkerste chick" site kan foto's van vrouwen als captcha gebruiken met de vraag wie de lekkerste is. Het is met dat soort beveiliging dus maar net wat voor site het is.

Een zakelijke site is wat anders. Een contactformulier moet snel en toegankelijk zijn. Daar mag beslist geen normale captcha inzitten. Maar je kunt wel een bepaalde validatie uitvoeren van een veld dat een bot niet snapt, zoals inderdaad een telefoonnummer dat met 0 of + moet beginnen. Een hele simpele rekensom is evengoed een werkbare optie, hoewel misschien wat minder toegankelijk.

[gertvdijk]

_Thanatos_ schreef op woensdag 25 juni 2008 @ 13:27:
Een hele simpele rekensom is evengoed een werkbare optie, hoewel misschien wat minder toegankelijk.

Hoezo? Voorleessoftware kan het voorlezen, Ctrl++ maakt te tekst groter... Juist een Captcha doet heel erg af aan toegankelijkheid.
Als je bedoelt dat je ook mensen wil helpen die niet kunnen rekenen...

[ Voor 7% gewijzigd door gertvdijk op 25-06-2008 13:32 ]

[Verwijderd]

Op het internet zijn er meerdere scripts en uitleg te vinden over Captcha's. Als je het niet kan vinden heb ik nog wel een script of 2 voor je liggen

[Wortelsoep]

Ik maak altijd een inputveld met de naam "first_name" of iets dergelijks, die verberg je dan met CSS. Een bot vult in dit veld wat in, een mens niet want die ziet het hele veld niet
Werkt tot nu toe prima, en geen irritante dingen bij het invullen.

[ Voor 9% gewijzigd door Wortelsoep op 25-06-2008 15:25 ]

[_Thanatos_]

Als je bedoelt dat je ook mensen wil helpen die niet kunnen rekenen...

Dat bedoel ik inderdaad
Het klinkt gek dat iemand niet kan uitrekenen wat 5+7 is, maar als je doelgroep kleine kinderen is, dan moet je ze daar niet mee opzadelen.

[Wortelsoep]

offtopic:
De vraag is dan volgens mij meer of je jezelf wil opzadelen met mail van kleine kinderen

[Verwijderd]

Wilko schreef op woensdag 25 juni 2008 @ 15:25:
Ik maak altijd een inputveld met de naam "first_name" of iets dergelijks, die verberg je dan met CSS. Een bot vult in dit veld wat in, een mens niet want die ziet het hele veld niet
Werkt tot nu toe prima, en geen irritante dingen bij het invullen.

Maar is dat dan eigenlijk wel een goede oplossing? Want een screenreader of iemand die CSS uitschakelt die ziet dat veld wel. Dus eigenlijk zou je dan bij dat veld voor de niet-bots nog zoiets moeten zetten dat dat veld niet ingevuld mag worden met een uitleg erbij.

(O nee, ik vergis me, screenreaders lezen display: none; niet, maar degenen die CSS uitschakelen zien dus wel het verborgen inputveld.)

[ Voor 9% gewijzigd door Verwijderd op 25-06-2008 19:32 ]

[Blaise]

Je kan er uitleg bijzetten dat het veld bedoeld is om spamrobots te vangen en dat je het dus niet moet invullen. Die tekst verberg je uiteraard ook met CSS.

[ Voor 16% gewijzigd door Blaise op 26-06-2008 00:13 ]

[SchizoDuckie]

Wat is er nou mis met recaptcha.com?
Het is snel te implementeren, heeft een 'read out loud' optie, het zijn 2 korte woordjes en het wordt gebruikt op honderden sites.

[curry684]

Zonder je gebruikers lastig te vallen met captchas kun je hier al heel veel mee oplossen. Genereer een timestamp in je form als hidden input of url-parameter, en bij postback controleer je of de timestamp minder dan 3 seconden of meer dan 30 minuten oud is, en zo ja weiger je de comment - in het eerste geval heb je een spambot die wel de pagina leest alvorens te postbacken (niemand kan een reply tiepen binnen 3 seconden na genereren van de pagina), en in het tweede geval heb je een caching spambot die eerst crawlt en opslaat en daarna pas gaat spammen - en dat zelden al binnen een uur doet.

Simpele methode, stopt 99% van de comment spam, en valt je gebruikers nergens mee lastig. Win.

[TRON]

curry684 schreef op donderdag 26 juni 2008 @ 00:36:
Zonder je gebruikers lastig te vallen met captchas kun je hier al heel veel mee oplossen. Genereer een timestamp in je form als hidden input of url-parameter, en bij postback controleer je of de timestamp minder dan 3 seconden of meer dan 30 minuten oud is, en zo ja weiger je de comment - in het eerste geval heb je een spambot die wel de pagina leest alvorens te postbacken (niemand kan een reply tiepen binnen 3 seconden na genereren van de pagina), en in het tweede geval heb je een caching spambot die eerst crawlt en opslaat en daarna pas gaat spammen - en dat zelden al binnen een uur doet.

Simpele methode, stopt 99% van de comment spam, en valt je gebruikers nergens mee lastig. Win.

Deze methode heb ik nu ook toegepast op TRON's Poll. Laten we eens kijken of dit de lading een beetje dekt. 'k Laat echter de timestamp niet in het form verschijnen, maar 'k bewaar het in een sessie. Eens kijken of dit mijn lieftallige spammers tegenhoudt.

Het is in ieder geval een klantvriendelijk idee.

[_Thanatos_]

maar 'k bewaar het in een sessie

En als (sessie)cookies uitstaan?

[TeeDee]

_Thanatos_ schreef op vrijdag 27 juni 2008 @ 20:22:
[...]

En als (sessie)cookies uitstaan?

Dan zijn het dusdanige gebruikers dat je ze niet eens wil bedienen.

[Eris]

Hoe ik heb het gedaan was doormiddel van input velden die doormiddel van Javascript werden gekopieerd. Staat javascript uit wordt er gevraagd om de code te copieren.

Het werkt tot op heden goed.

[TRON]

TeeDee schreef op vrijdag 27 juni 2008 @ 20:42:
[...]

Dan zijn het dusdanige gebruikers dat je ze niet eens wil bedienen.

_Thatanos_ ik neem het standpunt in wat TeeDee ook inneemt. Het is niet meer nodig om sessies te blokkeren. Mocht het zo zijn dat de statistieken flink veranderen in mijn nadeel, dan zal ik uiteraard mijn standpunt herzien.

'k Verwacht dat alle populaire browsers dit accepteren en dat de meeste gebruikers van deze browsers dit niet blokkeren. Maar goed, dat is natuurlijk een aanname

[Voutloos]

TRON schreef op vrijdag 27 juni 2008 @ 18:21:
[...]
Deze methode heb ik nu ook toegepast op TRON's Poll. Laten we eens kijken of dit de lading een beetje dekt. 'k Laat echter de timestamp niet in het form verschijnen, maar 'k bewaar het in een sessie.

Pfff, state aan de server toevoegen terwijl het gewoon in een hidden form field kan. ZIjn meteen sessies niet benodigd, dus scheelt je ook weer die discussie. Desnoods doe je een triviale encryptie zodat het niet meer op een timestamp lijkt cq. je zeker weet dat enkel jouw server die waarde heeft kunnen setten.

[DiedX]

curry684 schreef op donderdag 26 juni 2008 @ 00:36:
Zonder je gebruikers lastig te vallen met captchas kun je hier al heel veel mee oplossen.

Ook een nette methode idd.

Zelf heb ik een website waarbij ik feitelijk gezien met statische HTML werk. Mocht je een formulier willen invullen, dan krijg je een sessie, direct gevolgd door een redirect naar de form. De formprocessor checkt of je een sessie hebt, en zo nee, dan accepteerd hij de invoer niet.

Een spambot zal het formulier inrammen, maar heeft geen lopende sessie. Dag spambot. Draait al 3 jaar vlekkeloos.

[mithras]

Ik genereer serverside twee tekenreeksen. Een ervan is bijvoorbeeld de naam, het email adres of het bericht. De ander is een text input veld die ik met css verberg.

Eerst werkte het door alleen een veld met css te verbergen, maar daar zijn ze (handmatig?) achtergekomen, dus nu worden twee namen van velden dynamisch aangemaakt. Het houdt de spam prima tegen, nergens meer last van.

Verder check ik ook nog op een tijd, maar dat gebeurt ook met serverside gegevens

[_Thanatos_]

TRON schreef op vrijdag 27 juni 2008 @ 23:27:
_Thatanos_ ik neem het standpunt in wat TeeDee ook inneemt. Het is niet meer nodig om sessies te blokkeren. Mocht het zo zijn dat de statistieken flink veranderen in mijn nadeel, dan zal ik uiteraard mijn standpunt herzien.

Daar gaat het niet om. Het gaat erom dat je een bezoeker blokkeert of als spammer bestempeld door het ontbreken van cookies. En dat terwijl cookies op sommige plekken gewoon uitstaan. Punt. En mensen die wel begrijpen wat cookies zijn, zetten ze soms zelf uit om snelheid te winnen. Ik ga toch niet verwachten dat een site die geen state onthoudt - als in: waar je niet inlogt enzo - tóch cookies vereist.

Stel maar voor, in IEDER request én response iets als:
ASPNETSESSID=09237407123989509120938

Of één keer een extra <input type=hidden name=time value=14987349872> en een time=14987349872 in de post.

Als je het dus om de bandbreedte doet, dan zou ik het wel weten.

[TRON]

Het is inderdaad klantvriendelijker om het op de bovengenoemde manier te doen. Wellicht dat ik het nog even aanpas.

[curry684]

_Thanatos_ schreef op zondag 29 juni 2008 @ 02:03:
[...]


Daar gaat het niet om. Het gaat erom dat je een bezoeker blokkeert of als spammer bestempeld door het ontbreken van cookies. En dat terwijl cookies op sommige plekken gewoon uitstaan. Punt.

Mjah tis net zoiets als de airbags van je auto uitschakelen of de aardlekschakelaars uit je huis slopen. Het kan, en er zijn vast mongolen die het doen, maar het blijven linksom of rechtsom mongolen waar je geen rekening mee hoeft te houden.

[sub0kelvin]

Ik gebruik voor spamfiltering binnen websites Mollom. Een gratis service die alleen een captcha laat zien als hij twijfelt of het spam is. De POST gaat dus via een spam-detectie-server, en die beoordeelt of het spam, ham of twijfel is. Spam wordt geblokkeerd, ham wordt toegelaten en bij twijfel krijg de gebruiker een recaptcha om te bewijzen dat je mens bent.

En het gave is dat je systeem ook kunt gebruiken voor automatische moderatie van posts met een lage kwaliteit (al gebruik ik het daar niet voor en ik weet dus niet hoe goed ze daar op dit moment in zijn).

[!null]

Dat Mollom ziet er ook goed uit.

DiedX schreef op zaterdag 28 juni 2008 @ 11:46:

Zelf heb ik een website waarbij ik feitelijk gezien met statische HTML werk. Mocht je een formulier willen invullen, dan krijg je een sessie, direct gevolgd door een redirect naar de form. De formprocessor checkt of je een sessie hebt, en zo nee, dan accepteerd hij de invoer niet.

Een spambot zal het formulier inrammen, maar heeft geen lopende sessie. Dag spambot. Draait al 3 jaar vlekkeloos.

Dit is wel een nette oplossing denk ik. Moet binnenkort voor een klant o.a. even een contact formuliertje maken, en ik denk dat ik dit ga toepassen. Dat je eerst op de index moet zijn geweest (wordt geregistreerd in sessie variabele) en daarna naar het contact formulier. Als je rechtstreeks naar het contact formulier gaat krijg je een nette waarschuwing. Volgens mij vang je hier het meeste mee af, al valt er natuurlijk wel wat voor te maken zodat je wel eindeloos kan spammen.

[_Thanatos_]

curry684 schreef op maandag 30 juni 2008 @ 12:03:
[...]

Mjah tis net zoiets als de airbags van je auto uitschakelen of de aardlekschakelaars uit je huis slopen. Het kan, en er zijn vast mongolen die het doen, maar het blijven linksom of rechtsom mongolen waar je geen rekening mee hoeft te houden.

Dat is wat anders. Je mag ervan uitgaan dat cookies aanstaan ja. Maar je mag mensen die ze uit hebben staan, niet afstraffen. Je weet niet waarom die mensen ze uit hebben staan, dus het kan heel beledigend overkomen.

Daarnaast raad ik je aan het tweede deel van mijn door jou gequote posting nog eens te lezen: het scheelt gewoon bandbreedte.

[Ferret]

Ik gebruik voor mijn contactformulier een veld wat ik verberg (met php/CSS) en zodra dat door een bot wordt ingevuld wordt het formulier niet verzonden. Ik heb nooit spam.... werkelijk nooit.

[Xcalibur]

De truuk die spambots kennelijk uithalen met die contactformulieren is dat ze extra headers toevoegen aan het bericht, waardoor de mail niet alleen naar de eigenaar van het formulier gaat maar naar nog veel meer mensen.

Ik check standaard of er meerdere to, cc of bcc headers inzitten en sloop die eruit
Dat werkt ook prima (dát, of ik heb absoluut geen populaire forms ), en geen gebruiker die er iets van merkt....

[gertvdijk]

Xcalibur schreef op maandag 30 juni 2008 @ 20:44:
De truuk die spambots kennelijk uithalen met die contactformulieren is dat ze extra headers toevoegen aan het bericht, waardoor de mail niet alleen naar de eigenaar van het formulier gaat maar naar nog veel meer mensen.

Dat is een heel ander probleem dan wat we hier bespreken. Imo gewoon een lam script dan als je zo een semi-open mail relay speelt.

[link0007]

Ferret schreef op maandag 30 juni 2008 @ 20:04:
Ik gebruik voor mijn contactformulier een veld wat ik verberg (met php/CSS) en zodra dat door een bot wordt ingevuld wordt het formulier niet verzonden. Ik heb nooit spam.... werkelijk nooit.

^^ ik sluit me aan bij de verborgen velden.

Ik verberg ze met een div:

HTML:

<form>
<goede input dingetjes>
<div style="height: 0px; visibility: hidden;">
vul het volgende veld niet in:
<verborgen input veld>
</div>
</form>

[Stoney3K]

link0007 schreef op maandag 30 juni 2008 @ 21:07:
[...]

^^ ik sluit me aan bij de verborgen velden.

Ik verberg ze met een div:

HTML:

<form>
<goede input dingetjes>
<div style="height: 0px; visibility: hidden;">
vul het volgende veld niet in:
<verborgen input veld>
</div>
</form>

Hier eventjes op inhakend, ik kom regelmatig gruwelijk irritante visuele captcha's tegen, vaak van standaard pakketten. Het komt regelmatig voor dat ik zelfs niet door de spam-beveiliging heen kom omdat de plaatjes van zo'n captcha-script op zijn minst onduidelijk zijn. En het wordt nog erger als er onderscheid gemaakt wordt tussen upper- en lowercase, cijfers en letters (was dat nou een 'l' of een '1'?) en het wordt al helemaal briljant voor mensen met dyslexie of een lichte visuele handicap.

Wat ik eens voor een pakket wil proberen is, in plaats van captcha's, één van de formulier-velden een random variabelenaam te geven afhankelijk van de sessie van de gebruiker. Als een spambot gewoon een poging doet om een POST te sturen met willekeurige data, dan zal ie er niet doorheen komen omdat het veld met naam <random> leeg of onaangekruist is gebleven. Een bot kan zo'n veldnaam niet herhaald ontfutselen omdat die per sessie anders is, de enige manier om zoiets te achterhalen is de HTML te ontcijferen waar het formulier op staat.

Als er spambots voorbij komen die toch de HTML uit elkaar peuteren, dan is daar op zich ook wel een oplossing op te vinden. Ik denk dat de sleutel voor dit soort trucs toch is dat je random elementen in het formulier verwerkt, of dat nou met sessie-sleutels, cookies, hashes of andere cryptografische grapjes is.

Een bot (geautomatiseerd proces) zal er vanuit gaan dat een registratieproces altijd hetzelfde is, of op een voorspelbare manier afwijkt. De truc is dus om een registratieproces te maken wat voor de gebruiker goed leesbaar en overzichtelijk is, maar per sessie genoeg afwijkt om een bot het niet te laten snappen.

[Voutloos]

Stoney3K schreef op donderdag 14 augustus 2008 @ 00:09:
één van de formulier-velden een random variabelenaam te geven afhankelijk van de sessie van de gebruiker. Als een spambot gewoon een poging doet om een POST te sturen met willekeurige data, dan zal ie er niet doorheen komen omdat het veld met naam <random> leeg of onaangekruist is gebleven. Een bot kan zo'n veldnaam niet herhaald ontfutselen omdat die per sessie anders is, de enige manier om zoiets te achterhalen is de HTML te ontcijferen waar het formulier op staat.

Elke bot weet de naam van de diverse form inputs op te pikken hoor, die worden echt niet op de gok bepaald. Gaat dus niet helpen.

Overigens ben je "aan het inhaken op captcha plaatjes", maar hetgeen je quote ging daar niet over. Wat je quote is juist een van de gebruiksvriendelijker methodes (aka onmerkbaar voor iedereen die niet met Lynx surft ). Dit plus een min. en max tijdspanne waarin gepost kan worden vangt met gemak >99% af, tenzij je specifiek getarget wordt.

[wolly_a]

Ik ken het zelfde probleem met een website... Toen laatst weer een hele berg meuk in het formulier werd gepoept en ik zat zo te kijken naar de onzin die gepost was, toen viel me het gebruik van veel weinig gebruikte letters op...

Helemaal 100% dicht zal het niet zijn en je moet er wel een beetje aan tweaken, maar wat nu als je gewoon de letters een waarde toekent... q en x zijn weinig gebruikte letters in bijv. gastenboeken, dus hoge spamscore, de y wordt al wat meer gebruikt, maar is toch wel een vreemde letter, dus ook een bepaalde waarde aan toekennen.

Als je ook nog eens kijkt naar onmogelijke lettercombinaties, zoals bijv. deze uit mijn collectie met afgevangen spam: vxqtpp. Bovendien maak je een vreemd tekstveld, dus geen naam, adres, e-mail, etc., maar iets wat wel slaat op je website, maar niet makkelijk automatisch te herkennen is. Dat heb ik ook en daar staan meestel dit soort dingen in: HKFXDVWoGduIzerO en QxIjVoNRHZZbTLbTsp. Een hele rits medeklinkers op een rij kan in de Nederlandse taal niet, dus dat is ook al strafpunten voor de post.

Verder check je nog op wat mooie woorden als: porn, dolly, titties, naked, etc... en je bent volgens mij al een heel eind met je spamfilter.

[!null]

Er worden hier aardig wat wazige oplossingen bedacht, om om een visuele captcha heen te werken. Dan kan je naar mijn idee toch echt beter Mollom implementeren. http://mollom.com/

[Stoney3K]

GreenSky schreef op donderdag 14 augustus 2008 @ 09:19:
Er worden hier aardig wat wazige oplossingen bedacht, om om een visuele captcha heen te werken. Dan kan je naar mijn idee toch echt beter Mollom implementeren. http://mollom.com/

Het punt is juist, je wil die captcha's eruit gooien, want een groot deel is zelfs al compromised en is niet te gebruiken door mensen met een handicap. En audio-captcha's (die gebruikt worden om visueel toegankelijk te blijven) zijn nog makkelijker te omzeilen.

Wat je in principe zoekt is een mechanisme dat 99,9% zekerheid geeft dat je een persoon aan de lijn hebt, maar daar niet noodzakelijkerwijs vreemde 'denk' grappen in hoeft te zetten. Ik ben op een gegeven moment een formulier tegenkomen dat simpelweg de vraag stelde 'sum of three and two' (of andere cijfers woordelijk uitgeschreven) waarop je dus ook woordelijk moet antwoorden. Okee, dat is wel te omzeilen, maar dat is maar net afhankelijk van de populariteit van zo'n script.

Je zit eigenlijk met een fundamenteel probleem: Als het spambeveiligings-proces geautomatiseerd aangemaakt wordt, dan is het op de één of andere manier ook weer automatisch te omzeilen. En als je een proces maakt wat té random is, dan is het ook door een mens niet meer te ontcijferen (waar de meeste captcha-oplossingen nu al last van hebben). De meest veilige oplossing is natuurlijk om altijd een mens in de schakel te houden -- maar ik heb als beheerder van een inmiddels redelijk bekend Nederlands forum ook al gemerkt hoe lastig dat is. Als je continu mails in je inbox krijgt met "gebruiker gfadhjahighailg is net aangemaakt, bekijk AUB zijn gegevens" ben je het op een ogenblik ook wel zat.

De uitdaging is dus om een stukje techniek te verzinnen wat voor elke sessie uniek is en alleen door een persoon is uit te vogelen, terwijl je je niet moet gaan beroepen op zintuigen (plaatjes, geluiden) ivm toegankelijkheid, parate of lokale kennis ("Wie was de president van bladiebla in jaar x") of andere situaties waarmee je bepaalde groepen mensen uitsluit.

In all een redelijk interessante uitdaging

[sub0kelvin]

Mijns inziens voldoet Mollom juist wel aan het merendeel van jouw eisen: door een audio aan te bieden kunnen zowel blinden als doven het toch gebruiken. En 95% van de mensen worden als zodanig herkend, en worden niet lastig gevallen (is geen 99,9% zoals jij eist, maar toch... ).

Ff wat statistieken (willekeurige dag): 99,69% van de spam wordt gepakt en slechts 5% van de echte mensen wordt bestookt met captcha's. Dat bij 80% spam en 20% normale mensen, gemiddeld. Die dunne bruine lijn onder het grijze is het deel van de (echte) mensen dat lastig wordt gevallen.