Experiment s maskováním e-mailů před roboty

Jak účinně zamaskovat e-maily před zraky spamových robotů? To měl zjistit půlroční experiment. Jenže výsledky jsou docela překvapivé.

Trocha teorie

Důležitým zdrojem, kde spammeři získávají e-mailové adresy, jsou webové stránky. Těmi procházejí roboti a adresy hromadně extrahují. Proto se doporučuje zapisovat e-maily ve formě pochopitelné člověku, avšak nepochopitelné stroji. Například ve tvaru franta (at) example.cz. Jenže i tento zápis může některým lidem připadat matoucí, naopak robot se mu může přizpůsobit. Proto se vymýšlejí stále sofistikovanější způsoby, jak adresu zakamuflovat (klíčové slovo: obfuscate email).

V této souvislosti se pochlubím s nápadem, jak neviditelně zastřít e-mail pomocí HTML komentáře. Použil jsem ho v Texy2 a nahradil jím méně přístupné (at) zavináče z Texy 1.

Jenže je otázka, jak chytří spamoví roboti skutečně jsou? Který způsob maskování je dostatečný? Proč to nevyzkoušet.

Roboti pod lupou

Jako pokusného králíka jsem použil tento blog. GTPR 6 a cca 350 stránek obsahu by mělo škodnou přilákat.

Protože jsem od robotů žádné zázraky nečekal, nejprve jsem ověřil, jestli vůbec převádějí HTML entity na znaky (v řeči PHP: zavolají html_entity_de­code). Pokud by je totiž zmátlo primitivní používání entit, nemusel bych experimentovat dál.

Na všechny stránky La Trine jsem na půl roku umístil skryté pastičky:

// 1) nechráněná e-mailová adresa v textu stránky
<a href="mailto:foo">test@example.com</a>

// 2) nechráněná e-mailová adresa jako odkaz
<a href="mailto:test@example.com">foo</a>

// 3) "mailto:" chráněné HTML entitami
<a href="mai&#108;&#116;&#111;&#58;test@example.com">foo</a>

// 4) zavináč chráněný HTML entitou
<a href="mailto:test&#64;example.com">foo</a>

// 5) kombinace bodů 3) a 4)
<a href="mai&#108;&#116;&#111;&#58;test&#64;example.com">foo</a>

Test ukázal, že náhrada zavináče HTML entitou je zcela dostačující ochranou. Po půl roce dorazily jen tři spamy! A to ještě mohl mít na svědomí slovníkový útok.

Tím bych mohl článek ukončit. Nejlepší prevence se jmenuje @. Jenže…

Skutečné zdroje e-mailových adres

Jak jsem zmínil, do pastiček č. 4 a 5 spadly jen tři spamy. Návnady č. 2 a 3 přilákaly 85 kousků a prim pochopitelně drží zcela nechráněný e-mail se 126 zářezy.

Jenže, 126 spamíků za půl roku je nějak podezřele málo. Do mé schránky jich víc dorazí za jediný den! Jak je to možné?

Po pravdě, netuším. Nejspíš se webové stránky staly zcela okrajovým zdrojem e-mailových adres. Spameři už loví jinde. Možná se zaměřují na malware, který šíří do cizích počítačů. Záškodnický program pak sám rozesílá spam a e-mailové adresy čerpá z poštovních klientů (adresář + doručená pošta). Nebo je to úplně jinak…

---

Související:

• La Trine: 203 kusů za den a stoupá

Den zúčtování s XHTML

Všechno je jinak. Ti, co měli pravdu, nám lhali, zatímco kacíři to s námi mysleli dobře.

Prolog

Začátkem letošního roku napsal Chamurappi na Lupu poměrně neaktuální článek Soumrak nad moderním X. Má smysl ještě dnes vyvracet dávno vyvrácené mýty o XHTML? Ptal jsem se sám sebe. K mému překvapení se pod článkem rozhořela plamenná diskuse plná emotivních výkřiků, které mě vrátily do dob nejtvrdší evangelizace. Pochopil jsem, že za ty roky mýty spíš zakořenily.

Laikům budiž odpuštěno. Jenže v oné diskusi dostala také řada osobností domácího webdesignu příležitost se historicky znemožnit. Dostala a využila. Přiznám se, že jsem to dlouho nemohl rozdýchat. S odstupem času to vnímám jako důležitou životní zkušenost.

Dějství první

Jak se blížilo desetileté výročí vývojového patu XHTML & CSS, přemýšlel jsem, jak k němu vůbec mohlo dojít. Jak je možné, že v době neomezené celosvětové komunikace není lidstvo schopno řešit technické záležitosti? Vlastně celkem banální. Co je HTML markup proti sestavení vesmírné rakety? Neschopnost řešit humanitní problémy je pochopitelná, ale i technické?

