bardóczi ákos @post.r

Egy nemrég megjelent publikáció szerint, amiben novellák, regények és más irodalmi művek ezreit elemezték főleg az ún. szentiment analízis módszerére támaszkodva megállapították, hogy a világirodalomban kortól és kultúrától függetlenül mi tett egy-egy irodalmi alkotást klasszikussá.

Maga Vonnegut már az 1990-es évek derekán feltételezte, hogy a legnagyobb műveknek lehetnek közös jellemzői, kérdéses volt, hogy ezt sikerül-e valaha kimutatni kvantitatív módszerekkel. A kutatók arra jutottak, hogy a világirodalom legnagyobb műveiben maga a sztori – ha jól értem – bizonyos emocionális íveket tesz meg, ennek megfelelő érzetek sorozatát kiváltva a befogadóban függetlenül attól, hogy azt olvassa vagy például filmen nézi. Összesen hat ilyen patternt sikerült azonosítani, a teljes cikk [The emotional arcs of stories are dominated by six basic shapes ] nem éppen könnyed olvasmány,  barátságosabb változata a MIT Tech Reviewban jelent meg nemrég. 

Személyes véleményem, hogy az adatelemzés módszerei már nem is olyan kevés ideje rendelkezésre álltak ugyan, valójában csak néhány évvel ezelőtt, a cloud computing általánossá váltásával vált elérhetővé olyan mértékű számítási kapacitás elérhető áron, ami elhozta azt, amit ma big data-érának nevezünk.

Ebbe a világba engedett egy mélyebb, messzemenően szakmai betekintést a közel két hónappal ezelőtt megtartott Nextent által támogatott Big Data Universe 2016 konferencia Budapesten, az előadások közül három, egymástól nagyban eltérő felhasználási területet emelek ki példaként.

Ma már gépi tanulást használó algoritmusok segítik az informatikai biztonsági incidensek kezelését, ami természetesen csak akkor lehet hatékony, ha az valós időben történik. A magatartás-elemzésen alapuló behatolásérzékelő Blindspotter ha átlagosan 7 percenként ad ki riasztást szokatlan felhasználói aktivitás miatt, nyilvánvaló, hogy lehetetlen kivizsgálni ezeket külön-külön annak megállapításához, hogy valódi támadásról van-e szó.  

Egyre gyakrabban van szükség big datából átvett módszerek bevetésére a nyelvtechnológia területén is. Egyre gyakrabban felmerülő igény egy-egy óriáscég vagy például politikai párt számára, hogy képet kapjon azzal kapcsolatban, hogy hogyan is változott a tömeg velük kapcsolatos megítélése, aminek kézenfekvő adatforrása az interneten adott időintervallumban keletkezett, főként közösségi médiából származó szöveges felhasználói tartalmak elemzése. A pozitív és negatív jelzők megkülönböztetése már rég nem jelent problémát a nyelvtechnológia számára, viszont ettől még a feladat bőven rejt magában buktatókat.  

Ha elfogadjuk azt a tézist, hogy a big data valódi paradigmaváltás olyan szempontból is, hogy olyan mennyiségű információ kezelésére van szükség, amire a klasszikus módszerek nem alkalmasak, mik lehetnek azok, amik viszont igen? A megoldandó probléma jellegétől függően előfordulhat, hogy a legkomolyabb relációs adatbázis-kezelő rendszerek sem képesek elfogadható futásidő alatt annyi információt kezelni, amennyit szükséges. Itt lépnek képbe a gráf-adatbázisok. 

Ahogy írtam, ha átlagosan 7 percenként fut be egy-egy riasztás, esélytelen lenne mindről felelősségteljesen megállapítani, hogy valódi támadási vagy támadási kísérlet-e vagy egyszerűen csak akkor lefutó szkript miatt jelenik meg egy-egy anomália. Viszont közel sem annyira könnyű megállapítani automatizáltan, hogy szokatlan felhasználó magatartásról vagy ún. robotról van szó.  

A Balabit kutatói az ember természetes aktivitásának időbeli eloszlását veszik alapul.  

Számításba vették, hogy nincs olyan alkalmazott, amelyik folyamatosan dolgozna, míg szkriptek közt természetesen lehetnek olyanok, amiknek folyamatosan vagy bizonyos, pontos időközönként futnak le. Ez pedig markerként használható annak megállapításához, hogy Valamilyen tevékenység közvetlenül emberi eredetű vagy egyszerűen kódfuttatás eredménye.  

A robotdetektáló modul második fontos eleme ugyancsak az időre, mint adatforrásra támaszkodik. Egy húsvér felhasználó ha periódusonként vagy rendszeres időközönként is csinál valamit, azt időben nem annyira pontosan kezdi és fejezi be, mint egy robot, ezen kívül a tevékenység időbeli eloszlása mindegy ujjlenyomatként szolgál a felhasználó – vagy éppenséggel robot – azonosításához. 

Röviden szólva, a Blindspotter időben riasztást tud kiadni olyan esetben, ha az emberitől eltérő aktivitást észlel a hálózat valamelyik felhasználójánál.

A Neticle szentiment elemzéssel foglalkozó előadásában a hallgatóság megismerkedhetett a műfaj 10 szabályával. A szentiment elemzés egyszerűsítve annak gép feldolgozása, hogy egy-egy adott szöveg milyen érzelmi töltést tükröz, ami közel sem olyan egyszerű, mint amilyennek tűnik. Ugyanis a gép számára alapvetően teljesen strukturálatlan adathalmazt, az emberi szöveget kell elemezhető egységekre bontani, azokat kontextusában vizsgálni. Több buktató viszont csak a tényleges elemzés közben derül ki, például egy 2013-as kutatásban mutatták ki, hogy a felháborodott, negatív hangvételű, dühös vélemények határozottan jobban terjednek mint a neutrális vagy pozitív hozzászólásokban hordozott üzenetek.

Hasonlóan kihívást jelent megtanítani a gépet az irónia kezelésére és osztályozására.

Viszont a jelzős szerkezetek előtt álló negáció azonosítása mára már minden nagyobb nyelvben megoldott.

Nem meglepő módon a gépi alapú elemzés pontosságát nagyban befolyásolja, ha előre tudott, hogy mit is kell elemezni. Így például olyan kifejezés, ami más helyen előfordulva pozitív töltésű lenne, adott szövegkörnyezetben vagy topikban gyakorlatilag nem hordoz semmilyen töltést.

