Professionele webontwikkelaars, waarom Google Captcha? :(

[terabyte]

Als gewone web gebruiker valt het overmatig gebruik van Google Captcha steeds meer op


Het moet me echt van het hart, maar ik erger me steeds meer aan dat verplicht moeten aanklikken van stoplichten, brandkranen, zebrapaden, etc. Het is steeds meer een pesterijtje en met goede UX heeft al helemaal niets te maken.

Misschien is het omdat ik Firefox gebruik en Google mij wil straffen omdat ik geen gebruik maak van hun dataverzamelingssoftware (Chrome)

voorbeelden:
- NS zakelijk abonnement inloggen
- TransIP domein beheren
- een tijdslot reserveren voor sporten bij Basic-Fit
Hier loopt het helemaal de spuigaten uit, moet soms 4 a 5 rondes aan plaatjes aanklikken. (Fuck you Basic Fit)
- random blogs met reactiemogelijkheid

Als gewone bezoeker/klant is het gewoon niet leuk om constant overal stoplichten, brandkranen, zebrapaden, etc. te moeten aanklikken.


Ja, ik weet het, je wilt "bots" weren.

Maar moet dat per se ten koste van
- de tijd van je echte bezoeker. Naar wie kan ik een factuur sturen voor het trainen van Googles AI?
- de privacy van je bezoeker (Google registreert natuurlijk dat persoon x met IP y op tijdstip t jouw site bezoekt)

Ik richt me aan de pro's, jullie zijn degenen die jullie klanten hierover adviseren en dit soort dingen implementeren, dus jullie zijn diegen die de macht hebben om dit ook te veranderen.

Is er anno 2020 echt geen betere oplossing?? Kunnen we deze trend niet eens omkeren en een alternatief zoeken voor de tentakels van Google? (Mits je UX echt belangrijk vindt?)


Bedankt voor het lezen van mijn klacht, ik hoop dat het in de toekomst tot iets positiefs kan leiden.

Paar random achtergrondartikelen:
https://www.dtelepathy.co...ha-alternatives-better-ux
https://uxdesign.cc/recap...st-nightmare-c28b7341e88a
https://www.reddit.com/r/...google_captcha_for_using/
https://www.stiphosting.nl/website/privacy-en-recaptcha/
https://salesforceprofs.c...lternative-for-recaptcha/

[The Eagle]

Ik snap je frustratie, maar ik draai hem even om om je te laten zien wat je vraagt
Stel jij wilt een nieuwe tafel. Ga je dan ook klauwen met geld uitgeven aan de aanschaf van gereedschap als een draaibank etc en hout om hem zelf te maken? Of ga je naar de winkel en koop je een nieuwe tafel?
Zelf een captcha ontwikkelen kost klauwen met geld terwijl je hem tegen een fractie van de kosten zo kunt gebruiken. Daar heeft een developer sowieso zelf niet zo heel veel over te zeggen, opdrachtgever betaalt.

[terabyte]

2 reacties:
1. is het hebben van een Captcha een doel op zich? Het gaat niet om een make-or-buy beslissing, het gaat hier om wel probleem je probeert op te lossen (bots) en hoe groot dat probleem uberhaupt en of de oplossing ten koste gaat van andere zaken (UX)

2. Opdrachtgever betaald dus bepaalt? Dit is een zwak argument, dit is puur het verbergen achter de klant. Jij hebt als professional ook een adviserende plicht. Ikzelf ben nog nooit een klant tegengekomen die daar een problem mee had (integendeel).

[The Eagle]

Vooropgesteld: ik ben zelf geen developer, zit meer richting architectuur.
Tav 2: jij _vindt_ dat verbergen achter de klant. Ik zeg "klant heeft een bouwblok met functionaliteit X (bescherming) nodig voor zijn website. Kan ik zelf bouwen, kost veel, moet ik ook onderhouden. Kan ik ook afnemen bij een techgigant, die kan beter ontwikkelen, onderhouden en beheren als ik zelf kan en is goedkoper. Integreert bovendien perfect met alle andere analytics zut die we al van ze afnemen. Je wilt niet zonder. Kies maar.

Tav 1: probleem is er niet. Hooguit dat je niet zonder functionaliteit X wilt omdat je anders wel problemen krijgt. De enige die er een probleem van maakt ben jij zelf heb ik het idee. Heel eerlijk: ik snap dat die capthcas vervelend kunnen zijn. Jij snapt ook dat het een noodzakelijk kwaad is. Qua user experience dus eigenlijk niet te voorkomen, en liever heb je dan iets waarvan je weet dat het gewoon werkt. Anders wordt de UX nog minder.

[NMe]

terabyte schreef op zaterdag 21 november 2020 @ 13:16:
2 reacties:
1. is het hebben van een Captcha een doel op zich? Het gaat niet om een make-or-buy beslissing, het gaat hier om wel probleem je probeert op te lossen (bots) en hoe groot dat probleem uberhaupt en of de oplossing ten koste gaat van andere zaken (UX)

Je weet dat er ook een ReCaptcha-variant is die geen user-input vraagt?

En zeker bij grote sites is dat probleem met bots wel degelijk enorm.

2. Opdrachtgever betaald dus bepaalt? Dit is een zwak argument, dit is puur het verbergen achter de klant. Jij hebt als professional ook een adviserende plicht. Ikzelf ben nog nooit een klant tegengekomen die daar een problem mee had (integendeel).

Ik heb nog nooit een opdrachtgever gehad die, wanneer gepresenteerd met wat ik per uur kost en een urenschatting van enkele dagen werk zoiets heeft van "Weet je wat? Die standaardoplossing hoef ik niet." Althans, niet voor een stom iets als een ReCaptcha.

[dutchmartin]

terabyte schreef op zaterdag 21 november 2020 @ 13:16:
2 reacties:
1. is het hebben van een Captcha een doel op zich? Het gaat niet om een make-or-buy beslissing, het gaat hier om wel probleem je probeert op te lossen (bots) en hoe groot dat probleem uberhaupt en of de oplossing ten koste gaat van andere zaken (UX)

2. Opdrachtgever betaald dus bepaalt? Dit is een zwak argument, dit is puur het verbergen achter de klant. Jij hebt als professional ook een adviserende plicht. Ikzelf ben nog nooit een klant tegengekomen die daar een problem mee had (integendeel).

1. Sommige klanten willen dit perse omdat ze in het verleden last hebben gehad van spam in hun contactformulier. Zelf beheer ik ook een website waar geen bot of spam detectie zit op het contactformulier en daar komt regelmatig een verzoek in voor dat onder de categorie ‘gare rotzooi’ ofwel spam behoort. Ikzelf verwijder die berichten en denk er niet teveel over na, maar anderen kunnen daar natuurlijk anders over denken en heen zin hebben om daarmee te dealen.

2. Ik vind dat je een interessant punt maakt. Alleen zijn de requirements van veel website-eigenaren samen te vatten als het moet snel en goedkoop te implementeren zijn. Dat men dan bij reCaptcha uitkomt is logisch, want het is de eerste hit bij het googelen naar de term ‘captcha implementeren’. Het implementeren is makkelijk en het is ook nog gratis! Ja dan voldoet het helemaal en helaas aan de bovenstaande eisen.

[Hahn]

terabyte schreef op zaterdag 21 november 2020 @ 13:16:
2 reacties:
1. is het hebben van een Captcha een doel op zich? Het gaat niet om een make-or-buy beslissing, het gaat hier om wel probleem je probeert op te lossen (bots) en hoe groot dat probleem uberhaupt en of de oplossing ten koste gaat van andere zaken (UX)

2. Opdrachtgever betaald dus bepaalt? Dit is een zwak argument, dit is puur het verbergen achter de klant. Jij hebt als professional ook een adviserende plicht. Ikzelf ben nog nooit een klant tegengekomen die daar een problem mee had (integendeel).

The Eagle geeft je een argument, en of jij dat nou een zwak argument vindt of niet, dat doet er niet toe. Het is en blijft een argument.

Jij vraagt "Waarom Google Captcha?" en in sommige gevallen is het antwoord daarop "Omdat hogerop dat bepaald heeft". Kan je de domste reden ooit vinden, en zelf totaal andere ervaringen hebben, maar dat verandert het antwoord niet.

Wat betreft reactie 1: welke inzichten heb je in hoeverre Google Captcha daadwerkelijk afbreuk doet aan de conversie van je genoemde voorbeelden?

Ik ben het helemaal met je eens dat captcha's een kut ervaring zijn, ik als UX designer haat ze met een passie (en ben heel blij dat wij ze (nog) niet gebruiken, knock-on-wood...), maar als de uiteindelijke conversie er amper op achteruit gaat, maar de nadelige effecten, zoals bots, er wel drastisch door verminderd worden, kan het zakelijk gezien toch een goed idee zijn.

[chielsen]

Naast de gegeven antwoorden.. Captacha zijn bijna altijd irritant omdat dat ongeveer de onderscheidende factor van een mens tov een machine is. Een bot vindt pokke taakjes prima.

Misschien dat we ooit verplicht met DigID moeten identificeren ofzo en dat je dan precies weet met wie je te maken hebt, maar tot die tijd zal dit eerder vervelender dan soepeler gaan worden. Misschien zouden bottraps nog een idee zijn, maar op dit moment is handhaving op het internet nihil.

[Comgenie]

dutchmartin schreef op zaterdag 21 november 2020 @ 13:41:
[...]

1. Sommige klanten willen dit perse omdat ze in het verleden last hebben gehad van spam in hun contactformulier. Zelf beheer ik ook een website waar geen bot of spam detectie zit op het contactformulier en daar komt regelmatig een verzoek in voor dat onder de categorie ‘gare rotzooi’ ofwel spam behoort. Ikzelf verwijder die berichten en denk er niet teveel over na, maar anderen kunnen daar natuurlijk anders over denken en heen zin hebben om daarmee te dealen.

[..]

offtopic:
Een handig eenvoudig truukje hiervoor om de meeste spam af te vangen: Zorg dat de action attribute van het form element pas na 5 seconden dmv javascript wordt gezet. Bots wachten geen 5 seconden, terwijl een normale gebruiker wel langer bezig is dan die 5 seconden.

Je kan het ook server-side oplossen voor de enkele gebruiker die geen javascript wilt gebruiken, maar dan is het iets meer werk.

[OverloadOfRed]

NMe schreef op zaterdag 21 november 2020 @ 13:39:
[...]
Je weet dat er ook een ReCaptcha-variant is die geen user-input vraagt?

Dit is een groot deel van het probleem. reCaptcha (Google dus) v3 is non-intrusive voor 'normale' gebruikers, dus TS zou het niet eens zien als ze ipv v2 'gewoon' v3 gebruikten.

[RobIII]

OverloadOfRed schreef op zaterdag 21 november 2020 @ 18:44:
[...]

Dit is een groot deel van het probleem. reCaptcha (Google dus) v3 is non-intrusive voor 'normale' gebruikers, dus TS zou het niet eens zien als ze ipv v2 'gewoon' v3 gebruikten.

Even uit de blote bol; volgens mij is V3 non-intrusive tot op bepaalde hoogte. Bij een bepaalde threshold kún je volgens mij alsnog zo'n vraag krijgen om alle mieren aan te klikken.

Edit: nevermind, toch niet:

quote: https://developers.google.com/recaptcha/docs/v3

reCAPTCHA v3 will never interrupt your users, so you can run it whenever you like without affecting conversion.

[ Voor 16% gewijzigd door RobIII op 21-11-2020 18:50 ]

[DJMaze]

terabyte schreef op zaterdag 21 november 2020 @ 12:51:
Als gewone web gebruiker valt het overmatig gebruik van Google Captcha steeds meer op

Als verkeersdeelnemer valt het overmatig gebruik van drempels, stoplichten en spoorbomen steeds meer op.

Kan iedereen niet gewoon fatsoenlijk deelnemen aan het verkeer zonder misbruik er van te maken?

En dan weet je waarom iedereen captcha plaatjes in websites plakt en gemeentes drempels opwerpen...

[Barryvdh]

OverloadOfRed schreef op zaterdag 21 november 2020 @ 18:44:
[...]

Dit is een groot deel van het probleem. reCaptcha (Google dus) v3 is non-intrusive voor 'normale' gebruikers, dus TS zou het niet eens zien als ze ipv v2 'gewoon' v3 gebruikten.

V3 is relatief nieuw (sinds 2018) en geeft ipv ja/nee een 'score'. Veel bestaande sites zullen dus nog 'gewoon' V2 gebruiken. Voor mijn gevoel zijn sommige browsers (en wellicht browser apps) gevoeliger voor de 'stoplicht' validatie. Bijv Brave Browser (privacy gericht) wordt voor mijn gevoel een stuk vaker extra gecontroleerd..

[NielsFL]

De meeste sites werken nog altijd prima zonder captcha. Ook de sites van Google zelf. Het kan dus echt wel. En er zijn dan ook diverse andere bot-werende oplossingen.

Maar de grap van de captcha is natuurlijk dat deze zichzelf op zeer irritante maar effectieve wijze adverteert en daarom snel bij klanten en minder ervaren developers als eerste in het vizier komt.

[Xander]

terabyte schreef op zaterdag 21 november 2020 @ 12:51:
- NS zakelijk abonnement inloggen
- TransIP domein beheren
- een tijdslot reserveren voor sporten bij Basic-Fit

Zijn dit niet allemaal diensten waarvoor je moet inloggen met een gebruikersaccount?

Ik snap geloof ik niet zo goed waarom daar een captcha nodig is. Brute-force inlogpogingen kun je toch wel anders tegen gaan? Of voor mijn part na de eerste mislukte inlogpoging een captcha tonen.

[YakuzA]

Hahn schreef op zaterdag 21 november 2020 @ 13:42:
[...]
The Eagle geeft je een argument, en of jij dat nou een zwak argument vindt of niet, dat doet er niet toe. Het is en blijft een argument.

Jij vraagt "Waarom Google Captcha?" en in sommige gevallen is het antwoord daarop "Omdat hogerop dat bepaald heeft". Kan je de domste reden ooit vinden, en zelf totaal andere ervaringen hebben, maar dat verandert het antwoord niet.

Van hogerop komt over het algemeen de vraag voor een veilige site zonder spam.

Het is meestal dan de ontwikkelaar die dat doet dmv een captcha. Omdat dat makkelijk/snel/betrouwbaar is voor een ontwikkelaar.

[NMe]

NielsFL schreef op zaterdag 21 november 2020 @ 22:56:
De meeste sites werken nog altijd prima zonder captcha. Ook de sites van Google zelf. Het kan dus echt wel. En er zijn dan ook diverse andere bot-werende oplossingen.

Het gaat helemaal niet om of de site werkt of niet. Het gaat erom dat er niet gespamd wordt en een van de makkelijkste manieren om dat te voorkomen is door een ReCaptcha op relevante formulieren te zetten.

Er zijn andere manieren om spam te voorkomen maar weinig daarvan zijn net zo makkelijk te implementeren als ReCaptcha. En als je het goed doet heeft je gebruiker er (bijna) geen last van...

YakuzA schreef op zaterdag 21 november 2020 @ 23:09:
Het is meestal dan de ontwikkelaar die dat doet dmv een captcha. Omdat dat makkelijk/snel/betrouwbaar is voor een ontwikkelaar.

De ontwikkelaar zal, als die een beetje verstand van zaken heeft, zeggen wat hij gaat bouwen en hoe en eventueel alternatieven noemen waar de klant dan zelf uit kan kiezen. Het is toch echt vrijwel altijd de klant die zegt "doe de goedkoopste optie maar."

[ Voor 26% gewijzigd door NMe op 22-11-2020 00:00 ]

[Koenvh]

Is er anno 2020 echt geen betere oplossing?? Kunnen we deze trend niet eens omkeren en een alternatief zoeken voor de tentakels van Google? (Mits je UX echt belangrijk vindt?)

Doe een suggestie, zou ik zeggen, want volgens mij is niemand echt een fan van verkeerslichten klikken.

[Voutloos]

Barryvdh schreef op zaterdag 21 november 2020 @ 22:48:Voor mijn gevoel zijn sommige browsers (en wellicht browser apps) gevoeliger voor de 'stoplicht' validatie. Bijv Brave Browser (privacy gericht) wordt voor mijn gevoel een stuk vaker extra gecontroleerd..

Dat is de technische onderbouwing. Maar er is ook een perverse relatie met Chrome. Het is een van de vele subtiele knopjes waar je aan kan draaien om de Chrome ervaring beter te maken. Voor de bottomline van Google zou dat effect zo maar meer impact kunnen hebben dan spamreductie...

[terabyte]

Koenvh schreef op zondag 22 november 2020 @ 00:15:
[...]

Doe een suggestie, zou ik zeggen, want volgens mij is niemand echt een fan van verkeerslichten klikken.

ik heb bij het schrijven van de OP meteen een hele lijst met linkjes gepost (na een simpele startpage.com search) maar tot nu toe is niemand daarop in gegaan.

Verder denk ik dat de suggesties het best vanuit de webontwikkelaars zelf kunnen komen MITS met er uberhaupt voor open staat om over dit soort zaken na te denken.


Een een voorbeeld van wat ik op mijn eigen site heb geimplementeerd:
form field input, verborgen met CSS.
Bots vullen deze altijd in, normale gebruikers zien het niet, dus laten het leeg
Bij submit, controle* of veld uberhaupt leeg is.

Sindsdien geen form-spam meer gehad.

*ik doe dit aan server-kant, maar wellicht kan dit ook in de browser.

[ Voor 40% gewijzigd door terabyte op 22-11-2020 10:52 ]

[terabyte]

Xander schreef op zaterdag 21 november 2020 @ 22:56:
[...]


Zijn dit niet allemaal diensten waarvoor je moet inloggen met een gebruikersaccount?

Ik snap geloof ik niet zo goed waarom daar een captcha nodig is. Brute-force inlogpogingen kun je toch wel anders tegen gaan? Of voor mijn part na de eerste mislukte inlogpoging een captcha tonen.

Ik snap dit dus ook niet! Maar blijkbaar is dit bewust zo geimplementeerd door een professionele webontwikkelaar, dus daarom ook mijn vraag aan de professionele webontwikkelaar community om hier toch echt kritisch over na te denken (ook wat men adviseert richting klant) - want in mijn ogen ben je als ontwikkelaar toch veel meer dan een code-klopper en heb je ook een adviesfunctie richting klant over dit soort zaken.

[MsG]

Het valt me altijd op dat je deze klik-dingen veelal enkel krijgt als je allerlei aluhoedjeblocking aan hebt. Dat is prima en geheel vrijwillig, maar als jij de website minder vertrouwt werkt dat veelal twee kanten op, en wil men ook explicieter van jou weten of je al dan niet een spambot bent.

Overigens klik ik liever stoplichten, heuvels aan dan een hondje rechtop zetten, zoals bij LinkedIn als je die via VPN bezoekt. Die knoppen voor naar rechts en links draaien staan precies verkeerd om, waardoor ik hem altijd eerst verkeerd draai.

[Hackus]

Het is in gebruik om zgn BOTS tegen te gaan, en te kijken of je wel een echt persoon bent, en niet iets wat hen site/shop wil aanvallen. Je krijgt dit vaak alleen als je VPN of dergelijks(add-block, fake dns) gebruikt. vanaf je eigen IP-adres zul je dit amper meemaken, ook niet vanaf Firefox.

[terabyte]

MsG schreef op zondag 22 november 2020 @ 10:52:
aluhoedjeblocking

Beetje jammer dat je mensen die zich bewust zijn van tracking/dataverzameling door Google (en dat zoveel mogelijk proberen te voorkomen ) simpelweg wegzet als aluhoedje.
Als dat de mentaliteit is kan ik me ook voorstellen dat je mijn klacht ook niet serieus zal nemen.

overigens gebruik ik geen VPN

[Postman]

Voor mensen die wel een ReCaptcha nodig hebben maar geen gebruik willen maken van Google zou ik https://www.hcaptcha.com/ aanraden.

Verder is het helaas dankzij (spam)bots nu eenmaal noodzakelijk om toch recaptcha te gebruiken. En dan praat ik niet alleen over bots voor e-mail, contactformulieren of login, maar ook de scalpers die je tegenwoordig meer en meer ziet. AMD gebruikt het bijvoorbeeld ook tijdens hun bestelproces.

Probleem van ReCaptcha is dat het een schijnveiligheid is. V2 is al in 2018 effectief gekraakt en kan dus door vrijwel elke huidige bot omzeilt/gemaakt worden. V3 is alleen leuk als je het al tijden hebt draaien om een website met veel echte gebruikers metric. Zonder dat werkt het alsnog niet, een site met veel bot traffic gaat dan doodleuk de bot traffic als 'correct' bestempelen.
Bronnen: https://threatpost.com/uncaptcha-googles-recaptchas/140593/, https://threatpost.com/go...cha-cracked-again/128690/ (en nog veel meer).
Het lijkt trouwens dat zelfs V3 al omzeilt dan worden door de betere bots.

Comgenie schreef op zaterdag 21 november 2020 @ 15:26:
[...]

offtopic:
Een handig eenvoudig truukje hiervoor om de meeste spam af te vangen: Zorg dat de action attribute van het form element pas na 5 seconden dmv javascript wordt gezet. Bots wachten geen 5 seconden, terwijl een normale gebruiker wel langer bezig is dan die 5 seconden.

Je kan het ook server-side oplossen voor de enkele gebruiker die geen javascript wilt gebruiken, maar dan is het iets meer werk.

Dit is echt een oplossing die nergens opslaat. Het zal de scrapers wellicht tegenhouden, maar iemand die een bot loslaat op jouw website en het gedrag van je website heeft getest zal de bot doodleuk instellen op 6 seconden. Gaat heel je beveiliging.

[ Voor 13% gewijzigd door Postman op 22-11-2020 11:09 . Reden: Bronvermelding ]

[DJMaze]

terabyte schreef op zondag 22 november 2020 @ 10:45:
Een een voorbeeld van wat ik op mijn eigen site heb geimplementeerd:
form field input, verborgen met CSS.
Bots vullen deze altijd in, normale gebruikers zien het niet, dus laten het leeg
Bij submit, controle* of veld uberhaupt leeg is.

Sindsdien geen form-spam meer gehad.

*ik doe dit aan server-kant, maar wellicht kan dit ook in de browser.

Ik heb een Cookie en JavaScript die een hidden input aanmaakt met de cookie key-value.
Dit houdt spam ook tegen.

[Voutloos]

Postman schreef op zondag 22 november 2020 @ 11:07:
Dit is echt een oplossing die nergens opslaat. Het zal de scrapers wellicht tegenhouden, maar iemand die een bot loslaat op jouw website en het gedrag van je website heeft getest zal de bot doodleuk instellen op 6 seconden. Gaat heel je beveiliging.

Beveiliging is niet 0% XOR 100%. Met een veldje en/of tijdcontrole hou je wel degelijk een groep domme, ongerichte (!) bots tegen. Als je klachten zijn dat je continu ruis hebt ivm de random domme bots, is dat een uurtje well spent.
Als je klachten ivm gerichte aanvallen zijn, of als je hier dagen aan gaan knutselen, ben je wel weer onzinnig bezig.

[Comgenie]

Postman schreef op zondag 22 november 2020 @ 11:07:
Dit is echt een oplossing die nergens opslaat. Het zal de scrapers wellicht tegenhouden, maar iemand die een bot loslaat op jouw website en het gedrag van je website heeft getest zal de bot doodleuk instellen op 6 seconden. Gaat heel je beveiliging.

Die oplossing was inderdaad bedoeld voor de ongerichte spam berichten op contact formulieren, waar de meeste (kleinere) websites dagelijks last van hebben.

Voor gerichte spam/bots wordt het natuurlijk veel lastiger al dan niet onmogelijk. Ook al bescherm je de contact formulier met 20 captcha's, ze kunnen ook de website overslaan en gewoon een berg mails sturen naar het achterliggende email adres.

[Zebby]

V3 werkte bij ons voor geen bal, gaf constant errors, dus zijn terug gegaan naar v2-invisible, geen problemen daarmee. Ik ben absoluut niet blij met de Google tracking cookies die je cadeau krijgt, maar onze omgevingen worden toch regelmatig gescand, dus ik wil die bescherming er gewoon op hebben.

Als er een open source alternatief is dat net zo eenvoudig te implementeren is als Google ReCAPTCHA, dan zou ik daar zeker niet tegen zijn. En dat hoeft dan ook niet even goed te zijn, dat kan bijna niet, maar 75% effectiviteit zou al voldoende zijn.

[Oid]

NielsFL schreef op zaterdag 21 november 2020 @ 22:56:
De meeste sites werken nog altijd prima zonder captcha. Ook de sites van Google zelf. Het kan dus echt wel. En er zijn dan ook diverse andere bot-werende oplossingen.

Maar de grap van de captcha is natuurlijk dat deze zichzelf op zeer irritante maar effectieve wijze adverteert en daarom snel bij klanten en minder ervaren developers als eerste in het vizier komt.

Wanneer ik met VPN geconnect ben vraagt google en andere websites mij continue om recaptcha in te vullen. Super irritant maar snap het wel.
@terabyte Zonder VPN heb ik het eigenlijk nog nooit zo de aanwezigheid van recaptcha ervaren. Kan het zijn dat je misschien in een 'bad ip block' zit? Zou je dat ergens kunnen controleren? (en zo ja hoe kom je dan van die reputatie af hehe...)

[Aardbol_23564]

Ik vind het ook een spijtige ontwikkeling dat men veel te snel naar google's oplossing grijpt, terwijl google het niet nauw neemt met privacy. En met RC gaat het veel verder dan enkel ip loggen.

Het is volgens mij luiheid en onwetendheid bij webdevs. Luiheid omdat er van andere (SaaS) alternatieven zijn die niet zo irritant als RC zijn en met respect voor de privacy van de gebruikers. En het kost een kleine moeite om dit even te onderzoeken. Onwetendheid omdat vele devs geen boterham hebben gegeten van veiligheid en weinig besef hebben hoe spambots juist werken. Moesten ze deze minimum kennis hebben, zouden ze weten dat een captcha uberhaupt niet nodig is om je formulieren te beschermen tegen spambots. En bij login formulieren captcha plaatsen, serieus?

Btw, het RC variant die geen input vraagt weekt enkel bij mensen waar google al veel data van heeft kunnen opslagen. Het werkt nier bij mensen die hun privacy zoveel mogelijk beschermen met bv addons

[ Voor 3% gewijzigd door Aardbol_23564 op 24-11-2020 09:53 ]

[DaFeliX]

Oid schreef op maandag 23 november 2020 @ 22:57:
[...]

@terabyte Zonder VPN heb ik het eigenlijk nog nooit zo de aanwezigheid van recaptcha ervaren. Kan het zijn dat je misschien in een 'bad ip block' zit? Zou je dat ergens kunnen controleren? (en zo ja hoe kom je dan van die reputatie af hehe...)

Het is niet alleen IP, er zijn volgens mij meerdere factoren die hier bepalend zijn. Ik vermoed dat Google adhv cookie, IP, historie, tijdstip, browser (en andere meta-data), toestaanslagen/muisbewegingen, wel/niet ingelogd in Google een score maakt, en als je onder een bepaalde grens zit je meer moet doen dan alleen "Ik ben geen bot" aanvinken.

Ik browse met een schone browser, dus ik heb 0 cookies staan als ik begin met mijn sessie. Bij websites moet ik dan vrijwel altijd 3 van die tests doen. Ik hou 't leuk door eerst naar de plaatjes te kijken, en dan pas naar de vraag.

Maar, als ik eenmaal zo'n vragenreeks heb gedaan, kan ik daarna vrijwel moeiteloos door bij andere websites, totdat ik mijn browser afgesloten heb en alle cookies wegzijn.

Wat precies de parameters zijn om te bepalen of je wel/geen vragen moet doen is een goed bewaard geheim door Google, want als ze daar teveel over vrijgeven is het systeem eenvoudiger te omzeilen. In mijn ervaring is de minste kans hier last van te hebben door het gebruik van Chrome, ingelogd te zijn in chrome, altijd 'tzelfde IP gebruiken en nooit cookies weg te gooien. Of het slim is om dat te doen, da's een tweede natuurlijk

[Douweegbertje]

Aardbol_23564 schreef op dinsdag 24 november 2020 @ 09:52:
Ik vind het ook een spijtige ontwikkeling dat men veel te snel naar google's oplossing grijpt, terwijl google het niet nauw neemt met privacy. En met RC gaat het veel verder dan enkel ip loggen.

Het is volgens mij luiheid en onwetendheid bij webdevs. Luiheid omdat er van andere (SaaS) alternatieven zijn die niet zo irritant als RC zijn en met respect voor de privacy van de gebruikers. En het kost een kleine moeite om dit even te onderzoeken. Onwetendheid omdat vele devs geen boterham hebben gegeten van veiligheid en weinig besef hebben hoe spambots juist werken. Moesten ze deze minimum kennis hebben, zouden ze weten dat een captcha uberhaupt niet nodig is om je formulieren te beschermen tegen spambots. En bij login formulieren captcha plaatsen, serieus?

Btw, het RC variant die geen input vraagt weekt enkel bij mensen waar google al veel data van heeft kunnen opslagen. Het werkt nier bij mensen die hun privacy zoveel mogelijk beschermen met bv addons

Lekker kort door de bocht.

Een dev is vaak ook gewoon maar afhankelijk van een opdracht, klant, manager of ???
Dus men werkt in opdracht van de klant:
- integratie van Gcaptcha: 1 uur werk ; want is al beschikbaar als module of lib
- custom integratie: 10 uur werk
Mag jij raden welke optie gekozen wordt.

Vele CMS oplossingen, zoals Magento, biedt alleen maar Gcaptcha aan (zit in de core van dit product).

Er zijn niet veel opties waar je in volledigheid greenfield kan werken met de beste oplossingen. Daarnaast is de beste oplossing voor een eindgebruiker niet altijd de beste oplossing voor de klant.

[Gomez12]

terabyte schreef op zondag 22 november 2020 @ 10:45:
[...]
Verder denk ik dat de suggesties het best vanuit de webontwikkelaars zelf kunnen komen MITS met er uberhaupt voor open staat om over dit soort zaken na te denken.

Het probleem is dat de vraag vanuit de klanten moet komen, niet vanuit de ontwikkelaars.
Google Captcha is gewoon zo populair omdat Google het al gebouwd heeft en het gewoon en 1 uurtje te implementeren is, daar kan je niet tegenop developen... En de klant wil er ook helemaal niet voor betalen dat jij er tegenop gaat developen.

Als een 3e partij wederom iets bouwt wat in 1 uurtje te implementeren is, dan valt het te overwegen. Maar tot die tijd blijft Google Captcha best bang for your buck.

Een een voorbeeld van wat ik op mijn eigen site heb geimplementeerd:
form field input, verborgen met CSS.
Bots vullen deze altijd in, normale gebruikers zien het niet, dus laten het leeg
Bij submit, controle* of veld uberhaupt leeg is.

Sindsdien geen form-spam meer gehad.

*ik doe dit aan server-kant, maar wellicht kan dit ook in de browser.

Dit is leuk tegen script kiddies, niet tegen serieuze bots.
Het is wel een mooi voorbeeld. Want geef jij er iets om als deze "beveiliging" over 2 jaar niet meer werkt?

Want het is heel simpel, deze "beveiliging" is al keihard doorbroken door scripts die gewoon html + css + js interpreteren en daaruit afleiden wat er wel en niet aan de gebruiker getoond wordt.
Nu zie jij die scripts nog niet langskomen, maar binnen 2 jaar schat ik van wel. En dan is het dus de grote vraag ga jij er nu tijd insteken om dit goed te krijgen, ga jij er over 2 jaar tijd insteken om dit goed te krijgen, of laat je google dit gewoon doen?

[naitsoezn]

Gomez12 schreef op dinsdag 24 november 2020 @ 10:25:

Dit is leuk tegen script kiddies, niet tegen serieuze bots.
Het is wel een mooi voorbeeld. Want geef jij er iets om als deze "beveiliging" over 2 jaar niet meer werkt?

Dit. Bij elke vorm van beveiliging wordt er (bewust of onbewust) een afweging gemaakt tussen klantvriendelijkheid en effectiviteit. Vuistregel is: Hoe klantvriendelijker een oplossing is, hoe minder effectief. Natuurlijk zit daar nog wel wat nuance is, maar een 'simpele, klantvriendelijke oplossing' is doorgaans niet bijzonder effectief. Hoe de verhouding klantvriendelijkheid / effectiviteit uiteindelijk geïmplementeerd wordt is dan weer afhankelijk van de prioriteiten die gesteld worden.

[user109731]

Douweegbertje schreef op dinsdag 24 november 2020 @ 10:01:
Een dev is vaak ook gewoon maar afhankelijk van een opdracht, klant, manager of ???
Dus men werkt in opdracht van de klant:
- integratie van Gcaptcha: 1 uur werk ; want is al beschikbaar als module of lib
- custom integratie: 10 uur werk
Mag jij raden welke optie gekozen wordt.

Goed argument, maar toch hebben we daar als developer ook een taak om de klant op de (privacy etc) problemen te wijzen. Als de klant z'n zinnen heeft gezet op een CMS of library dat al jaren niet meer onderhouden wordt, zeggen we ook niet "no problem, ik ga dat gelijk implementeren". Ja ik weet het, het is niet direct te vergelijken, maar het gaat me om het principe.

Hetzelfde zie je ook op andere gebieden, banken die klakkeloos Google Analytics scripts draaien. AMP websites. Chrome. Best gevaarlijke ontwikkelingen IMO.

[ElkeBxl]

user109731 schreef op dinsdag 24 november 2020 @ 13:30:
[...]

Goed argument, maar toch hebben we daar als developer ook een taak om de klant op de (privacy etc) problemen te wijzen. Als de klant z'n zinnen heeft gezet op een CMS of library dat al jaren niet meer onderhouden wordt, zeggen we ook niet "no problem, ik ga dat gelijk implementeren".

Ik ga zeker de klant op de mogelijke problemen wijzen. Maar vaak genoeg wordt er geen keus gelaten:

• Ofwel is de klant klein en willen ze geen tijd (en dus ook geld) steken in iets custom wat in de toekomst ook nog eens onderhouden moet worden (m.a.w.: nog meer tijd en geld nodig)
• Ofwel is de klant groot en wordt er van hogeraf ergens een beslissing genomen om toch maar niet een custom solution te implementeren. Vaak zit je in de grotere bedrijven met een architecture team of ergens een hogergeplaatste die denkt het beter te weten.

Daar komt nog eens vaak andere argumenten bij die ik me zo kan voorstellen waar een klant mee zou af komen:

• "We zitten met teveel botspam, voeg eens zo'n ding toe met die verkeerslichten en brandkranen en zebrapaden die ik moet selecteren!". Waar ik dan een hoop gedoe ga vermijden door er gewoon een Google captcha op te zetten in plaats van iets te moeten maken dat er exact hetzelfde uit ziet
• "We hebben het zo al in andere projecten gedaan!". Dan hoeven ze zich geen zorgen te maken als ik weg zou gaan dat er eerst nog kennisoverdracht moet zijn van de custom oplossing
• "Kan je dat NU toevoegen? Zoiets custom duurt paar dagen/weken? Laat maar, voeg iets NU toe! Hier, die documentatie van Google captcha ziet er makkelijk uit, doe dat!"
• "Waarom zouden we daar weken tijd en geld aan spenderen als je het ook op een paar uur kan? Die privacy is toch niet zo erg, we hebben nog zoveel ander werk voor jou dat belangrijker is!"
• "Onze senior architect heeft jaren geleden al gekozen voor deze standaardoplossing."
• "Gaat jouw custom oplossing dan ook zo mooi integreren met onze Google Analytics?"

terabyte schreef op zaterdag 21 november 2020 @ 12:51:
Ik richt me aan de pro's, jullie zijn degenen die jullie klanten hierover adviseren en dit soort dingen implementeren, dus jullie zijn diegen die de macht hebben om dit ook te veranderen.

Aardbol_23564 schreef op dinsdag 24 november 2020 @ 09:52:
Het is volgens mij luiheid en onwetendheid bij webdevs. Luiheid omdat er van andere (SaaS) alternatieven zijn die niet zo irritant als RC zijn en met respect voor de privacy van de gebruikers. En het kost een kleine moeite om dit even te onderzoeken.

Ik wou echt dat ik die "macht" had. Ik ben maar 1 van de vele kleine elementjes in de grote machine. Ik zit vaak bij grote klanten waar ik dan bots op grote muur waar ik gewoon de macht niet voor heb om erover te geraken. Het kost idd een kleine moeite om het even te onderzoeken en niet zomaar voor de "standaardoplossing" te gaan. Maar gegarandeerd dat ik een boze manager (die vaak het projectgeld betaalt) of een boze senior architect op mijn dak ga krijgen als ik er van afwijk.

Onwetendheid? Absoluut niet. Luiheid? Goh, tot op zeker niveau wel ja. Ik zal wel eens moeite doen om te zien wat ik kan bereiken als ik bij een nieuwe klant/project zit en ik merk dat er iets veel beter kan. Maar als ik voel dat het weer een hoop geklaag gaat veroorzaken en dat er niemand wil mee bewegen, dan zal ik inderdaad wat lui zijn. Zeker als ik bij een groot bedrijf zit waar technologie beslissingen niet door mij mogen genomen worden en waar ze niet echt moeten weten van een klager. Dan zie ik wel bij een volgende klant/project wel of het waard is om eens tegen de schenen te schoppen.

[DaFeliX]

user109731 schreef op dinsdag 24 november 2020 @ 13:30:
[...]

Goed argument, maar toch hebben we daar als developer ook een taak om de klant op de (privacy etc) problemen te wijzen. Als de klant z'n zinnen heeft gezet op een CMS of library dat al jaren niet meer onderhouden wordt, zeggen we ook niet "no problem, ik ga dat gelijk implementeren". Ja ik weet het, het is niet direct te vergelijken, maar het gaat me om het principe.

Hetzelfde zie je ook op andere gebieden, banken die klakkeloos Google Analytics scripts draaien. AMP websites. Chrome. Best gevaarlijke ontwikkelingen IMO.

Understatement: ik ben geen fan van Google. Maar ik weet uit de praktijk dat het heel moeilijk is om opdrachtgevers die niet zo tech-savy zijn, er van te overtuigen dat er een beter alternatief is.

Allereerst is er het "Ja, maar Concurrent X doet het ook zo en die is groot, dus moet ik het ook zo doen"-argument. Puntje bij paaltje vind de opdrachtgever het vaak belangrijker dat ze hetzelfde doen als een ander, dan risico lopen om het anders aan te pakken en omzet te missen. Bovendien heeft een opdrachtgever imo vaak 'angst' voor onbekende dingen; dan maar liever vertrouwd Google want "die jongens doen zulk goed werk".

Dit is overigens zo sterk, dat als ik destijds een non-Google alternatief gebruikte en het werkte niet, het argument "Ja, hadden we toch maar Google X gebruikt" werd gegeven. Als ik een Google-implementatie deed, "lag 't aan de markt/het weer/de spanning in het Midden-Oosten".
Hetzelfde geldt voor zoekmachineoptimalisatie, want als Google zegt dat je Y moet doen, dan staan opdrachtgevers daar om te springen om dat te doen (AMP), ook al geven ze effectief daarmee al hun content af aan Google. Bij mij gaat het er niet in dat opdrachtgevers dat serieus overwegen; maar er is nu eenmaal een grote groep mensen die Google als een heilige graal zien; en elk alternatief wantrouwen.

Dit heeft ook wel 'ns een positief effect gehad, want toen Google aangaf HTTPS boven HTTP te willen gaan prioriteren, ik in een week tijd alle websites heb mogen beveiligen met een SSL-certificaat; wat daarvoor 10% van de websites had.

Daarnaast vinden opdrachtgevers het belangrijk dat hun klanten een vertrouwde interface hebben; dus de "Ik ben geen robot"-vinkje van Google lijkt hun een minder groot obstakel, dan een alternatief dat er net wat anders zit. Ook hier zit weer die angst om vooral klanten niet teveel 'gekke' dingen te tonen. "Dat recaptcha kent men wel, dus dat zal geen enkele blokkade opwerpen voor de conversie".

Het zullen de technische onderlegden onder ons zijn die wat gereserveerder zijn, maar helaas zijn zij vaak diegene die het moeten uitvoeren, en niet diegene die het betalen

[user109731]

ElkeBxl schreef op dinsdag 24 november 2020 @ 16:17:
Ik ga zeker de klant op de mogelijke problemen wijzen. Maar vaak genoeg wordt er geen keus gelaten:

DaFeliX schreef op dinsdag 24 november 2020 @ 16:22:
Understatement: ik ben geen fan van Google. Maar ik weet uit de praktijk dat het heel moeilijk is om opdrachtgevers die niet zo tech-savy zijn, er van te overtuigen dat er een beter alternatief is.

Zeker waar, soms heb je gewoon geen of weinig keus. Wat ik echter vaak zie is dat developers snel de neiging hebben om bij dit soort problemen direct naar Google te rennen alsof het een soort liefdadigheidsinstelling is met als missie het aanbieden van {analytics, browsers, captchas, AMP} tools. De trade-offs (die er wel degelijk aan verbonden zijn) aankaarten is een goede eerste stap denk ik, ongeacht de uitkomst

[DaFeliX]

user109731 schreef op dinsdag 24 november 2020 @ 16:41:
[...]


[...]

Zeker waar, soms heb je gewoon geen of weinig keus. Wat ik echter vaak zie is dat developers snel de neiging hebben om bij dit soort problemen direct naar Google te rennen alsof het een soort liefdadigheidsinstelling is met als missie het aanbieden van {analytics, browsers, captchas, AMP} tools. De trade-offs (die er wel degelijk aan verbonden zijn) aankaarten is een goede eerste stap denk ik, ongeacht de uitkomst

Ik ken een aantal developers, en geen daarvan heeft de neiging om naar Google te rennen, maar juist er met een grote boog omheen te werken. Maar, wellicht zegt dat meer over mijn kenniskring dan over het landelijk gemiddelde natuurlijk

[Koenvh]

@Postman hCaptcha is een mooi alternatief, maar voor mijn gevoel nog niet op hetzelfde niveau als reCAPTCHA. Heel simpel voorbeeldje:



Waar is "Overslaan"? Ik zie 'm niet (niet iedereen begrijpt dat ze de knop "Overspringen" bedoelen).

Daarnaast moet ik ook voor mijn gevoel meer dingen aanklikken, en zijn de afbeeldingen onduidelijker dan Google's variant. Daarnaast is de toegankelijkheid van hCaptcha ook minder (geen audio-optie beschikbaar). reCAPTCHA is niet heilig, verre van, maar het werkt, het werkt goed, en is makkelijk te implementeren.

Ik hoop dat de alternatieven ook op hetzelfde niveau komen.

[ Voor 4% gewijzigd door Koenvh op 24-11-2020 17:15 ]

[GlowMouse]

Omdat dit topic is gericht op de professionele webontwikkelaar: waarom maken jullie geen uitzondering voor ip-adressen van Nederlandse providers? Spam komt meestal van servers of vanuit het buitenland.

Gerelateerd topic: eindeloze recaptcha

[ Voor 13% gewijzigd door GlowMouse op 24-11-2020 17:48 ]

[AW_Bos]

Volgens mij is er niks mis met de ReCaptcha als iemand stoplichten en auto's aan moet klikken. Ikzelf klik elke dag wel op een ReCaptcha van een site, en ik zie heel weinig die foto's met stoplichten en auto's. Al eerder is hier genoemd dat diverse factoren een rol spelen in het wel of niet zien van die foto's. Maar ook kan de webdeveloper in V3 de treshold aanpassen.

Het lijkt me dus een beetje de balans proberen te zoeken in wat wel spam is, en wat niet.
Ik kan me wel indenken dat als je add-ons hebt die je useragent vervalsen, of je browser-fingerprint veranderen, of uit bepaalde vage landen / ip-ranges komt dat je dan wel die klikmeuk krijgt.

[ Voor 3% gewijzigd door AW_Bos op 24-11-2020 17:36 ]

[Postman]

Koenvh schreef op dinsdag 24 november 2020 @ 17:11:
@Postman hCaptcha is een mooi alternatief, maar voor mijn gevoel nog niet op hetzelfde niveau als reCAPTCHA. Heel simpel voorbeeldje:

Waar is "Overslaan"? Ik zie 'm niet (niet iedereen begrijpt dat ze de knop "Overspringen" bedoelen).

Daarnaast moet ik ook voor mijn gevoel meer dingen aanklikken, en zijn de afbeeldingen onduidelijker dan Google's variant. Daarnaast is de toegankelijkheid van hCaptcha ook minder (geen audio-optie beschikbaar). reCAPTCHA is niet heilig, verre van, maar het werkt, het werkt goed, en is makkelijk te implementeren.

Ik hoop dat de alternatieven ook op hetzelfde niveau komen.

Goed voorbeeld. Ik weet niet precies hoe hCaptcha werkt en of ze een publieke repo hebben waarin je een pull request kunt doen. Of misschien kun je bijdragen aan vertalingen. Dit lijkt mij namelijk een gevalletje slechte vertaling en niet slechte implementatie.

Oké het klopt dat het wat minder is dan ReCaptcha. Maar het budget van Google is dan ook een googol maal groter

Het is meer dat je via ReCaptcha helpt om Google nog groter te maken dan ze al zijn. Op die manier krijg je dadelijk nul goed werkende alternatieven en kun je alles via een paar techreuzen doen. Geen idee of je dat wenselijk vind.
Implementatie en alles is bij Google haast perfect, daar kan ik niet omheen.

Rest de vraag: is de oplossing erger dan de kwaal?

[terabyte]

Gomez12 schreef op dinsdag 24 november 2020 @ 10:25:
[...]

Dit is leuk tegen script kiddies, niet tegen serieuze bots.
Het is wel een mooi voorbeeld. Want geef jij er iets om als deze "beveiliging" over 2 jaar niet meer werkt?

Het zou kunnen dat het alleen tegen scriptkiddes werkt, maar feit is dat mijn formspam naar 0 is gegaan.
Dus vanuit mijn ('eindklant') oogpunt werkt het uitstekend, dus ik heb niets te klagen en mijn (menselijke) bezoekers hebben nergens last van..

En ja, ik weet dat bots slimmer worden. Maar ik heb geen reden om nu al een atoombom als oplossing te implementeren terwijl een simpele oplossing in praktijk al uitstekend werkt.

En we zien over 2 jaar wel of het dan nog steeds goed genoeg werkt. Ik ga nu geen niet-bestaande problemen oplossen.

[terabyte]

GlowMouse schreef op dinsdag 24 november 2020 @ 17:30:
Omdat dit topic is gericht op de professionele webontwikkelaar: waarom maken jullie geen uitzondering voor ip-adressen van Nederlandse providers? Spam komt meestal van servers of vanuit het buitenland.

Dit is zo'n typisch voorbeeld van out-of-the box denken wat ik heel erg kan waarderen. Het kost nauwelijks iets, en niemand wordt er onnodig mee benadeeld

[Saven]

Surf je via een VPN of heb je geen Google account? Als je ingelogd bent met een Google account heb je sowieso nooit last van verificatie. Dan vindt Google je namelijk sowieso al geen bot

Koenvh schreef op dinsdag 24 november 2020 @ 17:11:
@Postman hCaptcha is een mooi alternatief, maar voor mijn gevoel nog niet op hetzelfde niveau als reCAPTCHA. Heel simpel voorbeeldje:

[Afbeelding]

Waar is "Overslaan"? Ik zie 'm niet (niet iedereen begrijpt dat ze de knop "Overspringen" bedoelen).

Daarnaast moet ik ook voor mijn gevoel meer dingen aanklikken, en zijn de afbeeldingen onduidelijker dan Google's variant. Daarnaast is de toegankelijkheid van hCaptcha ook minder (geen audio-optie beschikbaar). reCAPTCHA is niet heilig, verre van, maar het werkt, het werkt goed, en is makkelijk te implementeren.

Ik hoop dat de alternatieven ook op hetzelfde niveau komen.

Hcaptcha is vreselijk inderdaad

[ Voor 68% gewijzigd door Saven op 24-11-2020 19:38 ]

[Verwijderd]

terabyte schreef op zondag 22 november 2020 @ 10:45:
[...]


ik heb bij het schrijven van de OP meteen een hele lijst met linkjes gepost (na een simpele startpage.com search) maar tot nu toe is niemand daarop in gegaan.

Verder denk ik dat de suggesties het best vanuit de webontwikkelaars zelf kunnen komen MITS met er uberhaupt voor open staat om over dit soort zaken na te denken.


Een een voorbeeld van wat ik op mijn eigen site heb geimplementeerd:
form field input, verborgen met CSS.
Bots vullen deze altijd in, normale gebruikers zien het niet, dus laten het leeg
Bij submit, controle* of veld uberhaupt leeg is.

Sindsdien geen form-spam meer gehad.

*ik doe dit aan server-kant, maar wellicht kan dit ook in de browser.

Dat is echt een oplossing van likmevesje en met een beetje bot zo voorbij gewandeld.

Probleem is hier eigenlijk precies zoals bij meer klachten - ik heb wel een probleem maar ik weet de oplossing niet. Dus vraag je aan de "Pro's"of er geen andere oplossing is, maar het antwoord accepteer je niet.

Cirkeltje rond, discussie overbodig.

Als je het beter weet -> doen! levert je waarschijnlijk veel geld op.

[Koenvh]

@Postman Goede vraag. Ik heb wel de hoop dat met de hulp van Cloudflare het beter gaat worden, en ik heb het via hun bugreportformulier gemeld.

Uiteindelijk zal het 99% van de gebruikers niet uitmaken dat reCAPTCHA van Google is, als het maar niet te veel werk is om in te vullen. Ik hoop natuurlijk dat er een alternatief komt zonder Google, maar dan moet dat alternatief wel ongeveer even goed werken als Google, en dat ik op dit moment nog niet zo. De gebruikers maakt het niks uit dat hCaptcha kleiner is, en een kleiner budget heeft, die willen gewoon een systeem dat goed werkt. Zulke vertaalinconsistenties en -keuzes helpen absoluut niet mee. (Wie gebruikt het woord "overspringen" in die context? Heeft diegene überhaupt begrepen waar de vertaling voor was?)

@Saven Vreselijk vind ik het niet, minder dan reCAPTCHA op dit moment wel. Allicht komt daar nog verandering in.

[ Voor 3% gewijzigd door Koenvh op 24-11-2020 20:26 ]

[BertS]

Het zou me niet verbazen als het een feature is van hCaptcha. Vanuit de gedachte dat een bot de link niet legt, en een mens wel (al kost dat duidelijk wat moeite, toch ook weer niet heel moeilijk)

[Koenvh]

BertS schreef op dinsdag 24 november 2020 @ 20:29:
Het zou me niet verbazen als het een feature is van hCaptcha. Vanuit de gedachte dat een bot de link niet legt, en een mens wel (al kost dat duidelijk wat moeite, toch ook weer niet heel moeilijk)

Leuke theorie, maar de Engelse versie gebruikt in allebei de gevallen "skip". Blijkbaar is "overspringen" de eerste suggestie van Google Vertalen, dat kan er ook mee te maken hebben.

Ben toch ergens wel blij dat ze dat niet als "afvalcontainer" hebben vertaald

[ElkeBxl]

GlowMouse schreef op dinsdag 24 november 2020 @ 17:30:
Omdat dit topic is gericht op de professionele webontwikkelaar: waarom maken jullie geen uitzondering voor ip-adressen van Nederlandse providers? Spam komt meestal van servers of vanuit het buitenland.

Zoals @terabyte aangeeft idd leuk out-of-the-box denken. Maar welke service ga je daarvoor gebruiken? In hoeverre is die betrouwbaar? Hoe kom je aan die ip-adressen? Simpele geolocation API zoals https://ipstack.com/ zonet eens geopend, hij zit er al volledig naast met mijn locatie. Zo'n 50km verkeerd. Met mijn gsm op 4G is het nog zotter: 150km ernaast. En het is al helemaal onbetrouwbaar door VPNs. Bots kunnen ook wel een VPN gebruiken...

[DedSec85]

Captcha van Google is vooral bedoeld om de AI van hun zelf rijdende auto's slimmer te maken. Let maar eens op hoe vaak je verkeer-gerelateerde zaken moet aanklikken....zebrapaden, brandkranen, stoplichten, fietsen, auto's, etalages etc.
Ik merk dat ik vooral vaak Captcha's krijg als ik via een VPN verbinding werk (dus altijd). En dan heb ik gewoon een verbinding met een NL server, het is niet zo dat ik een 6-voudige VPN verbinding richting Honolulu heb. Maar erg irritant die Captcha's.

[GlowMouse]

ElkeBxl schreef op dinsdag 24 november 2020 @ 21:16:
[...]

Zoals @terabyte aangeeft idd leuk out-of-the-box denken. Maar welke service ga je daarvoor gebruiken? In hoeverre is die betrouwbaar? Hoe kom je aan die ip-adressen?

Van RIPE. Van elke ip-range kun je zien bij welke organisatie hij hoort, en als je Ziggo en KPN eruit filtert heb je het gros al te pakken.

DedSec85 schreef op dinsdag 24 november 2020 @ 21:26:
Captcha van Google is vooral bedoeld om de AI van hun zelf rijdende auto's slimmer te maken. Let maar eens op hoe vaak je verkeer-gerelateerde zaken moet aanklikken....zebrapaden, brandkranen, stoplichten, fietsen, auto's, etalages etc.

Ik maak daarom altijd een paar fouten

[Postman]

DedSec85 schreef op dinsdag 24 november 2020 @ 21:26:
Captcha van Google is vooral bedoeld om de AI van hun zelf rijdende auto's slimmer te maken. Let maar eens op hoe vaak je verkeer-gerelateerde zaken moet aanklikken....zebrapaden, brandkranen, stoplichten, fietsen, auto's, etalages etc.
Ik merk dat ik vooral vaak Captcha's krijg als ik via een VPN verbinding werk (dus altijd). En dan heb ik gewoon een verbinding met een NL server, het is niet zo dat ik een 6-voudige VPN verbinding richting Honolulu heb. Maar erg irritant die Captcha's.

Wat mij opviel is dat ik best veel captcha's kreeg op een nieuwe Windows installatie op nieuwe laptop van werk de eerste paar maanden, en dit nu bijna niet meer voorkomt. Lijkt dus dat er toch een soort van fingerprint is op basis van meer dan alleen de browser.

[iRobin]

GlowMouse schreef op dinsdag 24 november 2020 @ 21:35:
[...]

Van RIPE. Van elke ip-range kun je zien bij welke organisatie hij hoort, en als je Ziggo en KPN eruit filtert heb je het gros al te pakken.


[...]

Ik maak daarom altijd een paar fouten

Dus thuis ff een server aanslingeren op mijn Nederlandse IP adres en ik kan weer los

[dakka]

terabyte schreef op dinsdag 24 november 2020 @ 19:29:
[...]


Het zou kunnen dat het alleen tegen scriptkiddes werkt, maar feit is dat mijn formspam naar 0 is gegaan.
Dus vanuit mijn ('eindklant') oogpunt werkt het uitstekend, dus ik heb niets te klagen en mijn (menselijke) bezoekers hebben nergens last van..

Cool...

Maar heeft jouw site dagelijkse bezoekers die in de duizendtallen lopen en een winkelmandje?

Als jouw site simpel uit was html/react/weetikveel bestaat, dan zijn je grootste zorgen idd gewoon de gelegenheid spammers.

Maar er zijn ook gerichte spambots die zodra ze ook maar een hint ruiken van wordpress of iets dat op een webshop lijkt(dus kijken voor een winkelmandje), of een site die een redelijke hoeveelheid aandacht heeft,
dan hebben honeypots al geen zin meer.
(wat trouwens makkelijk te omzeilen is voor de bot door te kijken of in de DOM een input de tag "required" heeft, CSS word gewoon genegeerd met selenium/phantomJS)

En dan zijn er nog de maatoplossing spambots, die inderdaad voor de grote jongens zoals de NS/transip/etc gebruikt worden.

En aansluitend bij de rest, je kan de klant nog zoveel infomeren, vroeg of laat krijg je bij de meeste te horen "Ja maar bij website X werkt het zo, ik wil dat het ook zo werkt, deze ziet er anders uit!"

[ Voor 11% gewijzigd door dakka op 25-11-2020 04:33 ]

[ElkeBxl]

GlowMouse schreef op dinsdag 24 november 2020 @ 21:35:
[...]

Van RIPE. Van elke ip-range kun je zien bij welke organisatie hij hoort, en als je Ziggo en KPN eruit filtert heb je het gros al te pakken.

Ok eens door de docs gegaan en ze zeggen zelf al:

Objects in the RIPE Database are mostly created and updated by users. The RIPE NCC makes every effort possible within its resources to keep the RIPE Database clean of false, obsolete and unnecessary data. However, the RIPE NCC cannot guarantee the accuracy of all data in the RIPE Database.

Inaccurate values in the RIPE Database, whether highlighted or not, should be reported to the RIPE NCC via the report form.

Maar ok, laten we er even van uit gaan dat de data altijd correct is en ik RIPE hun DB zou willen gebruiken:

• Ik ga moeten uitleggen wat RIPE is. Google kent iedereen, maar RIPE gaat zelfs menig developer niet kennen. Iets wat niet zo gekend is, gaat zeker niet de eerste keuze zijn. Ik hoor zo al management zeggen "pak maar Google, we moeten het niet ingewikkeld maken"
• Ik moet nu een nieuwe API aanroepen en uitzoeken hoe die te integreren in mijn flow. Ok ze bieden wel een GitHub en docs aan, maar elke developer die na mij komt gaat ook ingelicht moeten worden hoe dat werkt. Goede code legt zichzelf uit maar het eerste dat elke dev zich gaat afvragen is: "wat is RIPE en waarom zitten wij daar calls naar te doen?"
• In grote bedrijven ga ik dit moeten verdedigen tegenover management en een architecture team of een senior dev/architect. Als die niet mee willen in het toevoegen van een RIPE query, gaat er sowieso niks van in huis komen
• Ziggo en KPN eruit filteren? Ok, en wat dan met ik als brave Belg? Wie gaat bepalen op wat je filtert? Wie krijgt de eer om geen captcha te krijgen? Zoals @iRobin aanhaalt, even zorgen dat ik in je VIP list terecht kom en de bouncer zal braafjes knikken dat ik binnen mag.

[Smuey]

Die vraag is eenvoudig te beantwoorden: Daar kiest een webontwikkelaar helemaal niet voor, dat doet de opdrachtgever. Die moet tijd, geld en mankracht inzetten om alle zooi uit de legitieme resultaten te filteren en kiest dus voor een snel te implementeren oplossing om dat domweg niet te hoeven doen.

Overigens is mijn ervaring met ReCaptcha anders, want ik krijg alleen bij een hele brakke implementatie die afbeeldingen voor mijn kiezen. Of als ik een script geautomatiseerd dingen in een formulier met ReCaptcha laat invullen. Waar het eigenlijk dus ook gewoon voor bedoeld is...

[_Erikje_]

recaptcha v3 is veel prettiger en houdt ook een groot aantal spammers tegen.

[GlowMouse]

ElkeBxl schreef op woensdag 25 november 2020 @ 06:50:
[...]

Maar ok, laten we er even van uit gaan dat de data altijd correct is en ik RIPE hun DB zou willen gebruiken:

• Ik ga moeten uitleggen wat RIPE is. Google kent iedereen, maar RIPE gaat zelfs menig developer niet kennen. Iets wat niet zo gekend is, gaat zeker niet de eerste keuze zijn. Ik hoor zo al management zeggen "pak maar Google, we moeten het niet ingewikkeld maken"
• Ik moet nu een nieuwe API aanroepen en uitzoeken hoe die te integreren in mijn flow. Ok ze bieden wel een GitHub en docs aan, maar elke developer die na mij komt gaat ook ingelicht moeten worden hoe dat werkt. Goede code legt zichzelf uit maar het eerste dat elke dev zich gaat afvragen is: "wat is RIPE en waarom zitten wij daar calls naar te doen?"
• In grote bedrijven ga ik dit moeten verdedigen tegenover management en een architecture team of een senior dev/architect. Als die niet mee willen in het toevoegen van een RIPE query, gaat er sowieso niks van in huis komen

Het gaat al mis bij de eerste stap. Je kunt beter vragen of je thuisgebruikers met Ziggo of KPN mag uitzonderen van de captcha.
Er is geen API, dus er komt geen RIPE query. Je haalt 1x de ip-ranges uit RIPE, bouwt daar een functie omheen, en klaar. Het heeft wat onderhoud nodig want de RIPE-db wijzigt af en toe en misschien wil je op een dag ook ipv6 ondersteunen, zelfs zonder onderhoud verbeter je met een makkelijke stap de ervaring van je een groot deel van klanten.

Ziggo en KPN eruit filteren? Ok, en wat dan met ik als brave Belg? Wie gaat bepalen op wat je filtert? Wie krijgt de eer om geen captcha te krijgen? Zoals @iRobin aanhaalt, even zorgen dat ik in je VIP list terecht kom en de bouncer zal braafjes knikken dat ik binnen mag.

Je weet als het goed is waar je bezoekers vandaan komen, dus als je op die manier 99% van je bezoekers een betere ervaring kunt bieden, is dat mooi meegenomen.

iRobin schreef op woensdag 25 november 2020 @ 02:00:
[...]

Dus thuis ff een server aanslingeren op mijn Nederlandse IP adres en ik kan weer los

Dan spoor ik je op en kleed ik je financieel uit

[ElkeBxl]

GlowMouse schreef op woensdag 25 november 2020 @ 20:51:
[...]
Het heeft wat onderhoud nodig want de RIPE-db wijzigt af en toe en misschien wil je op een dag ook ipv6 ondersteunen, zelfs zonder onderhoud verbeter je met een makkelijke stap de ervaring van je een groot deel van klanten.

En daar loopt het al fout, omdat het wat onderhoud nodig kan hebben. Er is dus een initiële extra kost voor het opzetten van iets custom en het gaat in de toekomst nog geld kosten. Tenzij ik kan bewijzen dat het een positieve invloed heeft op de instroom van geld, vrees ik ervoor dat menig manager dat niet zal aftekenen.

GlowMouse schreef op woensdag 25 november 2020 @ 20:51:
Je weet als het goed is waar je bezoekers vandaan komen, dus als je op die manier 99% van je bezoekers een betere ervaring kunt bieden, is dat mooi meegenomen.

"Betere ervaring" is relatief. Hoe minder je bezoekers moet lastigvallen hoe liever natuurlijk. Maar bezoekers zijn nu al heel veel dingen gewoon geworden op websites. Bijvoorbeeld op het huidige project zitten we met een cookie policy die helft van het scherm blokkeert en met een legal disclaimer ("Geld lenen kost ook geld" met een voorbeeldje wat een financiering kost) die ook nog eens op desktop kwart van het scherm vult (en op mobile zelfs heel het scherm). Gebruikerstesten hebben al aangewezen dat meeste mensen die 2 dingen gewoon wegklikken zonder nadenken, zeker als ze al bewust iets kwamen opzoeken of kopen. Ik zou dan veel liever zo'n dingen weg hebben omdat die alle bezoekers impacteren ipv een captcha die een veel kleiner deel van de bezoekers impacteert.

[ Voor 44% gewijzigd door ElkeBxl op 26-11-2020 07:05 ]

[DaFeliX]

hCaptcha vergroot aandeel tot 15%. Het artikel is door hCaptcha zelf geschreven, dus wees gewaarschuwd. Ook is de manier van meten niet uitgelegd, desalniettemin lijkt het wel aannemelijk dat ze groeien en daarmee een deel van reCAPTCHA afsnoepen.

[Postman]

DaFeliX schreef op donderdag 26 november 2020 @ 07:28:
hCaptcha vergroot aandeel tot 15%. Het artikel is door hCaptcha zelf geschreven, dus wees gewaarschuwd. Ook is de manier van meten niet uitgelegd, desalniettemin lijkt het wel aannemelijk dat ze groeien en daarmee een deel van reCAPTCHA afsnoepen.

Wij van WC eend...

15% lijkt me overdreven, maar dat ze groeien snap ik enigszins wel. Met de groeiende beweging van mensen die niets meer met de grote tech bedrijven te maken willen hebben zul je als website beheerder/eigenaar/ontwikkelaar toch iets moeten. Want als ik de hele boel van Google in mijn adblocker zet, dan werkt de ReCaptcha ook niet meer. En kan ik dus effectief gezien de website niet meer gebruiken.

[Voutloos]

Postman schreef op donderdag 26 november 2020 @ 08:32:
Wij van WC eend...

15% lijkt me overdreven, maar dat ze groeien snap ik enigszins wel.

Dit soort statistieken over het hele internet is überhaupt problematisch. Wat wel significant is: Cloudflare gebruikt hCaptcha.

offtopic:
Over de omvang en mitm rol van Cloudflare kan je natuurlijk ook weer van alles vinden etc etc... Maar wmb is het al gunstig dat CF en Google niet maximaal elkaar gebruiken.

[GlowMouse]

ElkeBxl schreef op donderdag 26 november 2020 @ 06:59:
[...]

En daar loopt het al fout, omdat het wat onderhoud nodig kan hebben. Er is dus een initiële extra kost voor het opzetten van iets custom en het gaat in de toekomst nog geld kosten. Tenzij ik kan bewijzen dat het een positieve invloed heeft op de instroom van geld, vrees ik ervoor dat menig manager dat niet zal aftekenen.

Alle software heeft onderhoud nodig. Software is nu eenmaal dienstverlening. Maar mijn voorspelling is dat als je het niet aanraakt, het over 15 jaar nog aardig werkt in tegenstelling tot recaptcha.

[Voutloos]

GlowMouse schreef op donderdag 26 november 2020 @ 16:40:
Alle software heeft onderhoud nodig.

True.

Maar mijn voorspelling is dat als je het niet aanraakt, het over 15 jaar nog aardig werkt in tegenstelling tot recaptcha.

Contradictie met eerdere axioma. Tevens had je zelf ook al ipv6 genoemd, de adoptie daarvan is een grote onbekende dus hindert ook elke lange termijn voorspelling.
Dus je voorspelling slaat eerlijk gezegd nergens op, of doe mij anders maar dezelfde glazen bol als jij hebt.