Térképek, keresők, mobilos társkereső rendszerek és közösségi szolgáltatások – mindnél természetesnek vesszük, hogy figyelembe veszik, honnan netezünk éppen vagy konkrétan működésképtelenek is lennének enélkül.

Gondoljunk csak bele: amikor elindítod a Google, Yandex, Bing vagy OpenStreetMap térképszolgáltatását, kisebb-nagyobb pontossággal eleve azt a területet mutatja, ahol vagy, nem pedig a teljes bolygót. Akár termékre, akár szolgáltatásra keresel rá, természetes, hogy ha az kapható illetve elérhető Magyarországon, a magyar találatokat fogja dobni, azaz ha Tihanyban ráguglizol arra, hogy „cafe”, nem a világ legtöbbször hivatkozott weboldalait fogja kiadni, amik valamilyen kávézó webhelyei, hanem azt, ami ésszerű közelségben van. Ha elindítod a Tindert, azt veszi alapul a választék megmutatásakor, hogy milyen közelségben vannak a csajok illetve pasik, enélkül működésképtelen lenne az egész, de olyan mobilos társkeresőt is láttam már, ami plusz/mínusz néhány méteres pontossággal mutatta a másik felhasználó pozícióját.

Ráadásul mindez független attól, hogy helymeghatározó funkciót használó mobileszközt használsz, asztali gépet vagy laptopot, csak a pontosság tér el. Hogyan? Honnan tudják a webes szolgáltatások, hogy éppen honnan netezel, ráadásul ilyen pofátlanul pontosan?

Ahelyett, hogy belemennék a részletekbe, ismét az elvi működést ismertetem nagyvonalakban, a geolokáció felhasználási lehetőségei nyilván végtelenek, ami nem kevés kérdést vet fel, amit inkább meghagynék azoknak idióta privacy fetisisztáknak akiket behatóbban érdekel a téma.

Ha nagyon vissza akarok menni Ádámig és Éváig, mindig eszembe jut, hogy micsoda össznépi őrjöngés volt még 10-15 évvel ezelőtt is annak kapcsán, hogy a mobilszolgáltatók naplózzák azt, hogy az előfizetők mobilja mikor hol volt éppen, ennek megfelelően azt is pontosan tudják, hogy merre volt maga az ügyfél és persze legalább annyi rémes ostobaságot hordtak össze a témában, mint manapság. A szolgáltatók pedig számomra érthetetlen módon első reakcióként lehazudták, hogy tárolnának a földrajzi hellyel kapcsolatos adatokat, holott ha bárki megnézi, hogy hogyan működnek a GSM hálózatok, - mondjuk ebből a jó régi, de az elméletet jól summázó könyvben – abból világosan kiderül, hogy nem is működne az egész, ha a hálózat nem tudná, hogy a mobil hol van, dióhéjban azért, mert az eszköz helye alapján tudják egyszerűen eldönteni a mobilhálózatok, hogy mely tornyot vagy tornyokat használja az eszköz, jelerősség, terheltség és egyebek alapján. Ez még jócskán a 80-as évek elején is így volt, de ha nem naplóztak volna ilyen-olyan adatokat, akkor esélytelen lett volna diagnosztizálni visszatérő problémákat, normálisan fejleszteni a hálózatokat, hiszen ha nem tudható, hogy egy-egy torony mennyire leterhelt, esetleg milyen típusú mobilok problémásak, azt sem lehet előre bejósolni, hogy hova kellene építeni még tornyot. Ezzel gyakorlatilag egy időben kötelezővé is tették a jogalkotók a szolgáltatók számára, hogy ezeket az adatokat jó sokáig tárolják is, aztán több bűntényt így sikerül megoldani, a mainstream sajtóba csak olyasmi néven vonult be a fogalom, hogy cellainformáció-alapú helymeghatározás.