A szövegbányászok egyetértenek abban, hogy ma már nem csak bizonyos írásművek szerzőinek azonosításában lehet segítségükre a nyelvtechnológia, de bizonyos folyamatok akár elő is jelezhetők a hagyományos- és közösségi médiában megjelent tartalmak tömeges elemzésével. Így például már egy 2011. szeptemberében megjelent Nature-cikk is foglalkozott azzal, hogy akár az arab tavasz is elvben előre jelezhető volt, ahogy az az előadásban elhangzott.

A nyelvtechnológiai megoldásokon keresztül azon kívül, hogy elemezhető a múlt és előre jelezhető bizonyos pontossággal a jövő, a nagyobb nyelvek esetén jobb szövegek előállításában is segítséget jelenthet mindenkinek, aki ezzel foglalkozik. Ilyen alkalmazások például a Textio azzal, hogy szinonimákat ajánl az íródó szövegben vagy éppen a Toneapi ami az elkészült szöveg hangulati jellemzőivel kapcsolatban képes egy elemzést adni az újságírók, szerkesztők kezébe.

Az idei Big Data Universen elhangzott előadások diasorai itt érhetők el.

UPDATE: gráfadatbázisokról hamarosan egy másik posztban

Akár egy komolyabb fórumon folytatott vitában, akár az igényesen végzett kutatásban szükségessé válhat, hogy ésszerű energiabefektetés mellett meg lehessen állapítani egy adott kijelentésről, hogy ki is mondhatta először. Az első előfordulás megsaccolásának persze számos más területe is lehetséges. Hangsúlyozom, egy-egy kifejezés első előfordulását rendszerint csak megbecsülni lehet, ezek egyike sem bizonyító erejű.

Nem akarok túl elméleti felvezetéssel kezdeni, de érdemes tudni, hogy kapcsolódó, de más műfaj az etimológia, ami az önálló kifejezések eredetének feltárásával foglalkozik, ez természetesen magában foglalja, hogy egy kifejezés miből származtatható, hogyan alakulhatott és sokszor azt is, hogy mikor. Az etimológiai eszközökről viszont tudni kell, hogy egy-egy konkrét kérdést nem lehet velük felelősségteljesen megválaszolni mélyebb nyelvtudományi, nyelvtörténeti tájékozottság nélkül. A másik, hogy minél nagyobb korpusz áll rendelkezésre az adott nyelven, annál bőségesebb és pontosabb adatbázisokat tudnak kiépíteni a kutatók, viszont még a legtöbb természetes beszélővel rendelkező nyelvek esetén sem lehet minden kifejezésről 100%-os pontossággal megállapítani a származását és első előfordulását. A magyar pongyolán fogalmazva közepes írásbeliségű nyelv, viszont az etimológiai szótárak közt már több is elérhető a neten, ilyen például a Tótfalusi-féle etimológiai nagyszótár. 

Érthetően sokkal nagyobb információtartalommal feltöltött és régebbi, megkockáztatom, hogy az összes közül a legkomolyabb etimológiai adatbázis az Etymonline angol nyelvű változata, ami – az én ismereteim szerint – pontosságában még a több természetes beszélővel rendelkező mandarin kínai, hindi és spanyol etimológiai adatbázisok pontosságát is lepipálja.  

Na de mi a helyzet a gyakorlattal? Azaz amikor egy idézet első előfordulását szeretnénk megállapítani. Több eszköz is van, amik közül csak a legegyszerűbbeket említem.

A Google Keresőben adjuk meg a kifejezést idézőjelezve és/vagy válasszuk ki a verbatim keresési módot, ami jelezni fogja a kereső felé, hogy a kifejezés szó szerinti előfordulására vagyunk kíváncsiak. Ezt követően, precízebb találatot kapunk, ha nem a felajánlott opciókat használva, hanem keresőoperátor megadásával állítjuk be, hogy kimondottan időbeli előfordulásra vagyunk kíváncsiak.

Azaz ha arra szeretnénk választ kapni, hogy melyik dokumentumban fordult először elő az a kifejezés, hogy

szökik a málna

akkor a következő keresőkifejezést építhetjük fel. Az egyik valahogy így néz ki

"szökik a málna" before:2016/05/23

természetesen ha nincs találat, akkor a before: és az after: operátorokkal lehet játszani, ezzel szűkíteni a találati halmazt, ami fontos, hogy mivel keresőoperátorokról van szó, a keresőkifejezés literálja(i) után kell, hogy álljanak, csupa kis betűvel, kettősponttal. Ínyencek próbálkozhatnak még a daterange: operátorral, ahol Julianus-naptár szerinti értékkel kell megadni azt a dátumtartományt, amiben a kifejezést keressük.

Bizonyos esetekben hasznos lehet még a Google Trends bevetése, ami ugyan csak tömeges előfordulású kifejezéseknél hatékony, kiindulópontnak jó lehet például olyan szempontból, hogy mikor kezdte el foglalkoztatni a net népét az a téma, amihez az adott fogalom szorosan kapcsolódik.

Miért is kezdtem azzal, hogy csak saccolni lehet ezekkel az egyszerű módszerekkel, pontosan megállapítani az első előfordulást nem vagy csak kivételes esetben? A sok-sok ok közül az egyik az, hogy abban az esetben, ha a dokumentum, amiben a kifejezést elsőként szerepelt, már törölve lett, egy idő után a Google indexből is kikerül, így nyilván nem jelenik meg a keresési kifejezések közt, mint gyorsítótárazott tartalom. A másik ok, hogy a Google igencsak hasonlóan olvassa a webhelyeket, ahogyan az ember, márpedig szinte minden korszerű webhelyen vannak olyan dinamikus elemek, amik más-más tartalmat jelenítenek meg a külön-külön lapletöltések alkalmával. Kevésbé kocka módon fogalmazva: gyakorlatilag minden hírportál ajánlgat korábbi vagy éppen újabb cikkeket az alatt a cikk alatt, amit aktuálisan olvasunk, hasonló témában, amit persze a Google is figyelembe vesz. Ez viszont technikai szempontból azt jelenti, hogy hiába fordul elő például az

"részeg árvíztűrő tükörfúrógép támadt a súlytalan rugóra"

egy olyan posztban, ami mondjuk 2016. május 23-án jelenik meg, mivel nem egy statikus oldalról van szó, lévén, hogy közben újabb elemek jelennek meg a cikk alatt, amikor a Googlebot újra pásztázza az oldalt, az ő kis snapshotjához tartozó időbélyeget meg fogja változtatni egy későbbi időpontra, így olyan, mintha a kifejezést valójában csak később írták volna le. Megoldás: nincs mese, a találatok egy részét külön-külön meg kell nézni, és abban látható a poszt, twit, cikk, akármilyen bejegyzéstípus pontos dátuma.

