Ako zmiasť roboty komentárového spamu?
# Jirka Chomát: Komentářový spam útočí
# Honza Hučín: Funkční javascriptová bariéra na komentářový spam
# PHP triky: Riešenie fantómovým tlačítkom
Zaujímavé metódy a debaty o komentárovom spame, no *jedno triviálne riešenie už existuje.* Bohužiaľ počas celého minulého roku sa všetci venovali sofistikovaným riešeniam a tak ste aj dopadli. Skúste zapojiť do práce niečo, čo nástroje komentárového spamu nevedia a zrejme moc dobre v blízkej budúcnosti ani nebudú vedieť (museli by si napísať interpreter javascriptu).
Moje riešenie je veľmi blízke riešeniu z Diskusie o webe, ktoré má iba jedinú chybu (prílev dát nezastavuje – iba ho účinne filtruje). Moje riešenie zamedzuje aj zbytočnému toku dát od spamových robotov.
Jedna vec je, že ofiltrujete obdržané dáta. druhá vec je, že spamersky robot už tie dáta poslal, čiže *zbytočne „zatažil“ server.* V istých prípadoch to može mať svoje dôsledky (napr. vyčerpáva dátovy limit hostingu, zdroje servera atď). Poviete si, že je to zbytočné riešiť ale uvedomte si, že spam momentálne prevažuje nad trafficom, ktorý urobia návštevníci (no dobre, nenačítava obrázky, takže nie je to jednoznačné) ale celkom určite po poslaní dát riešia skripty prijímajúce dáta nejaké operácie a ich réžia sa už počíta.
Keď pominieme účinnosť CAPTCHA ale nestotožníme sa s jej *otravnosťou* (prenášame problém na živého návštevníka), tak vhodným a ešte stále účinným riešením je *zapojiť do práce javascript.*
Interpreter javascriptu nie je triviálna záležitosť a harvestery vysosávajúce zo stránok FORM, ktorý je „skomplikovaný“ javascriptom *môžu byť zmätené.*
Pokiaľ akceptujeme javascript, tak musíme si uvedomiť, čo hľadá harvester stránok. *Hľadá tag FORM a v prvom rade jeho parameter ACTION.*
Môžeme javascript použiť na „neviditeľné“ vyplnenie položky nejakého poľa (to rieši Diskusia o webu). Tu harvester teda formulár vidí a teda vie adresu skriptu, ktorému sa dajú posielať dáta. Takže ho zaradí medzi obete a robot posielajúci dáta do toho skriptu teda posielať dáta bude (toto platí aj pre systémy používajúce CAPTCHA či „otázky“).
Benefitom týchto metód teda je odstránenie množstva komentárov „na schválenie“ či na vymazanie.
Pokiaľ však docielime, že harvester neuvidí adresu skriptu, ktorému môže posielať dáta, tak nás logicky *nemôže navštíviť žiadny robot s dátami,* ktoré by sa pokúšal poslať.
Teda ak zneviditeľníme adresu skriptu, môžeme si pomôcť. Za podmienky, že ako ďalší dôležitý krok urobíme PREMENOVANIE tohto skriptu, pretože Ďalšia veľká skupina robotov na spam proste naslepo skúša posielať dáta na defaultné umiestnenia a názvy skriptov pre prijímanie komentárov. Obmedzenie tohto typu robotov na spam vykonáme ešte tretím krokom a to odstránením všetkých „default“ známok použitia bežného a populárneho CMS (napr. zmienok o jeho názve z hlavičiek šablóny a pod.).
Riešenie, ktoré popisujem spočíva v týchto troch krokoch:
# odstránenie zmienok o použitom CMS (dôsledné odstránenie!),
# premenovanie mena skriptu, ktorý prijíma dáta komentárov z formulárov (a samozrejme prispôsobenie formulárov tejto zmene),
# nasadenie javascriptu na zneviditeľnenie značky FORM v šablónach.
Prvý bod zabezpečí nemožnosť dohľadať stránku zadaním spoločného reťazca pre weblogy založené na známom CMS. Druhý bod zabezpečí, že doterajšie databázy adries komentárových skriptov budú obsahovať už neplatnú adresu skriptu a dáta posielané priamo naň už nebudú prijímané. Tretí bod je najdôležitejší a spočíva v tom, že harvestery (skripty, ktoré lúskajú zdroják stránky a hľadajúce nové obete – adresy skriptov) nič nenájdu. Keďže hľadajú adresu skriptu a tá je parametrom tagu FORM, tak sa pokúsime vložiť tento tag aj s parametrami javascriptom.
Náš pôvodný riadok s FORM môže vyzerať takto:
<FORM action="http://example.org/ps-example.php">
Tento nahradíme volaním javascriptu a najjednoduchšie napríklad takto:
<script type="text/javascript" language="javascript">document.write('<fo');document.write('rm met');
document.write('hod="post" action="http://example.org/');document.write('ps-');
document.write('example.php">');</script>
Vymyslite si kľudne aj zložitejšie programy – napríklad výpočet hodnôt, externe prilinkovaná funkcia. Čím viac variánt, tým horšie podmienky pre interpretovanie javascriptu niečim iným ako je prehliadač.
Okrem tohto riešenia je kopec ďalších možností – napr. posledné úpravy WordPressu na komentáre cez AJAX. Základ je však vždy ten istý – používa sa javascript. Neznámy jazyk pre harvestery, s ktorým si ešte neporadia.
Vysvetlivka: Harvestery – skripty, ktoré lúskajú webové stránky a hľadajú obete – skripty, ktorým môžu poslať dáta.
Zatiaľ mi ešte nikto zmysluplne nereagoval na toto moje riešenie a preto si domýšľam možné námietky:
# javascript zasahuje do kódu – áno, dokonca zneviditeľní tag FORM a vzniká tak možnosť nevalidného kódu. Pokiaľ na tom záleží, urobte si to tak, aby to validné bolo.
# budúce harvestery to zlomia – možno áno, zatiaľ sa im to viac ako rok nedarí.
# CAPTCHA je lepšia – určite je to prejav sofistikovaného riešenia, ktoré ukazuje Vaše geniálne schopnosti. Lenže presúvate prácu na filtrovaní spamu na čitateľa a spamové roboty vám dáta aj tak posielajú.
# Riešenie fantóm tlačítka, otázok a z Diskusie o webu fungujú – áno, samozrejme. A vo všetkých prípadoch ste nepozastavili prísun dát od spamových robotov. Napriek tomu tieto riešenia rešpektujem.
Nie je dôvod siahodlho diskutovať riešenia a nadšene výskať nad 4 dňovými výsledkami pokusov. Môj pokus trvá stovky dní a pár jedincov už zrejme moje riešenie nasadilo a sú spokojní.
Tak, tak, je to osvedcene, rovnakou metodou skrývam e-mail uz hoooodne dlho.
[1] asi si nerozumiem :) o emailovu adresu nejde :) aj ked zrejme sa chces pripojit k mase vyuzivacov javascriptoveho maskovania.
ide o vyriesenie komentaroveho spamu :)
[2] asi si nerozumieme :-) pisal som v komentari o pouziti javascriptu na skryvanie (to uz je jedno coho) a ze tato metoda, u mna vyskusana na e-mail dlhodobo, dobre funguje.
OT škvrny na slnku [1][3] už to chápem. Dvojnásobne.
[3] jasne, lenze momentalne ti to moze byt uriti, ci mas skryty mail na webe, ked hlavnym zdrojom pre obete spamu su schranky pouzivatelov postovych klientov, ktori si klikli na spamovy stroj v prilohe ci si ho doinstalovali nejakym programom.
a bohuzial voci tomu, ze kdejaky idiot ma tvoj mail v dorucenej poste sa uz neubranis.
Sposob to moze byt naozaj velmi dobry a ucinny, splna vsetk predpoklady az na tu validitu. Ak sa vyriesi aj tato „malickost“ bude to pomerne dobre riesenie.
[5] dakujem za poucenie, s internetom sa este len velmi zbezne oboznamujem, takze vrela vdaka ;-)
Tebe to mozno u riti je, mne nie, pretoze u seba vysledok vidim – ale to je uz OT.
A k teme – len som reagoval na tvoje rozpisanie sa o skryvani javascriptom a reagoval som prikladom o skryvani e-mailu (bez akychkolvek dalsich suvislosti alebo nesuvislosti), kde je toto uz dlhodobo odskusane – NIC VIAC NIC MENEJ.
[4] ked sa zamyslis, tak tam ziadne OT neuvidis.
[Vsetkym] Rony – ze skryvat form javascriptom…
Ja – ze ano, ze tato metoda skryvania je funkcna…
NIC INE MOJ KOMENTAR ZNAMENAT NEMAL… ALE AK JE VECNY DOPLNUJUCI KOMENTAR OFFTOPIC, TAK SORRY…
No tak tedy toto řešení považuji ze všech diskutovaných za bezkonkurenčně nejhorší a nejhloupější. Kam se na něj hrabe „nepřístupná“ a „nepoužitelná“ CAPTCHA! Páni programátoři, gratuluji, opět jste zvítězili nad uživateli svých výtvorů…
[8] Je fakt, ze toto riesenie je pravdepodobne nepristupne – dokazu citacky interpretovat JS? Druhe negativum je v onych 2% ludi ktory maju vypnuty JS. Resp. ake ine negativa taketo riesenie ma?
[7] raz ta prizabijem :-)
[8] Ano! Nepristupne a nepouzitelne. Napriek tomu si mi komentar vlozil. Jedine, co nemam overene je, citacka slepcov, ci interpretuje moj formular alebo nie. Napriek tomu splna moju poziadavku: spamu nevenovat ani sekundu a pritom mi nedat pricinu k zruseniu komentarov.
[9] ano, venoval som tomu tolko casu, ktory som povazoval za naozaj hranicny k tomu, aby som sa spamu venoval. Aj za cenu, ze budem mat kod nevalidny. 2% ludi bez JS su primerana dan vzhladom k pouzitiu na konkretnom webe.
Odhliadnuc od toho, ze validnost, pristupnost by som s tym mal dokazat dosiahnut (ale nechce sa mi v tom vrtat).
Citacky, ktore pouzivaju jadro Trident zrejme ano (akiste maju interpretaciu JS prevzatu z jadra).
A ked uz nic ine – obsah je pristupny, funkcia komentovania nie a cesta ako poslat vyjadrenie vsak je k dispozicii. Alebo inak: ak slepec nevidi cervenu farbu pruhu hore, tak holt nijako nedosiahnem, aby mu tato farba pristupna bola. Do tejto skupiny je zaradeny teoreticky nedostupny formular.
[10] Opravdu skvělé řešení a skvělá argumentace. Však co jsou nějaká procenta, že. Raději použiji své řešení, protože je moje, než abych uznal, že ostatní řešení jsou lepší a použil některé z nich…
[8],[9] Nie som clovek z IT branze, takze odbornu diskusiu prenecham Vam, pani. ;-) Ale co si cenim na Ronyho rieseni je pristup prevencie, ak to tak mozem nazvat. Vsetky ostatne riesenia hovoria o filtrovani dosleho spamu. Jedine Ronyho paradigma hovori o tom, ze spam nemusi chodit vobec. Mne – ako userovi – je jedno, ci riesenie bude postavene na javascripte alebo ci mi na moj blog posadite maleho modrookeho trpaslika s velkou cervenou bradavicou na nose, ktory bude harvesterom hovorit „sem sa nic neoplati postnut“. Zaujima ma pozadovany vysledok: ZIADEN komentarovy spam, nezatazovanie navstevnikov, minimalizacia zbytocneho trafficu. Mate v rukave alternativne riesenia, ktore splnaju tieto moje ocakavania?
[12] Ve svém hodnocení antispamových řešení se hrubě mýlíte. Všechna antispamová řešení, ať už jsou založena na CAPTCHA, JS nebo prostě jen na uspořádání formuláře, plní stejný účel a stejně efektivně. Ronyho řešení má jedinou výhodu – komentářový spam se neodesílá na server, takže „nezatěžuje“ stroj a linku. Tato výhoda je vykoupena nejvyšší možnou úrovní nepřístupnosti a nepoužitelnosti ze všech…
Jakou výhodu má Ronyho řešení pro autora weblogu? Žádnou. Mohlo by mít výhodu, pokud by blog byl hostován někde, kde je limit přenesených dat velmi, velmi nízký. Ovšem hostingy už přenesená data dávno neomezují, pokud nedosáhnou limitu jejich linek (což bývají gigabity za sekundu). Obrázky na vašem webu jsou na přenos mnohem náročnější…
Jakou výhodu má Ronyho řešení pro návštěvníka weblogu? Vůbec žádnou.
A teď k nevýhodám.
Jakou nevýhodu má Ronyho řešení pro autora weblogu? Několik procent jeho návštěvníků ho neobdaří komentářem. Jak důležité jsou komentáře pro autora, to si musí každý rozhodnout sám.
Jakou nevýhodu má Ronyho řešení pro návštěvníka weblogu? Nemůže odeslat komentář. Může se mu zhroutit prohlížeč (ano, skutečně může) a může tak přijít o cenná data, dokonce se mu může poškodit jeho vlastní PC.
Na závěr bych chtěl důrazně upozornit, abyste se nenechal zmást Ronyho falešným předpokladem, že odesílají-li se spamy na server, zatěžuje to nějak autora weblogu nebo správce serveru. Ano, mohlo by ho to zatěžovat, pokud by spam byl nucen číst – kdyby se někam ukládal nebo něco podobného. Ale to se ve skutečnosti neděje u většiny řešení a nemusí se tak dít ani u těch ostatních, záleží na preferencích. Já se třeba o spamu dozvím jen tehdy, když projde skrze všechny úrovně obrany. Můj návštěvník však nikdy nikde není obtěžován ani diskriminován…
[10] [11] Vy dvaja sa fakt nemate radi :))
[10] V podstate dalsie riesenia su tiez postavene na JS, ale rozdiel je v tom, ze ak clovek JS nema, nevadi, moznost vlozit komentar mu zostane zachovana. V tom je vlastne kamen urazu tvojho riesenia…
[14] To je ovšem velmi nebezpečný omyl. My proti sobě navzájem, proti svým osobám, nemáme ani to nejmenší. Můžeme spolu nesouhlasit v určitých konkrétních záležitostech (a mnohem častěji máme názor stejný nebo podobný), ale to přeci neznamená, že bychom se „neměli rádi“ nebo dokonce něco ještě horšího!
2 rony: Měl bych jednu konstruktivní připomínku. Pokud by se celý formulář nebo blok kódu s formulářem generoval přes JS, nevzniknou problémy s nevalidním kódem, ani potenciálně řádově nebezpečnější problémy s parciálním JS. Princip a funkčnost zůstávají přitom zachovány ;-)
[13] Dovolim si nesuhlasit! ;-) Vo svojom hodnoteni sa nemylim. :-) V prvom rade este raz zdoraznim, ze bez ohladu na efektivnost ostatnych rieseni je pre mna zaujimava hlavne Ronyho paradigma: nefiltrovat spam – jednoducho ziaden nedostavat. Vsetko ostatne v nasej diskusii je len technicky detail. Takze ak mi niekto predlozi ine (lepsie) technicke riesenie s rovnakou paradigmou, velmi rad ho vymenim za trpaslika… ;-)
[17] Jak už jsem napsal, ve svém hodnocení protispamových řešení se mýlíte, protože jste přistoupil na zcestný předpoklad, že ostatní řešení nutí autora weblogu se spamovým komentářem nějak zabývat. Ale to není pravda! Přečtěte si odkazované spoty, zjistíte, že ostatní řešení také zaručují, že autor weblogu či obecně webu nikdy žádný spam nedostane…
[16] ale ak ma clovek vypnuty JS, nebude moct odoslat komentar…
[18] Este raz – myslim, ze sa mylite Vy vo Vasom predpoklade, ze ja som pristupil na chybny predpoklad. ;-) Som si vedomy, ze bloger (väcsinou) nie je nuteny zaoberat sa komentarovym spamom. A nemam namiestky voci ostatnym antispamovym rieseniam. Nikdy som ani nespochybnoval ich efektivnost. Verim, ze mozu dosahovat vysoku uspesnost. Ale mne ide o princip, zakladnu filozofiu, paradigmu – pomenujte si to ako chcete. To, ze nase sucasne kapacity sposobuju, ze problem nevnimame ako problem, este neznamena, ze ho mame ignorovat. Spamerov by sme z principu nemali tolerovat. Preto sa mi Ronyho riesenie paci.
Je to velice zajímavé řešení, ale souhlasil bych s tou konstruktivní připomínkou Viléma Málka, kdy by možná bylo lepší, aby se kompletně celý formulář generoval JavaScriptem, čímž by bylo zaručeno, že nedojde kžádné havárii. Protě ten, kdo by měl vypnutý JS by formulář neviděl. Čili stejný výsledek, jako v předchozím případě, ale bezpečnější (myšleno bezpečnější z pohledu případné chyby prohlížeče).
fiha, dobra diskusia pani, kazdeho si podrobne precitam, konecne mam doslednejsie vyjadrenia k mojmu rieseniu.
[13] ano, zvazil som vsetky nevyhody. dve mozne percenta pripadov, kedy by som mohol sposobit problemy mi stoja za dusevny pokoj, ktory som nemal pri sledovani statistik z bayesianskeho filtra. Aplikovanie „otazky“ znamenalo studovat niekolko hodin funkciu skriptov v CMS. Captcha je stale u mna neaplikovatelna. Nemozem sa ani hadat kolki navstevnici sa na vyplnanie otazok ci cisel z obrazkov proste vykaslu a nedokazem to porovnat s tym, co som mojim riesenim skomplikoval ja.
[14] nie nie je to tak. Vilemove nazory si vazim. Ked sme v rovine vecneho nesuhlasu, tak je to motor vyvoja :-) Nuti ma to zamysliet, inak si po vacsinu casu myslim, ze som genius, a to mi nerobi dobre ;-) tak ako v [15] Vilem povedal.
[16] ano, to som naznacil, ze teraz to mam nevalidne ale mozem to riesit komplet v js. resp. dokonca pouzit AJAX na vtlacenie formu do kodu. To su legitimne (teraz uz ano) nastroje, ktore su BEZNE pouzivane pocnuc gmailom konciac modnym web20 na hocaku prkotinu :-) Ano, naznacil som riesenie a jeho dokonalost je vecou formalizacie.
[17] ano, ja som sledoval co najmensie zatazovanie mojej osoby spamom. Akekolvek ine riesenie mi prinasalo „nervy“.
[18] u mna ano, vsetky ostatne o hodny cas dlhsie. Ale to je moj pripad. Aj ked osobne by som si aj CAPTCHA postavene na tacke asi zrusil pretoze si myslim o nej svoje :-) (je to riesenie pre seriozne weby, kde sa nemoze pouzit pristipkarske riesenie).
[19] ano, a to mi nevadi, moznost ma kontaktovat som ponechal. Mohol by som to vyriesit trosku inak. No v dobe, ked dominuje gmail si js kto vypina? Na druhu stranu, nieco by sa vymysliet dalo – napriklad ak nie je js, tak sa zobrazi „komentare nie su, poslite mi email“.
[20] ja s nimi nechcem zit tak, ze mi 50% trafficu robia ich stroje. A ze mi ho robia.
[21] Ano, je mozne ho vylepsit, ja by som tvrdil, ze externym js, ktory by roznymi fintami (vypocitavanie vkladanych hodnot zo vzorcov a pod.) nakoniec vlozil formular cely. Bohuzial v inteligentnych a nenarocnych „kryptovacich“ vypoctoch sa az tak nevyznam, aby som vedel spravit riesenie schodne aspon na velkej trojke IE/FF/Opera.
Velmi pekne dakujem zucastnenym za naozaj vybornu diskusiu.
[13] Vileme, k tomu datovemu limitu – verim, ze hostingy su uz take alebo onake. Prax mi vsak ukazuje, ako sa v niektorych momentoch proste zrutia. Prikladov z poslednej doby mame kvantum.
Moze ist o debilne napisane CMS, ktore mnozstvom dotazov ustve SQL databazu, prekroci preventivne limity Apache servera, nastartuje IDS strazcov a zalarmuje adminov k ochrane pred DoS. Vsetky tieto veci som zazil na vlastnej kozi alebo som ich sledoval a su vysoko realne. Nikto ma nepresvedci, ze komentarovy spam ma klesajucu tendenciu a ze nemoze ohrozit hostingove servre. Nemusia fyzicky padnut, ale mozu sposobit limitne stavy.
[24] Porovnal bych dvě řešení – JavaScriptem vkládaný formulář ala rony a „dvojtlačítkový“ formulář ala Interval.cz.
.
Jak to funguje:
.
Rony: Formulář se vloží JavaScriptem. Současný spambot ho nepřekoná a tak žádný spam nezasílá nebo se ho pokouší zasílat na adresy známé z masově rozšířených CMS.
.
Interval.cz: První tlačítko ve formuláři požaduje náhled vloženého příspěvku, teprve druhé příspěvek skutečně vloží. Spambot ovšem odesílá všechna talčítka (nebo to první), takže jeho příspěvek se mu nikdy nikam nevloží. Spambot ovšem dostane stránku, ve které je jeho příspěvek obsažen, takže je spokojen a zmizí (a nezkouší žádné podfuky).
.
Nevýhody pro uživatele:
.
Rony: X % uživatel příspěvek nevloží, některým může stránka způsobit problémy.
.
Interval.cz: Žádné.
.
Nevýhody pro provozovatele webu:
.
Rony: Žádné.
.
Interval.cz: Na server se odesílá spam a z něj náhled. Zabírá se přenosová kapacita, na jednu transkaci asi 20 kB, tedy ekvivalent jedné ikonky či menšího obrázku. Také se mírně zatíží server (žádné SQL operace tady nejsou, vše se kešuje). Teoreticky je možné, že nějaký spam proklouzne až ke správci, který ho bude nucen číst (za tři roky necelých deset případů).
.
Souhrn:
.
Ze zkušenosti s Interval.cz mohu říci, že naše řešení vytváří jen minimální zátěž, která je v celkové režii serveru neměřitelná – a čím větší server je, tím menší je také tento podíl zátěže. Podle mého názoru by mělo dostat přednost řešení, které nezatěžuje uživatele. Nikdy bych se neodvážil aplikovat JavaScriptové řešení, když ho mohu nahradit jiným, které je navíc nenásilné a nenarušuje strukturu webu jako celku (na rozdíl od různých nadbytečných políček násilně vkládaných do formuláře).
[25] Nevýhody pro uživatele:
Interval.cz: Po odoslaní príspevku počkať na zobrazenie náhľadu a opätovne potvrdiť príspevok… Nehovoriac o zmätení návštevníka pri ďalšom kliknutí na „Zobrazit náhled“ ktoré je umiestnené ako prvé, alebo po odoslaní formulára s nevyplnenými údajmi „Jméno“ a „Předmět“ na ktorých nutné vyplnenie nie je návštevník dopredu nijako upozornený… Inak nemám námietky…
Zložitejšie riešene: JS ktorý by príspevok automaticky vložil bez zobrazenia náhľadu, pri nefunkčnom JS by sa náhľad zobrazil – vznikol by tak hybrid interval/JPW, ktorý by trošku zaťažoval server (ako na intervale) ale neotravoval návštevníka pokiaľ netreba (ako na JPW) V podstate by teda nič neriešil…
Osobne si myslím že najlepšia verzia s tu popísaných pre rýchle vloženie príspevku je Javascriptom vygenerovaný celý form s textom informujúcim o nutnosti JS pre možnosť komenovania článkov, prípadne uvedenou nejakou alternatívou…
Pre stránky kedy je vhodné aby návštevník mohol skontrolovať príspevok je jednoznačnou voľbou riešenie ala interval, len s upozornením na vyplnenie povinných položiek a krátkeho textu (popis odosielacieho tlačítka nestačí) ktorý informuje že návštevníkovi sa najprv zobrazí náhľad, až potom vloží komentár
[26] Nutnost nejprve po sobě příspěvek zkontrolovat a teprve poté ho vložit je na serveru záměrně. Je to velmi efektivní ochrana proti komentářovému spamu produkovanému lidmi, kteří pociťují potřebu vkladat komentáře typu „Tý vole!“ nebo „sxgv,nsflg“ a podobně. Navíc je server určen pro odbornější publikum, takže se domnívám, že popis tlačítka „Zobrazit náhled“ je zcela dostačující ;-)
.
Upozornění na nutnost vyplnit jméno a předmět zvážím. Sice je na to uživatel upozorněn po odeslání a sice o svůj příspěvek nepřijde, takže mu stačí to jméno nebo předmět doplnit, ale v zájmu přístupnosti by to tam asi mělo být ;-)
Kdyby Rony udelal prijimaci scripty pro ulozeni dat z formulare 2(dva!), mohl by byt spokojen i Vilem, i Rony.
Prvni sript by byl napsan do HTML formulare jako action=“http://prijimaci.script.cz“ a ten by fungoval s vypnutym javascriptem a obsahoval vy vesechny ty hnusne, ale pristupne opruzy jako CAPTCHA a dvoji odesilani aĺa Vilem.
Druhy script by mel URL hodne podobne, ale delsi, s parametrem, ktery by vsechny ty opruzy vyloucil. Ten parametr by se vkladal ronyho javascriptem.
Kdo nema vyply javascript, komentuje bez opruzu.
Spambot se chyti na prvni URL bez parametru a spokoji se s nahledem.
Genialne jednoduche :-)
[28] Napadlo mě, že čím víc budeme používat JS na ochranu před spamboty, tím lépe ho roboti zvládnou, až v tom budou lepší než lidé a jejich prohlížeče (jako se to stalo technologii CAPTCHA).
.
Na druhou stranu, žádné dva formuláře nejsou stejné a nijak se nedá zjistit, které pole je nutno vyplnit, které vyplněno být nesmí a které odesílací tlačítko příspěvek uloží – nebo co s ním vlastně udělá.
.
Takže JS bude dřív nebo později překonán, ale rozumná konstrukce formuláře bude na spamboty zabírat i nadále…
[29] myslis si, ze implementuju cely interpreter javascriptu? pokial bude nejaky k stiahnutiu a pouzitiu k dispozicii, tak to urobia.
nefunguje mi to… aj som zmenil adresu skriptu, aj tak som dostal sprsku spamu do hodiny…
[30] Existují projekty, které interpretují JS – využívat je začínají vyhledávače. A když taková technologie bude volně k dispozici, proč by ji nepoužili spameři, kteří na tom, konec konců, vydělávají?
[31] hod adresu tvojho webu.
urobil si VSETKY tri body?
naozaj si to urobil dosledne?
pozrieme, uvidime.
som puk, funguje to, zatial.. som sice presmeroval skript, ale ten povodny som nezmazal zo servera..:)
[34] neponechavaj povodne meno skriptu, priamo do neho ti viem poslat data.
neviete interpretovat JS ? HA! ved nie je problem spravit robota, ktory bude virtualne browsit, rony sa vyzna, takze:
www::mechanize – len na explorer, nieco podobne je aj na mozillu, cele to moze bezat vo virtual X (ta mozilla:).
Je pravda, ze sa to ale nerobi, ale myslim, ze coskoro s tym zacnu, ak takychto JS bude priliz vela.
Ale ako napad to nie je zle, uznavam.
[36] problem mozno je v tom, ze to bude trosku narocnejsie. Mozem spravit JS, ktory bude pre ziveho navstevnika neskodny ale jemu to pretazi stroj. Dokonca mozeme konecne vyuzivat rovnake zbrane a napadat dierami IE stroje spammerov :-)