Nos, ehhez képest ma a felhasználók egy jókora része rendszeresen becsekkol ide-oda-amoda a webkettőn, még azt is megjelöli, hogy pontosan hol lakik, na meg, hogy mettől meddig nyaral. Az Antivírus Blogon visszatérő téma, hogy a betörők elképesztően nagy része a social weben keresztül előre tájékozódik róla a betörés tervezésénél, hogy hova törjön be, elég csak megnézni néhány palimadarat, amelyik geotaggel Fészen, Instán, Foursquareen – ami aztán már tényleg az agyrém netovábbja – ha ezek esetleg nem lennének kint publikusként, és a betörőnek van egy csöpp esze, akkor létrehoz egy vonzó kamu karaktert, majd felveteti magát ismerősnek emberünkkel. Kihasználva azt, hogy ilyen téren annyira illedelmes a többség, főleg a jól kinéző szőke hölgyekkel, akiknek az adatlapja szerint egy iskolába jártak, hogy felvesz ismerősnek boldogot boldogtalant, de még akkor is, ha a kamu karakter képét egyébként ezer helyen dobná a Google Képkeresője és az illetőnek eszébe sincs megválaszolni azt a kérdés, hogy "bocs, honnan ismerjük egymást". [1]

Jókora patália volt belőle, amikor a Google Streetview kocsijairól kiderül, hogy nem csak utcákat fotózgattak, hanem menet közben összegyűjtötte a hatótávolságába kerülő wifi-routerek hálózati nevét, ún. BSSID-jét és el is mentette azt a kapcsolódó GPS-koordinátákhoz kötötten. Persze nem adta ki senkinek, viszont óriási adattárházat épített belőle. Persze sok-sok hülye és kevésbé hülye ország illetékes szervei kötelezték a Google-t, hogy ezeket az adatokat töröljék, mivel a routerek tulajdonosai explicit módon ebbe nem egyeztek bele. Mit csinált a Google? Like a boss, törölte az így begyűjtött adatokat, majd egy még precízebb helymeghatározást lehetővé tevő, gyakorlatilag megkerülhetetlen módszert alkalmazott. Itt most arról fogok irkálni, hogy hogyan működött az adatgyűjtés korábban, a legtöbb helyen már nem így működik a Goolge esetén, de millió meg egy más szolgáltatás csinálja.

Nagyon nagy vonalakban a helyzet valahogy így néz ki: amikor valaki használatba vesz egy mobiltelefont, akkor vagy elfogadja a felhasználási feltételeket vagy felteheti dísznek a polcra kikapcsolva. Ha elkezdünk például egy andoridos mobilt használni, akkor kapásból beleegyezünk abba, hogy a mobil a háttérben leolvassa a hatótávolságában lévő BSSID-ket és elküldje a Google-nek, amit több adattal kapcsol össze, ezek többek közt
-    a korábbról már meglévő pozícióadatok
-    a mobilteló cellainformációja alapján helymeghatározásra használható adatok
-    az IP-cím, amit akkor kap meg, amikor a felhasználó kapcsolódik az egyik hálózathoz wifin keresztül, az Android core szolgáltatásain kívül pedig még kismillió Google-szolgáltatásnak ezt úgyis tudnia kell, például amikor a Gmail-es levelek automatikus letöltése történik, a felhasználó elindítja a Chrome-ot, amelyik szinkronizálja a könyvjelzőket, stb.  

Mielőtt most azt mondanák az almás és ablakos felhasználók, hogy ugyehogyugye, gyorsan megírom, hogy az Apple és a Windows Phone-os eszközök lényegében ugyanezt csinálják, csak éppenséggel a szolgáltatások neve más.

Na de még mindig nem világos, hogy a fent említett néhány adatból honnan tudja akkora pontossággal Android esetén a Android Device Manager, iPhone esetén pedig a Find my phone, hogy hol is az a mobil, ha elveszik, aztán megkeressük a térképen, hogy hol van.

A durván egyszerűsített magyarázat az, hogy egy cella alapján még a torony is csak kilométeres pontossággal tudná megállapítani a mobil helyét, de a mobil általában egyidejűleg több cellára kapcsolódhat, amiknek eltérő a jelerőssége, amiből besaccolható ezek távolsága, márpedig ezeket az adatokat az okosmobil elérheti. Ráadásul hacsak nem egy oázisban vagyunk, ahol még ember nem járt előttünk, akkor nyilván korábban más mobilja is lekérte és használta ugyanezeket az adatokat, másrészt tőlünk egy városon belül minden égtáj irányába kisebb vagy nagyobb távolságra, de van wifije a szomszédnak északra, délre, keletre és nyugatra egyaránt, ahol más mobilok ugyanezeket az adatokat már átadták a helymeghatározó szolgáltatásnak.