Ezen kívül segíthet még az inurl: operátor, ha azt úgy adjuk meg, hogy az operátor után az URL-ekben gyakran előforduló formában adjuk meg a dátum egy részét. Példa:

"részeg árvíztűrő tükörfúrógép támadt a súlytalan rugóra" inurl:2016/05

persze több találat esetén az inurl: után megadott dátumnál egyre korábbi dátumokkal lehet próbálkozni, de szóba jöhet még az intitle: is.

Soha ne felejtsük el, hogy nem csak Google Search létezik a világon, más-más keresőkben más-más haladó keresési operátorok érhetők el.

Gépház üzen: a kérdésekre nem fogok tudni a megszokott sebességgel válaszolni pár napig :(

Minden olyan eset, amikor a szellemi tulajdonjog sérelme felvetődik, teljesen más szempontból lehet érdekes, az más kérdés, hogy engem személyesen annál jobban érdekel egy-egy ilyen ügy, minél magasabb szintű, ötletes, esetleg korábban még nem is alkalmazott bizonyítási eljárásokat vetettek be a bíróság előtt.

A mostani pont nem olyan, de azért nem mentes a tanulságoktól: a Mercedes-Benz, pontosabban a Daimler csoport ellen még 10 évvel ezelőtt indított pert egy magánszemély, mivel bizonyos Mercedes típusok fejtámláiban olyan nyakmelegítőt építettek be, amit az adott módon nem lett volna joguk, sértette Ludwig Schatzinger felperes szabadalmi jogait, ugyanis a Mercedes által használt megoldáshoz nagyon hasonlót Schatzinger még 1996-98 körül védett le, ha jól látom erről van szó. 

A kocsikat ráadásul továbbra is így reklámozták és hozták forgalomba egészen mostanáig. Ember nem hitte volna, hogy Góliátot legyőzheti Dávid, ha eléggé kitartó, de a napokban a német bíróság jogerős ítélete kimondta: a Mercedes a továbbiakban nem reklámozhatja az ún.  Airscarf-tel szerelt kocsijait, valamint nem adhatnak el több ilyet. Ez első olvasásra nem tűnik nagy érvágásnak, viszont eszelősen sokba fog fájni a Mercedest tulajdonló Daimler-csoportnak.

A szellemi tulajdonjoggal kapcsolatos peres eljárások egyébként azért is húzódhatnak eszelősen hosszú ideig, mert más-más állam más-más módon értelmezi a szellemi tulajdonjogot és az összes hozzá kapcsolódó fogalmat is, ez ma a világon az egyik legkevésbé harmonizált területe a jognak, a szabadalmi perekben ráadásul olyan szálakat kell kibogozni, amik határokat nem ismerve messze szétágaznak a világban, főleg egy Mercedes által alkalmazott megoldás esetén.

A Daimler jogi csoportja nyilván eléggé régen tudott róla, hogy szellemi tulajdonjogot sért, alighanem azért nem hátráltak meg végig, mert a bevétel messze meghaladta azt a kárt, amit most elszenvedett illetve el fog szenvedni a cég.

Egyre többször merül fel a kérdés, hogy vajon a webhelyek mennyi információt tudhatnak rólunk, ezt hogyan oszthatják meg egymást közt, arról viszont nem nagyon esik szó, hogy bizonyos adatok és módszerek hogyan tesznek nem csak egyedileg gép szerint, hanem akár a gépet használó felhasználó, mi több, akár név szerint is azonosíthatóvá egy-egy személyt. Jól olvasod, tényleg lehetséges. Előre jelzem, kicsit távolról, az alapoktól indítok. 

Aki az elmúlt másfél évtizedet nem egy kavics alatt töltötte, annak legalább valamiféle elképzelése van arról, hogy ha tetszik, ha nem, egyes webhelyek annyi információt igyekszenek begyűjteni rólunk, amennyit csak tudnak, elsősorban azért, hogy minél inkább számunkra releváns, esetlegesen érdekes hirdetéseket tudjanak megjeleníteni a reklámfelületükön. Ez az ún. kontextusérzékeny hirdetés, ami egyrészt érvényesül például egy szolgáltatáson belül, amire példa, hogy ha könyveket böngészünk az Amazonon, akkor is, ha nem léptünk be és inkognitó módban böngészünk, a webhely hasonló tematikájú könyveket fog ajánlani a böngészés ideje alatt. Sőt, mivel a trendek elemzésén keresztül hatalmas mennyiségű adatot spajzoltak be, ezért azt is jól tudják, hogy ha valaki mondjuk az anonimizálással kapcsolatos könyveket böngészte, akkor sanszos, hogy érdekelni fogja mondjuk valamilyen más geek kütyü, mondjuk kémtoll is, így azt is ajánlgatni fogja a webshop. 

A modell természetesen működik webhelyek közt is, gyakorlatilag behálózva a világot, a legismertebb ilyen technológia a Google Adsense, amivel kapcsolatban a legfinomabb, hogy a teljes Google-nek évről évre ez hozza a legnagyobb bevételt. A webhelyek közti működést úgy kell elképzelni, hogy ha egy Adsense-t használó oldalt meglátogatott a felhasználó ami alapján az Adsense sejti, hogy a felhasználónak milyen hirdetést lehet érdemes megjeleníteni, ezt követően ha egy olyan oldalra megy át, ahol még soha korábban nem járt, de szintén Adsense hirdetéseket használnak, akkor ott is eleve olyan termékek illetve szolgáltatások fognak felvillanni hirdetésben, amik feltehetően érdeklik az olvasót, de a korábban meglátogatott oldalak alapján. 

A kontextusérzékeny hirdetéseket a Facebook járatta csúcsra, persze kicsit más műfaj, hiszen itt már be kell lépni, ahogy arról már korábban írtam, gyakorlatilag jobban tudja a Facebook azt, hogy mire költenénk szivesen, mint mi magunk, ráadásul a Google-lel ellentétben a hirdetésperszonalizációt még csak ki sem lehet iktatni a szolgáltatáson belül. 

Webanalitikai szolgáltatásokról szintén írtam korábban, ezek lényege ugyancsak az, hogy tudjuk, a látogatóinkat milyen tartalmak érdekelték, milyen platformot használnak, általában milyen képernyőfelbontással, honnan kattintanak át az oldalunkra és így tovább, minden ilyen megoldás erősen támaszkodik a JavaScriptre és a sütik kezelésére. 

Tehát azok a főbb, régi módszerek, amiket már sok-sok ideje alkalmaznak arra, hogy a felhasználóról valamilyen adatot nyerjenek, a következők: 

1.    magának a webszervernek a nyers logja, amit valahogy így kell elképzelni 

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36

[IP-cím]
[URI,  azaz, abszolút minden fájl, ami http/https protokollon keresztül folyik át]
4/25/16 5:02 AM
[a tartalom, ami az előbbit meghívta, itt konkrét példával]
http://bardoczi.reblog.hu/telefonbeszelgetes-rogzitese 

Megjegyzem, elvben lehetséges, hogy semmilyen információt nem ad át a szervernek a kliens az oprendszer típusáról, a böngészőmotorról, böngészőcsaládról, csak ebben az esetben vagy megtagadja a kiszolgálást a webszerver vagy kiszolgálja ugyan a látogatót, de a tartalom hibásan fog megjelenni. Az okos webanalitikai oldalak az IP-címeket már nagy-nagy adatbázisok alapján földrajzi hellyé „fordítják le”, a legnagyobb adatbázisok pedig dermesztő pontossággal mutatják egy-egy eszköz helyét csupán az IP-cím alapján: http://iplocation.net/ 

2.    sütik a böngészőben – az első olyan technológia volt, amit többek közt azért hoztak létre, hogy a felhasználókat jobban meg lehessen egymástól különböztetni 

3.    minden más, hibrid módszer – gyakorlatilag a többi csak ezeknek a cizelláltabb változata, például amikor a Google Analytics megoldja, hogy egy süti elhelyezése után egy JavaScript kód folyamatosan értesítse a webanalitikát végző szervert a felhasználó kattintgatásairól 

Természetesen minden letiltható, csak éppenséggel ennek az az ára, hogy az elmúlt 10 évben készült webhelyek szinte egyike sem fog működni normálisan. 

Feltétlenül szót kell ejteni azokról a technikákról, amik viszonylag újabbak és még ennél is pontosabb azonosítást tesznek lehetővé. 

Az abszolút láma felhasználó esetleg gondolhatja úgy, hogy az IP-cím az azonosítás szent grálja, ezért nagyon gyorsan elmagyarázom az egyik okát, hogy ez miért nincs így, majd azt, hogy ez hogyan változott meg mégis. 

Az otthoni routerünknek vagy a munkahelyi routernek a netszolgáltató leoszt egy IP-címet, erre az IP-címre fogja majd megcímezni az adatcsomagokat az a szerver, amelyikről letöltünk. De ha egy munkahely vagy otthoni hálózat egy IP-címet használ, akkor honnan tudja az adatcsomag, hogy merre kell haladnia, azaz anyuka, apuka vagy a gyerek gépére kell küldeni az adatokat? Úgy, hogy a router, ahogy a nevében is benne van, útválasztást végez, így hálózati címfordítást is. Ez annyit jelent, hogy a router leoszt a lakásban található eszközöknek is külön-külön egy belső, kívülről nem látható címet, majd pontosan annak továbbítja, amit a net felől kapott, amelyiknek kell, kifelé viszont nem látszik, hogy melyik eszköz küldött adatot, mert a router elfedi azt. A belső hálózatra leosztott címek viszont alapesetben nem láthatóak az internet felé és egy, konvenció szerint csak belső hálózatok címzésére használható tartományból kerülnek ki, ami kisebb hálózatok esetén 192.168.1.1-től 192.168.255.255-ig tart. /*ez elvben több, mint 65 ezer gépet jelentene, a gyakorlatban az otthoni routerek 253 eszközt tudnak kezelni, azaz nem osztják le mindet*/ 

Tehát amikor valamilyen adatcsomagom érkezik a netről, azt a szerver megcímzi a kívülről látható, a világon abban az időben egyedülálló IP-címre, mondjuk a 178.48.105.abc-re, a routerem pedig tudni fogja, hogy lakáson vagy irodán belül már a 192.168.1.15 irányba kell továbbítani, ami jött, mert konkrétan az én gépemet ez fogja azonosítani, az adatot pedig én kértem. 

Tételezzük fel, hogy van egy troll, akit egy webhelyről vagy kommentmotorból ki szeretnénk tiltani IP-cím alapján és tudjuk, hogy a címe mondjuk 178.48.105.abc. Éppenséggel meg lehet tenni, viszont ha ezt a címet a netszolgáltató egy kisebb kollégiumnak vagy munkahelynek osztotta le, akkor az IP-alapú tiltással nem csak a problémás látogatót zárom ki, hanem mindenki mást is, hiszen ugyanazon az IP-címen keresztül látnak ki a netre a többiek is és a szerver is csak egy címet lát. 

Előbb írtam, hogy a belülre leosztott, azaz ún. LAN IP soha nem látszik az internet felé. Kivéve, amikor mégis. A böngészőben futtatható videócsetes szolgáltatások miatt szükségesség vált kifejleszteni egy olyan megoldást, amivel részlegesen tehermentesíthető a router, kifelé is mutatja a belső IP-címet is, viszont cserébe nem töredezik a kép és a hang videóhívás közben. 

Ezt az ún. WebRTC fölött valósítják meg és gyakorlatilag mára már minden böngésző támogatja. És ahogy mostanra kitalálható a leírásból, a belső IP-címet természetesen nem csak videócsetes szolgáltatások tudják lekérdezni, hanem gyakorlatilag bármi és bárki, aki a webhelyét felkészíti ennek a lekérdezésére. Ez viszont már hatalmas különbség a WebRTC előtti időhöz képest, hiszen megoldható, hogy például egy kommentmotor a trollnak ne csak a publikus IP-címét vegye figyelembe, hanem a LAN IP-jét is, azaz beállítható a tiltás olyan módon, hogy tiltsuk ki azt a gépet, amelyik a 178.48.105.abc IP-vel látható és a 192.168.1.35 LAN IP-cím tartozik hozzá. 

Az azonosítás ezen módszerét egyébként a komolyabb szolgáltatások ugyancsak használják, többek közt ez alapján fogja látni a Facebook, ha valaki a saját gépéről lépked be 5 kamu accountjába még abban az esetben is, ha elővigyázatosságból privát böngészőablakot nyit mindhez. 

Több ponton persze most egyszerűsítéssel éltem, a LAN IP-k kisebb hálózatok esetén rendszerint változnak, tipikusan egy napig azonosak, de ez lehet egy hét is, esetleg fix. 

Mi több, ha eléggé szépen kérdezik a böngészőtől, még azt is kifecsegi, hogy névfeloldó szerverként, azaz DNS1 és DNS2 szerverként mely szervereket használ [ezek azok a szerverek, amikről durva egyszerűsítéssel azt szokták mondani, hogy számokról betűkre fordítják le a szolgáltatások elérhetőségét, azaz a wikileaks.org cím begépelése mellett elérhetjük a Wikileaks oldalát a  95.211.113.154 beütésével is].  

Hogy mit láthat aktuális IP-ként, belső IP-ként és használt névszerverként bármelyik weboldal rólunk könnyen ellenőrizhető mondjuk itt: 

https://ipleak.net/

A másik, ami idővel szükségessé vált, hogy a webhelyek le tudják kérdezni a látogatójuktól, hogy a böngészőjükben milyen betűtípusok érhetőek el, milyen böngésző kiegészítők vannak telepítve, ezen kívül a reszponzív, okos weboldalaknak tudniuk kell, hogy a tartalmak milyen képernyőfelbontás mellett, milyen színmélységgel jelenítsék meg, mi több, ha átméretezzük az ablakot még azt is látni fogja, hogy mekkorára méreteztük át. Mindezeket vagy önmagában a webhelyen megjelenítéséért felelős HTML5 nyelvvel vagy ún. AJAX-technológiával oldhatujnk meg, de a lényeg, hogy nem csak a megfelelő megjelenítés érdekében használhatjuk, hanem pusztán naplózás céljából is. 

Márpedig ha figyelembe vesszük, hogy egy átlagos gép böngészőjében van mondjuk 10 telepített addon, elérhető 50 különböző betűtípus, a böngésző megmondja, hogy milyen felbontású a kijelző, könnyen belátható, hogy gyakorlatilag nincs két egyforma böngésző a világon! És olyan finom részletekbe bele se mentem, mint például az, hogy böngészőbővítmények a verziószámukkal együtt kérdezhetőek le. Az eredmény valami ilyesmi: 

Szemléletesebb, ha mutatom: az egyik legismertebb, browser fingerprinting oldal a https://panopticlick.eff.org/  ahol, miután elvégeztük az alaptesztet, kattintsunk a „Show full results for fingerprinting” feliratra és láss csodát, a webhely jobban ismeri a böngészőnket, mint mi magunk. 

Erre felvetődhet a kérdés, hogy mi van akkor, ha valaki hordozható TOR böngészőt használ? A hordozható TOR böngészőben ugye tiltva van számos HTML5, JavaScript funkció, nem futtat fecsegő bővítményeket, de például a NoScriptet mindig, ezen kívül mindegyik ugyanazt a betűkészletet és user-agentet [oprendszer és böngésző típusát mutató változó] kamuzza be a szerver felé, ami annyit jelent, hogy a látogatóról félreérthetetlenül sütni fog, hogy TOR-on keresztül érkezett. A TOR-on keresztül érkező látogatókat pedig egyre több szolgáltatás egyszerűen szögre akasztja és tovább sem engedi. 

A részletező táblázatban a „bits of identifying information” és a „one in x browsers have this value” sor értelmezése egyszerűsítve annyi, hogy az összes addig tesztelt böngésző közül az adott látogató böngészője mennyire egyedi. Annak az információértéke például, hogy a böngésző angol nyelvű, nem nagy, hiszen alighanem a világon a legtöbben angol nyelven telepítik a böngészőjüket. Annak viszont már eléggé nagy az információértéke egy külföldi oldal számára, ha például a böngésző nyelve magyar, mivel a világ összes böngészője közt relatív keveset telepítenek magyar nyelven. Azaz az egyediség megállapítása az információelméletben alkalmazott egyik alapmodellt alkalmazza, ami szerint az információ nem más, mint a bizonytalanság hiánya, minél kisebb bizonytalanságú valami, annál informatívabb. Másként szólva, minél többet tudunk valamiről, annál jobban alkalmazható azonosításra. 

Senkit sem büntetnék a Shannon-Weaver-modellel, de ha valakit érdekel, a szócikk magyarul is egészen jól össze van rakva.  

A Panopticlick-tesztben saját magunk jogosítottuk fel a webhelyet, hogy tudjon meg a böngészőnkről mindent, viszont tartsuk észben, hogy a LAN IP és DNS1, DNS2 megszerzését és más böngészősajátosságok lekérdezését és naplózását elvégezheti bármelyik webhely a tudtunk nélkül is! 

Jó, jó, de a webszolgáltatások használhatóbbá tételén túl milyen további haszna van annak, hogy a böngészőnk gyakorlatilag a puszta létével ennyit elárul rólunk? Ennek tényleg csak a fantázia szabhat határt, de azért képzeljük el az alábbi eseteket. 

Tételezzük fel, hogy szállodaszobát szeretnénk foglalni és a hotelfoglaló oldal látja, hogy egy Apple gépről netezünk, ráadásul céges bérelt vonalon keresztül, ebből egy hozzá kapcsolt algoritmus azt a következtetést vonhatja le, hogy sokkal magasabb árajánlatot dobjon fel, mintha egy öreg windowsos gépen próbálnánk foglalni szobát valamilyen olcsó netkapcsolaton keresztül. A dolog persze messzemenően etikátlan, de a törvény mindenesetre nem tiltja. Túlságosan paranoidnak tűnik? Abból már három évvel ezelőtt botrány volt, hogy egy webshop annak figyelembevételével eltérő árat mutatott más-más felhasználóknak ugyanannak a terméknek az adatlapjánál, hogy a felhasználó helyéhez közel mennyi hasonló profilú üzlet van, pedig egy egyszerű IP-alapú helymeghatározásról volt szó. 

Második forgatókönyv: tételezzük fel, hogy valaki kamu Facebook-accountokat hoz létre azért, hogy valakit zaklasson. A Facebook naplózza a legfinomabb részleteket is és simán adódhat úgy, hogy az adott gépről már nem enged új regisztrációt, a meglévőeket pedig egyszerűen jegeli a zaklató valódi fiójával együtt. Ugyanezen az elven, mivel a browser fingerprint naplózva van, többféle webes felületen keresztül történő támadási kísérlet azonosítható, az első esetben a zaklató, a második esetben pedig a szkriptelős hülyegyerek nem gondolhat mindenre, biztos, hogy lebuktatja valamilyen árulkodó nyom, amit hagy maga után. Egy kellően nagy kapacitással rendelkező szervezet akár adatbázist is építhet az ilyen böngésző-ujjlenyomatokból. 

A harmadik példa talán a legizgalmasabb. Amikor azonosítani kell egy spammert vagy scammert, elég, ha létrehozunk egy olyan kamu, fingerprintelő webhelyet, majd a címét elküldjük a nigériai főhercegnek mondjuk azzal a szöveggel, hogy oda írtuk fel a számára szükséges adatokat. Emberünk megnézi az oldalt, már meg is van a böngészője ujjlenyomata. A beépített szkriptünkön keresztül az illető nem csak, hogy a teljes böngésző ujjlenyomatát hagyja ott, hanem még az is látható lesz, hogy milyen böngészőbővítményeket és annak milyen verzióit használja. Ez a bűnüldözésben aranybánya – már amennyire a törvény engedi. Például ha ismert, hogy milyen bővítmények milyen verzióval futnak, egy böngésző motor vagy böngészőkiegészítő sérülékenységet kihasználva akár kémprogram is telepíthető az illető gépére, ahogy tette ezt minap az FBI is és nosza, fogtak is párezer pedofilt, na meg gyermekpornográfiában utazó jómadarat példásan rövid idő alatt. 

A harmadik technika, amiről nem ejtettem szót eddig, hogy egy kellően ügyes szkript segítségével egy webhely azt is meg tudja állapítani, hogy ilyen-olyan közösségi szolgáltatásokba be vagyunk-e jelentkezve. Ehhez már hozzászokhattunk a social pluginek világában, amikor például nem igényel plusz belépést a kommentelés egy poszt alatt, mivel a plugin felismerte, hogy már bejelentkeztünk a Facebook/Disqus/Twitter-fiókunkkal. A még ügyesebb szkript viszont még annak a megállapítására is képes, hogy egy-egy webhely tud-e lájkoltatni oldalakat a nevünkben, a tudunk nélkül. A lájkvadász mechanizmusok működése végülis a clickjacking, azaz click hijacking, magyarosabban szólva klikk-eltérítés egy speciális esete. 

Linus Robbins oldala is sokat el tud árulni rólunk és azt is jelzi, ha például a lájk-eltérítésre érzékeny a böngészőnk. 

Ezt egyébként a 

http://webkay.robinlinus.com/clickjacking/facebook.html 

oldalon lehet ellenőrizni: kijön egy teljesen köznapinak tűnő oldal, amiben ha az ártalmatlannak tűnő folytatás gombra kattintasz, a tudtod nélkül lájkoltad is Linus Robbins oldalát, amit a Facebookon az Activity logban vonhatsz vissza. 

A clickjacking ellen ugyan próbál védekezni a Facebook, a lényeg még mindig abban áll, hogy a lájk gombot el lehet rejteni egy, a webhelyen megjelenő átlátszatlan elem, például a „tovább” gomb alá. 

Még néhány évvel ezelőtt egy Bestofallworlds-meghívóért egy netes csaló 500 dollárt csalt volna ki egy pénzes német nyugdíjastól és a pénzt persze, hogy Paypal-re kérte, mint később kiderült, nem is volt BOAW-meghívója. A burzsuj szenilis német nyugdíjas csak annyit kért, hogy már küldi is a pénzt, csak az illető kattintson egy linkre, azzal az indokkal, hogy megmutathassa a képeket a nemrég született unokákról. A hülye scammer kattintott, amivel a tudta nélkül lájkolt is egy előre erre a célra létrehozott csali FB-oldalt a saját, valódi Facebook-fiókjával [azt pedig egy FB-oldal adminja azonnal látja, hogy konkrétan ki lájkolta az oldalát és mikor], ami alapján kiderült, hogy nem holland üzletember, hanem egy csóró harmadikvilágbeli pöcs, aki ilyen lehúzásokból él. Ami pedig a történetben nem mellékes, hogy a burzsuj német nyugdíjas valójában én voltam xD 

Azaz a netezők pontos azonosításához vagy netes csalások feltárásához nagyon sokszor semmi szükség rá, hogy valamilyen szépnevű hárombetűs szervezet tagjai legyünk, csak egy kis ész, na meg kriminalisztika. 

Több szempontból nem javallt, hogy az emlegetett oldalak által ajánlott anonimizáló bővítményeket feltegyük ész nélkül, de abban már nem megyek bele, hogy miért. 

Persze, tényfeltáró újságírók, ilyen-olyan aktivisták részéről gyakran felmerülő igény, hogy ne lehessenek azonosíthatók, észben kell tartani, hogy az anonimizálás – amellett, hogy 100%-os sosem lehet – külön tudomány. Ennek megfelelően ha kényes kutatómunkát végez valaki, az általános OPSEC gyakorlat mellett érdemes konzultálni olyannal, akinek az anonimizálási módszerek több éve a kutatási területéhez tartoznak. 

Amikor emailt küldünk valakinek, annak reményében tesszük, hogy azt a címzett majd el is olvassa. Ugyanakkor bármikor bárki mondhatja, hogy az emailt nem kapta meg, spamben landolt, nem volt még ideje foglalkozni vele, ugyanakkor indokolt esetben, ha a levél kellően fontos volt, tudunk kellene, hogy a levelet a címzett olvasta-e és ha igen, akkor mikor is. Hogyan oldható meg mégis a feladat? Tökéletesen sehogy, de részmegoldás azért van.  

Sokak számára alighanem már csak amolyan megmosolyogtató emlék, hogy az emailek olvasottságáról a címzettől visszajelzést kérhetünk, ha levelezőrendszerünk támogatja azt a pattintott kőkorszakból ránk maradt funkciót, amiben kérelmezi a címzettet, hogy jelezzen vissza a feladónak emailen, ha a levelet elolvasta. Ezt tekinthetjük a klasszikus e-tértivevénynek. A lehetőséget szinte már senki sem használja, ugyanis alapvetően a felhasználók többsége nem akarja a címzettel tudatni, hogy a levelet elolvasta-e, ha fontos dologról van szó, úgyis jelentkezik majd, ha pedig nem, jobb elsumákolnia, aztán tud jönni valami vérszegény kifogással. 

Ahogy írtam, gyakorlatilag egy kihalt lehetőségről van szó, mivel még ha kérünk is ilyen visszajelzést, a címzett levelezőrendszere ezt vagy figyelembe veszi vagy sem, ha támogatott a visszajelzés funkció, a felhasználó még mindig dönthet róla, hogy küldjön visszajelzést, ne küldjön visszajelzést, esetleg a levelezőrendszer rá se kérdezzen, így soha senkinek ne küldjön olvasottsági visszajelzést. 

Ugyanakkor fennmaradt az a természetes igény, hogy a feladó tudhasson róla, hogy a levelét a címzett megkapta, olvasta, csak ha nem válaszol, tesz rá magasról vagy nem jutott el hozzá. Az egész pedig egy régi jó technikával szinte mindig kivitelezhető, hamarosan rátérek, hogy miért nem garantáltan mindig. 

Amikor egy webszerverről egy dokumentumot letöltünk, annak a naplófájljába bekerül többek közt, hogy milyen IP-címmel, milyen böngészővel és böngészőverzióval, milyen oprendszerrel és annak milyen verziójával, azaz milyen géppel történt a letöltés. Megjegyzem, ezek kombinációja sokszor már önmagában is igencsak egyedi. Már több, mint tíz évvel ezelőtt is úgy küldték a hírleveleket a szolgáltatók, hogy abban olyan grafikus elemeket, azaz képeket helyeztek el, amiket HMTL formátumú levélbe szerkesztettek bele, a képeket pedig ennek megfelelően nem csatolták az emailhez, hanem egy külső szerverről töltötték be a HTML megjelenítésnek megfelelően a címzettnél. Nyilvánvaló, hogy ha a levél normálisan megjelent, a hírlevél küldője visszajelzést kapott azzal kapcsolatban, hogy a levelét egyáltalán mennyien nyitották meg, hiszen látta, hogy mennyi különböző logbejegyzés van, ami a képi elemek szerverről való letöltődését tanusította. Biztonsági szempontból viszont nagyban gondolkozva igen nagy kockázatot jelent, ha tudható, hogy valaki pontosan milyen platformmal netezik, ráadásul az IP-címekhek kapcsolódó szervezet és annak helye egyre pontosabban azonosíthatóvá vált az évek folyamán. 

Sok-sok évvel ezelőtt már minden jólnevelt levelezőkliensben és webes levelezőrendszerben alapértelmezés volt, hogy a HTML-formátumú levelekben lévő távoli szerveren tárolt képeket nem tölti le automatikusan, hanem rákérdez a felhasználónál, hogy letöltse-e azokat. Ha a felhasználó úgy döntött, hogy ne töltse le, akkor a feladó nem értesült róla, hogy a címzett a levelet megkapta-e. Viszont könnyen lehet, hogy a címzett egyszerűen nem tudta elolvasni a levelet, mert ilyen-olyan lényegi információk nem szöveges formátumban, hanem egy képre írva voltak a levélben, mint például egy szilveszteri parti helyszíne. Így ha a címzettet érdekelte a dolog, mindenképp le kellett töltenie a képet, mint külső tartalmat is. 

Ez még mindig az ókor. Aztán jöttek az ügyesebb hírlevélkézbesítő rendszerek, amik minden egyes címzett leveléhez külön-külön, egy egyedi, távolról letölthető képet is linkeltek. 

Azaz például, ha valaki feliratkozott pistike@example.org címmel, akkor a hírlevélküldő az adott címhez és hírlevélhez generált egy egyedi nevű fájlt a szerveren, mondjuk http://hirlevelkuldo.tld/track/d1a3c5382be1a69c57f7caccbb8c6858.gif 

ahol a fura nevű GIF, tipikusan 1x1 pixeles átlátszó GIF-fájl a HMLT-levélbe volt ágyazva és ha a fájl a levéllel együtt letöltődött a szerverről, akkor az egyértelműen bizonyította, hogy a pistike@example.org címre kiküldött hírlevél kézbesítődött és Pistike meg is nyitotta azt, természetesen azzal az információval együtt, hogy mikor. 

Az ilyen típusú állandó feedback mesterkéltnek tűnhet, viszont olyan hírlevelet küldeni, amire a felhasználó valaha feliratkozott, a levelezőrendszer nem vágja azonnal spambe, drágább mulatság, mint amilyennek tűnik, a hírlevél küldője pedig érthető módon tudni szeretné, hogy mennyi értelme van egyáltalán hírlevelet küldözgetnie. 

Ezen kívül voltak még ilyen-olyan torzszülött megoldások, mint például a HTML-levélbe ágyazott JavaScript-kód, ami elvben a levél megnyitásakor lefut, érthető módon kicsit is normális levelezőrendszer nem tette lehetővé az azonnali kódfuttatást a levél megnyitásakor. 

Azaz maradt a jó öreg 1x1 pixeles megoldás, ami persze nem csak hírleveleknél vethető be, hanem minden további nélkül egyénileg küldött leveleknél is. Számos szolgáltató van, ami lehetővé teszi ilyen levelek küldését, úgy, hogy a részletekkel a feladónak ne kelljen foglalkoznia, ami viszont közös bennük, hogy sosem garantálják 100%-ra a visszajelzést, de az esetek többségében igen.  Ezek közül egyet mutatok be, utána pedig azt, hogy mindez hogyan kivitelezhető sokkal geekebb stílusban, bármilyen szolgáltató igénybevétele nélkül. Ezen kívül feltételezem, hogy a levelezéshez a legtöbben Gmail-t használnak, azt is webes felületen keresztül – ott viszont gyakorlatilag mindig működik. 

A http://www.getnotify.com/ oldalon egyszerűen csak regisztrálni kell azzal a saját email címünkkel, amelyikkel követett levelet szeretnénk küldeni, majd ha ez megvan, teljesen hagyományos módon megírhatjuk az emailt a címzettnek, nemes egyszerűséggel csak a címzett címének végére kell biggyeszteni a getnotify.com hosztnevet. Azaz ha a címzett pistike@example.org lenne, akkor a levelet a pistike@example.org.getnotify.com címre kell küldeni. 

A küldést követően a Getnotity a levelet átformázza HMLT-formátumúvá, akár HTML levél volt eredetileg, akár nem, majd elhelyez benne a kézbesítésre nézve teljesen egyedi nevű átlátszó fájlt, majd a levél fejlécét olyan módon módosítja, hogy levágja a .getnotify.com hosztnevet a cím végéről és továbbküldi a levelet a címzettnek. A címzett a levelet megkapja, megnyitja, a feladó pedig a Getnotify felületén keresztül értesül is róla, hogy a levél meg lett nyitva, mi több, ha a címzett a levelet többször is megnyitotta, az összes időpont szerepelni fog, amikor a levél meg lett nyitva. Hogy érthetőbb legyen, egy Gmail-es címre küldött levél kézbesítési reportja valahogy így néz ki: 

Mint látható, a report szinte mindent mutatna, ami a kézbesítődéssel kapcsolatos, ráadásul külön-külön, amennyiszer megnyitotta a címzett a levelet, ebben az esetben persze a tesztlevelet egy saját gmail-es címemre küldtem. Gyakorlatilag viszont a levél megnyitásának idején kívül semmilyen értelmes adat nem hámozható ki például a címzett földrajzi hollétét illetően, mert annak helyén a Google szerverei által odamókolt adatok vannak. Mi lehet a magyarázat? 

A Google nagyon jól tudja, hogy a Gmailt a többség webes felületen keresztül használja, ugyanakkor azt is, hogy ha azonnal betöltenék a távoli tartalmakat, az egyrészt felfedné a felhasználó hollétét, az általuk használt platformot, ugyanakkor emellett nyilván igény van rá, hogy a HTML-formátumú emaileket a felhasználók el tudják olvasni úgy, hogy azokban megjelennek a képek is. Éppen ezért nem is olyan rég a Gmail-ben az lett az alapértelmezett beállítás, hogy a távoli tartalmakat is automatikusan betölti a levél megnyitásakor, viszont nem az eredeti helyéről, hanem előzetesen a képet a Gmail a háttérben gyorsítótárazza a GoogleImageProxy-n keresztül, majd innen töltődnek be a képek ténylegesen. Ekkor viszont természetesen a küldő rendszer nem a valódi címzett címét és egyéb platformjellemezőit látja, hanem a GoogleImageProxy-ét fogja naplózni. Nem megyek bele olyan finom részletekbe, hogy a Google természetesen a háttérben nem Windows XP-s gépeket használ Firefox böngészővel a gyorsítótárazáshoz. 

Persze mezei levelezőrendszer esetén, ha a HTML-levéllel távolról letöltődik az apró, átlátszatlan kép, a feladó teljesen valid információkat kap a címzett által használt platformmal kapcsolatban is, ez viszont szinte mellékes, ha a fél világ Gmailt, Outlook.com-ot és hasonlókat használ levelezéshez, amik a GoogleImageProxy-hoz hasonló megoldást alkalmaznak. A filléres és fapados levelezőfelületeknél, mint amilyen a Horde, Squirrel vagy a Roundcube, a rendszer ideális esetben rákérdez, hogy betöltse-e a távoli tartalmat, amit a felhasználó jó esetben csak akkor engedélyez, ha a feladó számára megbízható.  

Érdekesség, hogy az egyik legkomolyabb levelezőrendszer, a Microsoft Exchange alapértelmezés szerint úgy tölti be a levelek megnyitásakor a képeket, hogy nem is kérdez rá, hogy a távoli tartalmat letöltse-e. Az ok alighanem az, hogy meglegyen az a típusú kényelem, amiért egy-egy felhasználó elvár, ha a cége egy Exchange üzemeltetéséért fizet. Ott az Exchange előzetesen persze alaposan átvizsgálja, hogy a levél tartalmaz-e kártékony kódot, amit akár egy képbe rejtettek el, de nem proxyzza magukat a képeket, hanem letölti azokat az eredeti helyükről, így ha tudjuk, hogy a címzett Exchange-t használ a cégnél, ritkábban magáncélra, ott jobban jobb lesz a „találati arány”. 

Végülis mennyire megbízható konkrétan a Getnotify? 

A saját súgóoldalán ugyan azt állítja, hogy a címzett semmit fog észlelni abból, hogy egy követett küldeményről van szó, ez igaz is és nem is. Az átlag felhasználó valóban semmit sem fog észlelni belőle, kicsit is jobban megnézve viszont ordít a trackelt levélről, hogy az egy köztes átjárón lett keresztülpréselve valami miatt. Éppen a Gmail nemrég vezette be azt az újítást, hogy a feladó mellett egy törött piros lakatot helyez el akkor, ha a feladó rendszere nem szavatolta, hogy az email csak titkosított csatornán kézbesítődhet, márpedig a Getnotify esetén ez a helyzet. 

A részleteket megnézve pedig egyre büdösebb lesz a dolog: 

Ami pedig már bizonyító erejű, ha megnézzük az emailt nyers formátumban, ahol nem csak az kerül ki, hogy a látszólag egyszerű szövegként küldött levél valójában egy egyszerű szövegnek tűnő HTML-levél benne egy-két érdekes képpel, ami sima nézetben nem látszik, hanem az is, hogy ha a feladó domain nevéhez DKIM-rekord tartozik, a fejlécben látható, hogy az sérült, lévén hogy a levelet valami út közben megváltoztatta, ez egyébként annak az esélyét is nagyban növeli, hogy a levél a címzettnél spamben landol. 

Összességében elmondható, hogy nem, bárki bármit is mond, máig nincs olyan csoda technika, ami biztosan szavatolná, hogy a levél olvasottságáról a feladó biztosan tudomást szerezzen, pláne nem úgy, hogy azt a címzett ne vegye észre, ha akarja, legalábbis hagyományos emailek esetében nincs és ez így van jól. Ez a technikailag meglehetősen egyszerű trükk viszont az esetek döntő többségében működik, csak személyre szóló levél küldésekor nem túl bizalomgerjesztő, ha a címzett észreveszi, hogy előzetes beleegyezése ellenére ellenőrizni akarta a feladó a levél olvasottságát, hiszen ahhoz vagyunk hozzászokva, hogy ez a címzett magánügye. Egy személyes hangvételű levélbe bele lehet varrni olyan linket, amiben valaminek a megtekintésére kérjük a feladót egy linken keresztül, ami persze olyan szerveren van tárolva, amihez a logjaihoz hozzáférünk, hiszen ekkor ugyanúgy szervernaplóba kerül a linkelt tartalom letöltése, csak éppen egyáltalán nem biztos, hogy kattintani is fog a linkre a címzett. 

Ami fontos, hogy olyan levelet, amilyet például a Getnotify.com készít, írhat bárki, aki olyan levelezőprogramot használ, amelyik támogatja a nyers HTML-szerkesztést, amiben csak egy saját tárhelyre mutató, akár láthatatlan képet lehet elhelyezni, ez lenne a kézműves megoldás. 

Megjegyzem, gyakorlatilag minden levelezőrendszerben tiltható, hogy a levél egyáltalán HTML-ben jelenjen meg vagy éppen az, hogy külső képeket töltsön be. Ha mégis ilyen levelet kapnánk, megbízunk a feladóban tipikusan néhány kattintással engedélyezhetjük a teljes megjelenítést. 

Mindegy, hogy a Getnotify-ről vagy szó vagy valamelyik másikról, a működési elve mindnek az, amit leírtam. A kukkoló funkciót különböző levelezőrendszerek esetén ezekkel a beállításokkal lehet teljesen hatástalanítani.  

Gmail esetén: 

AOL-on: 

Zimbra rendszerben: 

Horde-n: 

Hushmailen: 

Roundcube-on: 

Squirrelmailnél: