A Mana működésének része, hogy folyamatosan új technológiákkal kísérletezünk, és időről időre rákérdezünk a saját eszközeinkre: amit évek óta használunk, még mindig a legjobb válasz-e. Ez a szokás azért fontos, mert a legtöbb eszköz nem egy rossz döntés miatt marad a helyén, hanem azért, mert működik. És amíg működik, ritkán kérdez rá bárki, hogy van-e nála jobb.
A bot-védelmünk évekig a Google reCAPTCHA volt. Bevált, csendben tette a dolgát, nem okozott gondot. Pontosan ezért volt jó jelölt a felülvizsgálatra: a megszokott, láthatatlanná vált default, amihez hozzá sem nyúltunk, mert nem kellett. Most sorra került, és kipróbáltuk helyette a Cloudflare Turnstile-t.
A konkrét apropót az adta, hogy újraépítettük a kapcsolatfelvételi űrlapot, és bevezettük a hírlevél-feliratkozást; eközben a footerből is levettük a publikus e-mail-címünket, mert egy kiírt cím garantáltan spamet és bot-aratást hoz. Két új űrlap védelme jó alkalom megnézni, mivel is védjük őket. Az, hogy végül mire jutottunk, kevésbé érdekes, mint a szempontok, amelyek odáig vezettek; ezek egy másik cégnél is ugyanígy érvényesek.
A bot-védelemnél a widget, vagyis az a kis ellenőrző doboz a form alján, csak a felület. A védelem érdemi része a szerveren dől el, és ott is marad, bármelyik szolgáltatót választjuk. Aki a widgetet lecseréli, a felületet cserélte le, nem a védelmet.
Miért probléma a bot-forgalom egy B2B oldalon
Egy B2B oldalon a bot-forgalom ritkán támadás a szó drámai értelmében. Sokkal gyakoribb az unalmasabb változat: automatizált szkriptek végigjárják a netet, és kitöltenek minden űrlapot, amit találnak. Ez négy különböző helyen okoz kárt, és egyik sem látványos, ezért sokáig észre sem venni.
Az első a CRM elszennyeződése. A hamis vagy értelmetlen kitöltések bekerülnek az értékesítési rendszerbe, és ott ülnek valódi leadként. Valakinek végig kell néznie és ki kell szűrnie őket, vagy ha nem teszi, az értékesítő valós időt tölt olyan érdeklődők után, akik nem léteznek.
A második a mérés torzulása. Ha a marketing egyik mutatója a beérkező leadek száma, a bot-kitöltések felfújják ezt a számot. A csapat abban a hitben él, hogy egy kampány jól teljesít, holott a növekmény egy része gépi zaj. Rossz adatból rossz döntés lesz arról, hova menjen a következő marketingköltés.
A harmadik a hírlevél-lista romlása. A feliratkozó űrlapra betöltött hamis vagy másokhoz tartozó címek rontják a lista minőségét, és ezzel a kézbesíthetőséget (hogy a levél a postafiókba jut-e, vagy a spam mappába). Egy elég szennyezett listáról küldött hírlevél könnyen az egész domain megbízhatóságát rontja le.
A negyedik a kiírt e-mail-cím learatása, ez volt a footeres döntésünk oka. Egy publikus címre nem kell csábítani a spamet, magától megjön.
Hogyan működik a CAPTCHA, és mi a baj vele
A CAPTCHA egy teszt, amely megpróbálja eldönteni, ember vagy gép tölti-e ki a formot, mielőtt a beküldés érvényessé válna. A klasszikus megközelítés ezt láthatóan teszi: kattints a jelölőnégyzetre, válaszd ki a lámpát tartalmazó képeket, gépeld be a torzított szöveget. Ezzel a megközelítéssel két baj van, és egyik sem technikai.
Súrlódás az ügyfélélményben
Minden extra lépés, amit a felhasználóra kirakunk, csökkenti a kitöltési arányt. Ez általános igazság az űrlapoknál, és különösen fájó B2B-ben, ahol egy érdeklődő ritka és értékes: nem tízezer látogatóból akarunk ezret, hanem száz látogatóból a néhány komolyat. Egy képes puzzle, amit kétszer is meg kell oldani, pont a legrosszabbkor, a beküldés pillanatában állítja meg az embert. A veszteséget nem látni, mert aki emiatt lép le, az nyom nélkül tűnik el.
Ehhez jön az akadálymentesség. A vizuális puzzle eleve kizárja a látássérült felhasználókat; a hangalapú alternatíva jellemzően gyenge és nehézkes. Egy B2B cégnél, amely komolyan veszi, hogy bárki elérje, ez nem apró részlet.
Az adatvédelmi dimenzió
A reCAPTCHA a Google szolgáltatása, és a működéséhez böngészőből származó jeleket továbbít a Google felé, hogy megítélje, emberszerű-e a viselkedés. Ez európai környezetben visszatérő kérdést vet fel: milyen tájékoztatással és milyen jogalapon kerül a látogató adata egy harmadik félhez, ráadásul egy Európán kívüli szolgáltatóhoz. A pontos jogi megítélés a konkrét beállítástól, a hozzájárulás (consent) kezelésétől és a mindenkori szabályozói állásponttól függ. A választás így nem tisztán műszaki döntés, hanem adatvédelmi is, és ezt a szempontot a legtöbb csapat átugorja.
A gyakorlati következmény itt válik kézzelfoghatóvá: a Turnstile a működéséhez nem használ sütiket, és nem épít profilt a látogatóról, ezért jellemzően nem igényel külön hozzájárulás-mezőt vagy consent-banner-integrációt a formokon. A reCAPTCHA-nál ez visszatérő fejfájás, mert a Google felé menő adat és a sütihasználat miatt a hozzájárulás kezelése rendre külön feladat.
Hogyan működik a Turnstile
A Turnstile a klasszikus puzzle helyett a legtöbb esetben nem kér semmit a felhasználótól. A widget a háttérben böngészőjeleket és könnyű ellenőrzéseket futtat, köztük egy proof-of-work jellegű lépést: a böngészőnek egy apró számítási feladatot kell elvégeznie, ami egy embernek észrevehetetlen, egy tömeges bot-farmnak viszont, ahol egyszerre sok ezer kitöltés zajlik, érezhető költség. Ezt a Cloudflare managed challenge-nek nevezi: a rendszer dönti el, kell-e egyáltalán interakció. A gyanús esetben feldob egy egyszerű lépést, a többségnek viszont láthatatlan marad.
Ha az ellenőrzés lefutott, a widget ad egy tokent, egy rövid, aláírt igazolást arról, hogy a kitöltés átment az ellenőrzésen. Ez a token viszont önmagában semmit nem ér, amíg a szerver a Cloudflare siteverify végpontján, a titkos kulccsal, meg nem erősíti, hogy valódi és érvényes. Itt dől el a védelem: ha a szerver kihagyja ezt a lépést, és a token puszta jelenlétét elég bizonyítéknak veszi, a widget csak dísz, mert a token hamisítható vagy újrajátszható.
Ehhez képest a megszokott alternatíva, a reCAPTCHA, két fő változatban él. A v2 az, amit a legtöbben ismernek: jelölőnégyzet, mögötte esetenként képes puzzle. A v3 láthatatlan, és nem enged vagy tilt, hanem egy pontszámot ad nulla és egy között arról, mennyire tűnik emberinek a látogató; a döntést, hogy mi legyen a küszöb, a fejlesztőre bízza. A közös pont mindháromban ugyanaz, mint a Turnstile-nál: a kliens csak jelez, a döntést a szervernek kell meghoznia.
Amit a Turnstile sem old meg
Kényelmes lenne azt írni, hogy megvolt a váltás, és megoldódott a probléma. Nem így van; több minden nyitva maradt.
A hatásosság a támadó komolyságától függ. Egy egyszerű, tömeges szkriptet a Turnstile jó eséllyel megállít. Egy elszánt, célzott támadót, aki valódi böngészőt automatizál, vagy aki emberi kitöltőket fizet meg a CAPTCHA-k megoldására, egyetlen widget sem állít meg biztosan. A challenge a zaj nagy részét szűri, nem a legfelkészültebb ellenfelet.
A csapat feladatainak java része megmarad. A szerveroldali token-validáció nem opció, hanem az egyetlen pont, ahol a védelem érvényesül. Emellé kell a rate limiting (annak korlátozása, hány kérést fogadunk el egy forrásból adott idő alatt), egy vagy több honeypot mező (rejtett űrlapmező, amit ember nem lát és nem tölt ki, egy bot viszont igen; ha ki van töltve, eldobjuk a beküldést), és a mérés, hogy lássuk, mennyi spam jut át. Ezek egyike sem a widget dolga.
És ott a vendor-függés. A Turnstile a Cloudflare-höz köt: ha náluk fennakadás van, a te formod védelme is akadozik. Ez nem a Turnstile hibája, a reCAPTCHA ugyanígy a Google-höz köt; csak érdemes tudatában lenni, hogy egy külső szolgáltatóra bíztunk egy folyamatlépést.
Ebből az is következik, hogy a reCAPTCHA vagy más megoldás továbbra is jó válasz lehet. Ha a cég stackje már mélyen Google-központú, ha enterprise szintű támogatásra, részletes kockázatelemzésre vagy szerződéses garanciákra van szükség, vagy ha a csapat már régóta ismeri és üzemelteti a reCAPTCHA-t, a váltásnak nincs feltétlen üzleti haszna.
Döntési szempontrendszer
Ha egy B2B cég most áll ugyanezen döntés előtt, öt szempontot érdemes mérlegre tenni, nagyjából ebben a sorrendben.
- UX és konverzió. Mennyibe kerül egy lead, és mennyi súrlódást bír el a beküldés? Minél értékesebb és ritkább egy kitöltés, annál drágább minden extra lépés, és annál többet ér a jellemzően láthatatlan ellenőrzés.
- Adatvédelem. Milyen adat kerül hova, és milyen tájékoztatással? Európai közönségnél és B2B kontextusban az számít, hogy a bot-védelem összhangban legyen a cég adatkezelési elveivel, ne csak működjön.
- Meglévő stack. Mihez illik a választás, és mit ismer a csapat? Egy Cloudflare-t amúgy is használó infrastruktúrába a Turnstile természetesen simul; egy Google-központúba a reCAPTCHA.
- Support és enterprise igény. Kell-e szerződéses garancia, kockázatelemzés, részletes naplózás? Ahol igen, ott a szolgáltatásszintű megállapodás fontosabb lehet, mint a widget kényelme.
- Költség és skálázódás. Meddig ingyenes, és mi történik nagy forgalomnál? A Turnstile-nál nincs mennyiségi küszöb; a reCAPTCHA ingyenes kerete korlátos, és nagy forgalomnál a skálázódás fizetős enterprise szintre visz. Nagy kérésszámnál ez érdemi különbség lehet.
A saját esetünkben ezek a szempontok a Turnstile felé billentek: a súrlódásmentes, jellemzően láthatatlan élmény és a kevesebb harmadik félnek továbbított adat többet nyomott, mint a reCAPTCHA megszokottsága. Ehhez jött a költség: a Turnstile ingyenes, forgalmi plafon nélkül, míg a reCAPTCHA ingyenes kerete korlátos, és nagy kérésszámnál a skálázódás fizetős szintre visz. De a döntés érdemi része nem itt dőlt el. Attól, hogy a widget láthatatlan és kényelmes, a CRM-ünk pontosan annyira védett, amennyire a szerveroldali validáció, a rate limiting és a honeypot meg van írva mögötte. A widget cseréje egy délután munkája; a mögötte lévő fegyelem nem az, és nem is lehet kiszervezni egy szolgáltatónak.
Két tanulság marad tehát, és a második a fontosabb. Az első, hogy a form védelme a szerveren dől el, nem a gombon. A második, hogy a bevált eszköz nem örökre bevált. A reCAPTCHA jó választás volt, amikor bevezettük, és lehet, hogy másnak ma is az; a hiba nem az lett volna, ha maradunk nála, hanem ha meg sem kérdezzük, miért. A rossz default ára ugyanis láthatatlan: nem csörög, nem hibázik, csak csendben, elszalasztott jobb megoldásokban gyűlik. A megkérdőjelezése ezzel szemben olcsó, sokszor egy délután. Ez a lehető legrosszabb arány egy döntésben: olcsó megnézni, drága nem megnézni, és épp ezért marad el a legtöbb helyen.
A hasznos kérdés tehát kettős. Rövid távon az, hogy hol dől el nálad a form védelme: a válasz majdnem mindig a szerveren van, nem a gombon. Hosszú távon pedig az, hogy melyik eszközödet használod évek óta úgy, hogy jól működik, és épp ezért nem nézted meg régóta, van-e nála jobb. A defaultok ott a legveszélyesebbek, ahol a legrégebben nem gondoltál rájuk.