Innentől kezdve pedig már nettó matek az egész, egy-egy pont térbeli helye meghatározható más, ismert helyen lévő pontokhoz viszonyított távolsága illetve szögek alapján, ennek az egyik legegyszerűbb, de nyilván nem egyetlen módszere a háromszögelés.

Nos, egy mobiltorony ennyi kilométerre, a másik annyi kilométerre, hogyan adódik mégis a néhány méteres pontosság? Anélkül, hogy csukafejest ugranék konkrét adatbányászati módszerekbe, amik többségéhez amúgy nem értek, lényeg, hogy az adatbányászatnál, na meg egyáltalán amikor napjaink egyik legrémesebb buzzwordje, a big data kerül szóba, a lényeg azon van, hogy minél több adat áll rendelkezésre, még ha azok pontatlanok is, a nagyon sok pontatlan adatból kikövetkeztethetők nagyságrendekkel pontosabb, már használhatóbb információk. Lásd: machine learning,  ami végülis a mintázatfelismerés alapja és felhasználható szinte bárhol. [2]

Nagyjából ennyi! Fontos tudni, hogy a mobilokban szigorú értelembe véve sosem valódi GPS van, hiszen ekkor egyrészt a mobil nagyobb és drágább is lenne, másrészt pedig amikor a pozícióját le akarja kérdezni, mindig fel kellene vennie a kapcsolatot több műholddal, amire vagy pont van rálátás vagy nincs, de egy-másfél percig bőven eltartana, ráadásul olyan pontosságra nincs is szükség.

Tisztázzuk: a mobilokban használt, előbbi adatok feltöltése és lekérdezése alapján működő helymeghatározó technológia az AGPS, azaz Assisted Global Positioning System.

A mobileszközöket túl is tárgyaltuk, az esetleges pontatlanságokért pedig elnézést. Na de honnan tudja az asztali gép, hogy hol van?

Ahogy írtam, a mobil felküldözgeti a cellainfóit és az általa látható vagy általa használt hálózatok BSSID-jét is, ezen kívül a netszolgáltatótól kapott IP-t [mármint amit wifin keresztül használ]. Márpedig túl gyakran nem változik sem a netszolgáltatónk, ennek megfelelően az sem, hogy a netre csatlakozott eszköz milyen IP-címtartományból kap IP-címet, mi több, nem csak a címtartomány marad változatlan, a netszolgáltatók nem osztanak új IP-címet sem, ha nem feltétlenül szükséges, így akár hónapokig is ugyanaz marad a dinamikus IP, az pedig, hogy egy IP-cím milyen internetszolgáltatóhoz tartozik, lekérdezhető – Európában – a RIPE adatbázisán keresztül automatizáltan is, amit a GIS-szolgáltatások meg is tesznek. Egy-egy IP-tartományhoz tartozó blokk valahogy így néz ki:

https://apps.db.ripe.net/search/query.html?searchtext=188.36.223.0#resultsAnchor

A netszolgáltató persze elvben azt kamuzik be bizonyos korlátok közt, amit csak akar, viszont ez egyszerűen nem érdeke, az érdeke az, hogy olyan pontossággal adjon meg adatokat, ami a hálózatok közti adatcsere folyamán az útválasztást segíti, a sebesség érdekében pedig úgymond tudniuk kell a hálózatoknak, hogy hol vannak, tipikusan egy-egy országnyinál sokkal nagyobb pontossággal. Ez az alapja a távolság-vektor alapú útválasztásnak
ami biztosítja, hogy az adatcsomagok ne csámborogjanak a neten egyik géptől a másikig, mint gólyafos a levegőben, hanem minél gyorsabban jussanak el a feladótól a címzettig.

Lényeg, hogy amikor mondjuk megnézzük a Google Mapset asztali gépen, akkor az nyilván nem tudja átadni a routerünk hálózati nevét, viszont az IP-címét igen, amit kikeres az adattárházában, lévén, hogy ahhoz az IP-címhez vagy azzal egy címtartományban lévő címhez már kapcsolódtak korábban mobiltelók, amik fel is küldték a helyüket, ebből következik, hogy az adott IP-hez tartozó hely mi is. Ekkor hopp, minimum kerület pontossággal a Maps eleve arra a területre fókuszál, ahol vagyunk, nem pedig például csak Magyarországra. Azzal nem is bonyolítanám a képet, hogy az óriásszolgáltatók nem csak mobilok által kapott pozíciók alapján saccolgatnak, hanem néha méricskélnek is a szervereik és netszolgáltatók alhálózatai közt traceroutinggel, ami nem konkrét távolságokat mutat, hanem azt, hogy hálózati eszközök közt milyen sebességgel közlekedik az adat a mérés pillanatában. Ez csak nagyon durva becslésre adna lehetőséget, viszont ha sok-sok mérést végeznek és sok-sok útválasztó IP-címének hálózatát jegyzik fel [3], akkor a sok-sok pontatlan adatból legalább megye pontosságú adat jön ki.  Természetesen a szolgáltatások tudják, hogy egy IP-cím tartozhat mobilhálózathoz is, ami meg a címet mobileszközöknek osztja le, a mobilok ugyebár attól mobilak, mert mozognak, a geoinformatikai adattárházakat építő algoritmusok nem hülyék, ezt figyelembe veszik.  Egyrészt a már emlegetett RIPE adatok alapján, másrészt pedig az alapján, hogy alighanem már bőven volt mobil, amelyik éppen abból az IP-címtartományból /*azaz így szolgáltatón keresztül*/ használta korábban pont az ő egyik szolgáltatásukat, márpedig ha valaki mondjuk elkezd az iPhone-ján böngészni, a böngésző azzal kezdi, hogy jelzi a webhelynek, így az amögötti szolgáltatásnak, hogy ő egy mobileszköz, valahogy így  

80.99.xy.zw [URI] 7/2/15 11:17 PM Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Version/7.0 Mobile/11D257 Safari/9537.53

És ha nem is ebben a formátumban, a többi mobilalkalmazásnak is egyértelművé kell tenniük egy app elindításakor a szerver felé, hogy ő nem netre kötött kenyérpirító, hanem mondjuk egy Samsung Galaxy adott típusú és verziójú operációs rendszerrel.

A helymeghatározás többek közt ezeket a módszereket kombinálja, finomítja.

Amivel nem akartam bonyolítani a képet, hogy nem feltétlenül úgy kell elképzelni, hogy a Microsoft a Bing Mapshez, a Google a Google Mapshez, az Apple a Mapshez, a Yandex pedig a Yandex Mapshez külön-külön adattárházat épít, amik mit sem tudnak egymásról. Egyrészt nem ritkán az adatokat cserélgetik egymás közt és mindenki jobban jár, másrészt természetesen igénybe veszik olyan geoinformációs technológiákkal foglalkozó cégek technológiáit és adattárházait is, amik közvetlenül egyáltalán nem szolgáltatnak a végfelhasználók, csak a szolgáltatók felé, ilyen például a TeleAtlas aminek egy részéből rakták össze a Google Maps-et.

Ezen kívül alighanem mindenkinek a mobilján van olyan app, aminek egyáltalán nem szükséges tudnia, hogy hol vagyunk, mégis az ingyenes használat feltételévé teszi, hogy a pozíciónkat hébe-hóba felküldi egy partnerének, mi pedig nem olvassuk el a kilométeres T&C-t, na meg egyébként sem érdekelne.

Vannak olyan cégek, akiktől kilóra lehet venni olyan adatbázisokat, amik kizárólag az IP-címre támaszkodva adják vissza a látogató földrajzi helyét, ilyen például az IPteligence, az IPAddressLabs, az IP-DB, vagy az IP2location.  

A helymeghatározásnak olyan esetben is fontos szerepe lehet, amiről egyébként nem gondolnánk. Például a Skype alapértelmezés szerint egy hanghívásnál point-to-point, ha úgy tetszik, közvetlen kapcsolatot hoz létre a két fél közt, amihez nyilván egymás IP-címét tudni kell. A Skype-on ez letiltható ugyan, ekkor egy köztes szerveren fut át az adat, viszont olyan esetben, ahol csak lassabb netet kap a mobil, pont emiatt lesz a hangminőség rosszabb.

Amit írtam, hogy a Google esetében a BSSID-alapú adatgyűjtési gyakorlat számos országban már a múlt, amíg viszont nem volt így, addig a wifi BSSID-je végére írt _nomap jelölővel lehetett utasítani a Google-t, hogy ezt ne vegye figyelembe, a wifink neve a helyével együtt ne kerüljön fel az adatbázisba. Na és? Ott van még ezer másik szolgáltató, amelyik meg gyűjti látástól Mikulásig. Ráadásul értelmetlen is tiltani, mivel vannak olyan, az OpenStreetMap-hez hasonló, közösségi tudáson alapuló geoinformatikai megoldásokat is használó rendszerek, mint például a WiGLE amiknek az API-felületén keresztül mondjuk pont olyan BSSID-k kereshetők bárki számára, aminek a nevében benne van, hogy _nomap :)