Získal jsem pocit, že hlavní mozky W3C trpí syndromem mrtvého koně. Cválají dál na oři jménem XHTML a nechtějí si připustit, že už je napůl v salámu. Že drakonickým pravidlům XML specifikace nelze v reálném světě dostát. Že DTD má příliš slabé vyjadřovací schopnosti, přičemž umí spoustu věcí značně zkomplikovat. Ale hlavně, že autorům webových stránek slavné XHTML vůbec nic nedalo. Ačkoliv touží po tolika nových vlastnostech, počínaje lepšími formuláři, konče třeba elementem pro video.

Pak jsem si uvědomil, že onou neschopností netrpí jen W3C. Dnes a denně jsme obětí jiné neschopnosti – neschopnosti vylepšit e-mailový protokol a zbavit se tak tun spamu. A podobných příkladů lze najít celou řadu. Začalo mi docházet, že problémem ve stáji W3C nebude zesnulý hřebec. Oči mi otevřela zmíněná diskuse na Lupě. Problémem je komunikace. Tedy příliš mnoho komunikace. Komunikující komunita. Největší význam pro rozvoj civilizace má jedinec. Komunita je mor.

První verzi HTML vymyslel jeden chytrej chlap. Jakmile se dalo dohromady hodně chytrejch chlapů, dopadlo to prachbídně.

Poznámka: jak začnete úvahy rozvíjet dál, zpochybníte si i principy demokracie. Dnes je mi hodně blízký Aristoteles a sympatizuji s jeho třemi právními formami státu.

Dějství druhé

Kupodivu i v oboru webdesignu se našel jednotlivec s ambicemi spasit HTML. Ian Hixie Hickson se pro mě stal jiskřičkou na konci tunelu, a to i přesto, že s mnoha jeho názory se neztotožňuji. Jenže, je chytrej, má obrovské zkušenosti a hlavně – je to jednotlivec Holt komunitám nevěřím. Teď, v době Webu 2.0 

A pak se to stalo! Pak to bouchlo! V květnu W3C adoptovalo HTML 5, vypiplané dítě Iana Hicksona. Mezi řádky lze číst, že tím vlastně odpískalo projekt XHTML. Nikdo to nahlas neřekne.

Ještě před pár lety se na HTML vs. XHTML vypisovaly kurzy přesně opačné. Neuvěřitelné se stalo skutečností.

(pro srandu králíkům, srovnejte úroveň diskusí pod oběma odkazovanými články na Lupě)

Epilog

Chamurappi může prožívat obrovskou satisfakci. Dlouhé roky upozorňoval na vady X-specifikací a byl za to nelichotivě častován. A najednou mu historie, jindy tak nespravedlivá, dala za pravdu. Vlastně se divím, že na Webylonu letošní převrat vůbec nereflektoval. Mohl napsat: „já vám to celou tu dobu říkal, vy pitomci.“ Měl by na to právo.

Je docela zvláštní, že o novém svěžím větru informuje pouze Martin Hassman. Nu což, dělá to výborně. Také mám v plánu o HTML 5 občas psát. Z toho téma sálá nadšení a pocit naděje.

Jo, a co na to Daniel Dočekal? Inu, jako vždy 

The stretched buttons problem in IE

As you might know, web forms have to by styled with care, since their native look often is the best you can achieve.

That said, sometimes even default look has its bugs. A truly flagrant mistake concerns buttons in Internet Explorer (including version 7) in Windows XP. If the button's caption is too long, the browser produces such a nasty thing:

…pokračování

Problém širokých tlačítek v IE

Jak již víte, webové formuláře je potřeba stylovat opatrně, protože už jejich nativní podoba bývá často tím nejlepším, čeho lze dosáhnout.

Někdy má ale i výchozí podoba své mouchy. V komentářích k předchozímu článku se jako problematické ukázalo zarovnání checkboxů s popisky ve Firefoxu. Skutečně hrubá chyba se však týká tlačítek v Internet Exploreru (včetně verze 7) pod Windows XP. Je-li popisek na tlačítku dlouhý, vyčaruje prohlížeč takový zlý, nepěkná věc:

(vyzkoušejte si)

Jde o kombinaci hned dvou chyb:

• tlačítka jsou zbytečně moc široká
• velká tlačítka se vykreslí zubatě a divně

S druhou chybou asi nic udělat nepůjde. To je prostě chyba ve vykreslovacím jádře prohlížeče a lze ji leda reportovat vývojářům a doufat, že třeba někdy…

Zajímavé je, že čím je tlačítko širší, tím ošklivěji se vykreslí. Takže vyřešením první chyby, tj. donucením Exploreru, aby tlačítka zúžil na odpovídající šířku, by se měl zmírnit či dokonce odstranit i efekt zubatého vykreslení. Uvidíme.

Zužujeme tlačítko

Pokusy nastavit různé hodnoty pro width nebo padding k ničemu nevedly. V takové chvíli se webdesigner uchýlí ke střelbě naslepo v podobě experimentování s CSS vlastnostmi jako display, overflow, position atd. Ukázalo se, že nápravu sjedná overflow: visible. Pak ale tlačítko těsně obepíná popisek, takže je záhodno ještě doplnit padding.

input.button {
    padding: 0 .3em;
    overflow: visible;
}

A vidíte? Zúžení tlačítek zcela eliminovalo vykreslovací vadu u druhého z nich, v případě třetího ji alespoň zmírnilo.

Pocit vítězství nad digitálním nepřítelem jsem si vychutnával přesně do chvíle, než jsem formulář s dlouhým tlačítkem naformátoval do tabulky a ejhle:

Ačkoliv se tlačítka vykreslují se správnou šířkou, v tabulce zabírají své původní místo. Problém vyřeší width:0. Jenže lepší prohlížeče (Opera, Firefox) nulovou šířku skutečně respektují, je tedy nutné použit IE-only hack. A to už je známá pohádka. Buď dát za vděk vylepšenému „podtržítkovému hacku“, tedy =width:0 (pro IE7 je nutné podtržítko zaměnit například za rovnítko), nebo oddělit styl pro IE pomocí podmíněných komentářů.

Zabrousil jsem na Google a pokusil se najít jiná řešení. Stejný zápas absolvoval jistý Jehiah Czebotar a po třech kolech s pomocí čtenářů došel k velmi podobnému výsledku, ale s jednou elegantní fintou navíc!

Zde je řešení:

/* chyba roztazenych tlacitek v IE pod WinXP */

input.button {
    padding: 0 .25em;
    width: 0; /* pouze pro IE */
    overflow: visible;
}

input.button[class] { /* IE ignoruje [class] */
    width: auto;
}

Finta spočívá v odlišení lepších prohlížečů od IE7 validní cestou. Díky tomu není potřeba „rovnítkový hack“ ani extra soubor se stylem. Kód tedy můžete použít pro všechny prohlížeče. Enjoy!

---

Související:

• La Trine: Dokonalé stylování formulářů
• La Trine: Ještě dokonalejší stylování formulářů

Ještě dokonalejší stylování formulářů

Před nějakou dobou jsem naznačoval, jak dokonale nastylovat webový formulář. Pointou bylo, že formuláře je nejlépe nestylovat vůbec. Nechat je vykreslit prohlížečem v přirozené podobě.

Nijak jsem tehdy své tvrzení nepodložil. A to dnes napravím.

Je důležité si uvědomit, jak je ona výchozí podoba ve skutečnosti křehká. Třeba takové tlačítko. Ve výchozí podobě ve Windows XP vypadá pro každého uživatele maximálně srozumitelně, esteticky je na úrovni a hezky reaguje na události myšky:

Nicméně stačí jen velmi drobný zásah do stylu a celé kouzlo se rozpadne jako domeček z karet. Například nastavíme barvu pozadí (v podstatě na výchozí hodnotu).

input { background: ButtonFace }

A výsledkem je tento skok do grafického pravěku:

Co z toho plyne? Barvu pozadí nenastavovat. Ale pozor, pokud explicitně neurčíme barvu pozadí, tak o ní nic nevíme – může být šedá, bílá nebo třeba černá. Z toho důvodu nemůžeme nastavit ani barvu písma. Jen ta výchozí bude správná.

Stejné dílo zkázy způsobí i hrátky s border, nebo celou řadou dalších vlastností. Ale pozor. Netýká se to jen tlačítek, nýbrž všech prvků formuláře!

Margin a jeho přítel padding

Zdaleka nejde pouze o barvičky. Takto hezky vypadají obyčejné nestylované zaškrtávací políčka ve Firefoxu pod Windows XP:

No uznejte, co jim chybí? Stačí však drobný zásah do jejich křehké symbiózy, například zkur nastavení vlastnosti margin…

input { margin: 0 }

…a to dokonalé horizontální zarovnání ovládacích prvků s popisky je minulostí:

A není cesty zpět. Ztracenou rovnováhu už žádným CSS nezachráníte. Srovnáte účaří v jednom prohlížeči, rozbité bude v jiném. Můžete nad tím spekulovat celé hodiny. Já vám radím – užijte ten čas nějak lépe a prostě formuláře nestylujte.

Resetování CSS

S tímto velmi úzce souvisí takzvané hvězdičkové resetování kaskádových stylů. Jde o kód, který se přidá na začátek každého stylu…

* {
  margin: 0;
  padding: 0;
  border: none;
}

…čímž se formuláře domrví nejen snadno a rychle, ale také nenávratně. Chytří už vědí. Chytří neresetují 

---

Související:

• Styling even more form controls – přehlídka vlivu stylování formulářů na různé browsery
• La Trine: Dokonalé stylování formulářů
• La Trine: Problém širokých tlačítek v IE