Szóval eléggé gyorsan érdekessé tudja tenni magát az a felhasználó, aki mondjuk az otthoni routerét így nevezi el, addig csak a Google látta, az átnevezés után meg az egész világ. Az is lehetőség, hogy a router konkrétan ne boardcastolja a hálózat nevét, ekkor viszont ha valaki vendégségbe érkezik és wifit használna, kézzel kell bekalapálnia a hálózat nevét is a jelszó mellett, mivel az nem fog látszani a wifi hálózatok felsorolásában.

Még egy picit a Google-ön rugózva, mondhatni eléggé para, amikor 30 napra visszamenőleg meg lehet nézni, hogy merre mászkáltunk az androidos mobilunkkal, hacsak ez nem volt letiltva, trükkös dolognak tűnik az, hogy meghamisítjuk a mobilunk pozícióját, annyira nem az. Ez elvben elérhető Blackberryn, Windows Phone-on, Apple-n is, csak sokkal durvább beavatkozással, míg Android esetén elég a beállítások alatt bekapcsolni a Developer mode-on belül a Mock location engedélyezését, ezt követően a geek-ebbek az Android SDK-n keresztül idétlenkedhetnek vele, de vannak konkrétan olyan alkalmazások is, amiken egyszerűen csak rá kell bökni a térkép egy pontjára és rögtön azt kamuzza a mobil az összes alkalmazásnak, hogy valójában mondjuk a Déli-sarkon vagyunk. Nagyon gyorsan hozzáteszem, hogy egyetlen androidos mobilom van, amit szinte soha nem viszek el sehova otthonról, többen viszont elsődleges telefonként használják a saját androidos mobiljukat. Abban az esetben, ha valami hülyeség van bebökve a valódi pozíció helyett, a többi platform  esetében pedig például egy az egyben le van tiltva a földrajzi hely meghatározása, nos, teljesen mindegy, hogy Android, Windows Phone, iOS vagy Blackberry a mobilunk, garantáltan nem lesz meg, ha valahol ott felejtjük, hiszen maga a mobilkereső-lopásgátló szolgáltatás sem éri el.

Azt hiszem, hogy itt érdemes megjegyeznem, hogy lopás esetén a tolvajok kevésbé agytröszt részét nem tartja vissza az, hogy tisztában vannak azzal, hogy a mobil pozíciója könnyen meghatározható, ugyanakkor nem célszerű töltött lőfegyver, magánhadsereg, de minimum rendőri segítség nélkül a telefon után menni, ugyanis tragédiába is torkolhat a dolog, ugyan számoltak már be szórakoztató esetekről is amiknek a középpontjában nagyon hülye orgazdák állnak.

Lényeg, hogy az Android természetesen észleli, ha developer módban fut és az eszköz földrajzi helye pedig egész egyszerűen életszerűtlen módon változik, azaz például néhány másodperc alatt átkerül Zürichből Debrecenbe, a GIS-rendszerek pedig nem hülyék, azonnal észlelik, hogy a pozíció nem természetes módon változott meg és tudják is a helyzetet helyén kezelni – vagy a szolgáltatás, aminek szolgáltatják az adatot. Ahogy írtam korábban, a Facebook például annyira kifinomult, hogy ha valaki 13:00-kor még Budapesten lájkolgatott, 13:05-kor pedig rögtön beírja a helyes felhasználói nevet formálisan Rio de Janeiroban /*IP-cím alapján*/, annak túl sokféle magyarázata nem lehet. Az egyik, hogy valaki tényleg ellopta a jelszót és megpróbált belépni más nevében, a másik lehetőség pedig, hogy a felhasználó anonimizáló proxyt, VPN-t, TOR-t vagy hasonlót használ. Mindkét esetben a Facebook a szokatlan aktivitás miatt megpróbál róla meggyőződni, hogy valóban a tulajdonos szeretne belépni ezért még elkér ilyen-olyan adatokat. Viszont abban az esetben, ha valaki össze-vissza „ugrál” az IP-címe alapján, a Facebook nem fogja törni magát és valahanyadik belépés után már simán megy a belépés. Ebben az esetben nem az a GIS kifinomult, amelyik a Facebook alatt fut, hanem ahogyan a Facebook használja a GIS-től kapott körülbelüli pozíciót.

Az Apple esetén a Find my phone szolgáltatásnál nem világos, csak sejthető, hogy a Macbookokat és iMac-eket hogyan találja meg annyira gyorsan az Apple, de sejthető, hogy a logika lényegében az, ami a mobiloknál, ráadásul a Macbook akkor is folyamatosan figyelheti a BSSID-ket, amikor egyébként altatva van – hiszen például a leveleket is letölti még attól. És nem lehet olyan egyszerűen legyilkolni benne a helymeghatározást, mintha egy értékes nem-Apple laptop lenne, aminél a tolvaj rögtön kigyalulja az oprendszert az esetlegesen rajta lévő helymeghatározó szoftverrel együtt.

Ha valaki valami miatt nem szeretné, hogy a földrajzi pozíciójának nyoma maradjon, annak azt a protokollt tudom javasolni, amit én követek néha: a SIM-kártyát átteszem egy régi butamobilba és nem viszek magammal semmit, amiben egyáltalán van lehetőség a geolocationre. Persze, a mobilszolgáltatóknál megmarad, hogy merre jártam, csak éppenséggel ez egyáltalán nem zavar, hiszen nem valami félelmetes hárombetűs szervezet elől akarok elbújni.

Tehát a geolocationt lehet szeretni, nem szeretni, de alapvetően a felhasználói élményt fokozza, bizonyos alkalmazások működése erre alapul. Használjuk ésszel.


[1] én már a WiW-érában sem illedelmeskedtem, akit nem ismertem meg arc alapján azonnal, nem volt egyértelmű, hogy biztosan az, akinek mondja magát vagy biztosra vettem, hogy értelmes tartalmat nem fog a falra hányni, azonnal elutasítottam a bejelölést, ha ismét jelölt, bónuszként le is tiltottam.
[2] a biztonsági okokból felszerelt kamerák egy része alapvetően nagyon pocsék felvételt készít az arcokról, ez viszont nem jelenti azt, hogy értelmetlen lenne a begyűjtött adat. Amikor például valaki egy bankautomatát berhel, közben nyilván mozog. A nagyon sok, rossz minőségű képkocka alapján pedig már előállítható olyan kép, ami alkalmas a személyazonosításra.
[3] A traceroutinget egyrészt alapvetően nem erre találták ki. OSX-ben és linux shellben a traceroute, Windows parancssor esetén pedig a tracert paranccsal érhető el, de elvégezhető webes felületen is: például ha nem tudjuk, hogy a Budapesti Műszaki Egyetem és valószínűleg annak webszervere melyik városban van, csinálhatunk felé egy nyomkövetést, amiből látszik, hogy a hoszt IP-je, annak „megfordítottja”, azaz reverse-elve az IP hosztnévvé Budapesten van, sokszor a végpont előtti IP-cím jelenti a hasznos információt vagy a hosztnév vagy az alhálózat alapján. Számos esetben viszont igen bonyolult technikákat alkalmaznak azért, hogy a földrajzi hely ne legyen egyértelmű, na meg azért, hogy a terheléselosztás biztosított legyen. Például ha valaki lekérdezi a Youtube.com IP-címét, kijön egy cím, ami az ARIN /*ez a RIPE USA-beli megfelelője*/ szerint Mountain Viewban van, Kaliforniában. Ha viszont lekérdezzük az IP-cím reverse-jét, akkor olyan hosztnevet kapunk, aminek a nevéből sejthető, hogy valójában az a szerver, amivel a böngésző felveszi a kapcsolatot, Budapesten van. Perpill. ezt a címet kaptam: 216.58.209.206, aminek a reverzje ennek feleltethető meg: bud02s22-in-f206.1e100.net. Amúgy a magyar felhasználók Gmail-es levelezését és Google Drive fájljait még csak véletlenül sem Magyarországon tárolja a Google :)

Képek innest: reddit.com, iconbeast.com, neilson.co.za

Pontosabb, bővebb magyarázat? Kapcsolatfelvétel? Kattints ide!