About...

Napi betevő adag elírás, elütés és helyesírási hiba egy helyen! Amúgy meg #információbiztonság #webcserkészet néha #élettudomány

bardóczi ákos @post.r

blogavatar

minőségi kontent-egyveleg

RSS

cimketenger

ITsec (37),privacy (17),Facebook (17),social media (11),itsec (11),egyéb (10),social web (9),biztonság (8),mobil (8),OSINT (6),jog (6),magánszféra (6),tudomány (6),szellemi tulajdon (6),Google (5),molbiol (5),felzárkóztató (5),webcserkészet (5),szájbarágó (5),plágium (4),Nobel-díj (4),kriminalisztika (4),terrorizmus (4),kultúra (4),big data (4),email (4),genetika (3),pszichológia (3),molekuláris biológia (3),biztonságpolitika (3),CRISPR (3),Android (3),online marketing (3),sajtó (3),élettudomány (3),gépi tanulás (3),Onedrive (3),üzenetküldés (3),jelszó (3),2015 (3),orvosi-fiziológiai (3),Apple (3),Gmail (3),reklám (3),konferencia (3),webkettő (3),biztonságtudatosság (3),kriptográfia (3),levelezés (3),magatartástudomány (3),azelsosprint (3),popszakma (3),hype (3),open source intelligence (3),torrent (3),nyelvtechnológia (3),bejutas (2),tweak (2),villámokosság (2),cas9 (2),Yoshinori Ohsumi (2),Hacktivity (2),génterápia (2),fiziológia (2),természetes nyelvfeldolgozás (2),Reblog Sprint (2),bűnügy (2),Pécs (2),nyílt forrású információszerzés (2),webkamera (2),deep web (2),P2P (2),Netacademia (2),arcfelismerés (2),DDoS (2),Balabit (2),bűnüldözés (2),TOR (2),kulturális evolúció (2),ransomware (2),hitelesítés (2),SPF (2),Whatsapp (2),neuropszichológia (2),szabad információáramlás (2),FUD (2),DKIM (2),2-FA (2),bolyai-díj 2015 (2),molekuláris genetika (2),jövő (2),sudo (2),IDC (2),cyberbullying (2),social engineering (2),malware (2),tartalomszolgáltatás (2),meetup (2),facebook (2),reblog (2),videó (2),titkosítás (2),kutatás (2),epic fail (2),pedofília (2),netkultúra (2),nyelvtudomány (2),vírus (2),hírszerzés (2),iOS (2),farmakológia (2),szociálpszichológia (2),tanulás (2),biológia (2),gépház (2),bulvár (2),bug (2),Tinder (2),öröklődő betegség (2),Yandex (2),könyv (2),beszélgetés rögzítése (2),pszeudo-poszt (2),Twitter (2)

Ugyan semmi, csak a heti Android-malware


Hivatalos alkalmazásboltból lett letöltve, több százezer felhasználó által, akik 4+ pontosra osztályozták, legitim alkalmazásnak tűnik és a mobilplatform bármely mobilját érinti, nem csak a megbuheráltakat, mi az? Igen, androidos kémprogram, mi más.

Már ha egyáltalán hírértékű az Android-mezőnyben, hogy a Google Play Storeban azonosítottak néhány olyan alkalmazást, amit letöltöttek és kitűnőre értékeltek több százezren, és teljesen mindegy, hogy az adott mobil rootolva van vagy sincs, így is, úgy is viszi az egész házat, pofátlanul gyakorlatilag minden adatot, amit csak lát. Ne legyenek illúzióink, a válogatás nélkül, minden áldozattól kilopott és összegyűjtött információ minden bizonnyal megvehető a feketepiacon, akár konkrét adatmasszaként, akár csak belépéshez szükséges felhasználói név-jelszó párosként, alighanem a díler csak annyit kérdez, hogy dekára vagy tonnaszámra venné a vásárló. Ilyesmit tesz lehetővé az a heti házikedvenc is, amit az ESET azonosított nemrég.

Az Android manapság olyan, mint a Windows 98 és Windows Millenium volt sokáig: mindenki tudta, hogy ön- és közveszélyes, de azért továbbra is mindenki használta, olyan sebezhetőségek illetve malware-ek megjelenése pedig, amik eget rengető, na meg részvénycibáló hatással lennének más platformokra, az Androidnál épphogy hírértékűek.

Mi több, előfordul, hogy még csak nem is kell alkalmazást telepíteni az androidos mobilra, mivel a felhasználó eleve úgy veszi meg hivatalosan a szolgáltató üzletében, hogy az eszközre  előtelepített alkalmazások lopják a felhasználói adatokat, ahogy az történt egy magyar szolgáltató által értékesített telefonszériával is. A hírt most nem keresem meg, de írom  egyszerűsítve, hogy mi történik a mobillal, mielőtt kikerül a polcokra. Úgy kell elképzelni a dolgot, hogy amikor az adott szolgáltató megrendel raklap számra adott márkájú, adott típusú mobilt, ahogyan azt is be kell állítani, hogy a mobil csak egy adott hálózattal álljon szóba – amíg nem függetlenítik – legyen rajta egy előtelepített Android, előtelepített alkalmazásokkal, ezt pedig ott csinálják, ahol a legolcsóbb, mondjuk Kínában, hol máshol. Miután elvégezték az előtelepítést, megy mondjuk Magyarországra, aztán persze kutya sem ellenőrzi, hogy a mobil nem küld-e a kelleténél több felhasználói adatot bárkiknek, a felhasználó tudta nélkül. Olyan ez a téma, mint a globális klímaváltozás vagy az éhínség, nem lehetne dokumentumfilmet csinálni abból, hogy az Android mindössze azzal, hogy olcsó, a mobilszegmens egy részét valahol a pattintott őskorban tartja, ehhez képest ha találnak egy bugot az iOS, Windows Phone vagy Blackberry egy ezer éve nem frissített verziójában, bégethet a nyáj, ha kihasználható a bug, ha nem. Ami meg aztán már végképp érthetetlen, hogy ha a felhasználók otthon, na meg a cégnél használnak személyi tűzfalat, vírusirtót, miért vesznek olyan mobilokat, amiről konkrétan tudják, alighanem lopható róla az égvilágon minden?  

Nos, normális ember nem engedné, hogy egy teljesen ismereten személy kattintgasson a LinkedINjén, Facebookján, Google-fiókján, Tinderjén, turkáljon az SMS-ei közt, ráadásul mindent lementsen és bárkinek el is adja, aki fizet érte. Androidot bezzeg használ a fél világ. Hát így.

Ha eltűnnék több napra, túlságosan belemerültem az irracionális fogyasztói döntések kutatásába, eltűntem az óceánon, esetleg csak a Balatonba fulladtam bele.

A Linux Torvaldsnak tulajdonított idézet szerint „Talk is cheap. Show me the code.”, szóval mostantól majdnem minden poszthoz írok példakódot könyvajánlót is annak, akit behatóbban érdekelnek a témák.  

Android-alapú szoftverfejlesztés - Az Android rendszer programozásának bemutatása (Ekler Péter - Fehér Marcell - Forstner Bertalan - Kelényi Imre)


Kép: phandroid.com

0 Tovább

Fesztiválhekkelés: karszalag-barkácspraktika


Ugorjunk is át azon a témán, hogy a nyári szabad idő eltöltésekor a fesztiválozás, a koncertezés vagy éppenséggel a disco a legmenőbb, szerintem az utolsó. Ami tény, hogy akármilyen rendezvényről is szó van, nagyon gyakran alkalmazott módszer a tömeges beléptetésnél a karszalag, aminek a lényege, hogy egy rendezvényen való részvétel joga ne legyen átruházható, ennek megfelelően vannak kialakítva a karszalagok is: feltenni mindet nagyon egyszerű, viszont ha valaki leveszi valami miatt - magyarul letépi vagy levágja - az teljesen biztos, hogy még ha ismét összerakható is, a biztonsági őr egyszerűen kiszúrja és nem engedi a belépést később. Elképzelhető olyan szituáció, ami miatt mégis szükséges egy karszalag leszedése olyan módon, hogy az ne sérüljön meg és később simán vissza lehessen tenni: mondjuk ha egy egyébként meglehetősen értékes kedvezményekre jogosító, egész nyárra érvényes karszalagnak - valószínűleg a festékanyaga - az én bőrömön allergiás reakciót vált ki néhány óra után.

Ha karszalagokról van szó, a legegyszerűbb a mindenki által jól ismert papír karszalag, ennél erősebb, stabilabb kell a nagyobb fesztiválok résztvevőinek, ekkor a karszalag anyaga is erősebb, gondolom nehezebben hamisítható és egy plombaszerű izé zárja le olyan módon, hogy a vendég akár a szalagot vágja el, akár a plombát töri le, annak nyoma marad: a karszalag érvénytelenné válik. Biztos van még néhány típus, én tegnap ugrottam el egyik kedvenc magyarországi szórakozóhelyemre, amelyik az adott nap olyan karszalagot adott a vendégeinek, amik jelentős belépési kedvezményeket jelent a nyár további részében, ami pedig a lényeg, hogy olyan megoldást használtak, amilyet én még korábban nem láttam, a karszalagnak viszont a nyár végéig a vendég csuklóján kell lennie, ami nem feltétlenül kényelmes megoldás.

 Az elvi működést lehetővé tevő felépítés a következő: adott egy műszál alapú, talán nagyrészt poliészter szövet szalag, aminek az egyik oldala hófehér, a másik oldala pedig mintás, mindez pedig egy olyan lapított gyűrűbe fut bele, aminek a belsejében alulról és felülről 4-4, egy irányba döntött fog található, ami "harapja" a szalag szövetét. A gyűrűben tehát egyik irányban minden további nélkül elmozdulhat a szalag, viszont ezzel ellentétes irányba már nem, ez biztosítja azt a stabilitást, ami miatt kizárt, hogy véletlenül leesik miközben a kultúrafogyasztó plázabenszülött bemindenezve révül a legújabb AVICII-re a tánctéren és persze, ami miatt leszedni csak úgy lehet, hogy visszaapplikálni nyom nélkül már esélytelen. Azért annyira mégsem. Inkább mutatom fotókkal, a gyűrű az eredeti fehér, szalagként pedig az ott kapott, szinte azonos anyagtechnológiai tulajdonságokkal rendelkező fekete szalagot használtam a képek elkészítésénél a szemléletesség miatt.

Fogak a gyűrű belsejében

Ahogy az ki fog derülni, még azt sem lehet megjátszani, hogy a vendég nem húzatja olyan szorosra a karszalagot a hostessel, olyan logika mentén, hogy ekkor elvileg a kézfejen keresztül ki lehetne bújni belőle, majd feltenni, amikor ismét kell.
 

Nos, mivel nekem már pár óra után kezdett vörösödni a csuklóm - tudjuk be annak, hogy a karszalag festékére allergiás a bőröm - a parti után azon agyaltam, hogy hogyan lehetne mégis úgy leszedni okosba', hogy később visszatehető legyen. Kézügyességet igénylő dolgokat nem csináltam soha, az ördöglakatokhoz sosem volt elég türelmem, a lockpickinghez mindig hülye voltam, máig csak a legegyszerűbb zárakat tudom kinyitni kulcs nélkül, ami viszont a karszalagot illeti, az is motivált, hogy meg tudom-e csinálni, ráadásul egyedül, azaz egy szabad kézzel.

A kézenfekvőnek tűnő, de nyilván hülye ötletek elvetése után abból indultam ki, hogy ha a működés arra az elvre épül, hogy hogyan kapcsolódik egymáshoz egy alapvetően lágy anyag, azaz a szalag és egy teljesen rigid anyag, azaz a gyűrű a fogakkal, akkor ilyen irányba lenne érdemes keresni a megoldást. A megoldás még mindig nem adja magát, de azért már derenghet: törjem ki a fogakat? Nem lenne egyszerű, mivel eleve annyira a szalagnak is van  térkitöltése a gyűrűbe húzva, hogy egy vékony szög se nagyon férne hozzá, vastagabb pedig a szalagot roncsolná. A cél tehát, hogy a fogak valamilyen módon engedjék el a szalagot. 

 Ekkor kitaláltam, hogy éppen azt a sajátosságot lehetne kihasználni, - na még egyszer: a gyűrű csak a lágy anyagokat fogja meg, a rigideket nem, a működés lényege pedig egy teljesen rigid és hegyes és egy, mondjuk úgy beakadós anyag közti, tisztán fizikai kapcsolódás. Ezért fogtam egy egyszerű PE-palackot, abból kivágtam egy olyan szélességű csíkot, ami a szalaghoz hasonló szélességű. A PE-csíkot pedig egyszerűen befűztem a szalag és a gyűrű fogai közé a megfelelő menetirány felől (mivel ugye a fogak cca. 45 fokban döntöttek) és violá a fogak elváltak a szalagtól. A felső rész könnyen ment, de még mindig van alul is 4 fog, ami tartja a szalagot. Innentől jött egy adag bénázás, mivel alapvetően csak az egyik kezemet használhattam, másrészt a második PE-csíkot már eleve sokkal nehezebben sikerült becsúsztatni, mivel ekkorra már eléggé szorosan állt az egész a gyűrűben. Inkább mutatom, itt csak az egyik oldalra fűztem be a PE-csíkot:

Ennyike, minimális mozgatás után a PE-csík a fogakat elválasztja a szalagtól, vegyük észre, hogy a PE-csíkba pedig nem tud beleharapni a gyűrű foga a rigiditása miatt, elcsúszik rajta, maga a szalag pedig mindkét irányba húzható, legközelebb is fel tudom tenni, ha megyek. Minimális az esélye, de ha már legközelebb kidobnak ezen népi bölcsesség közzététele miatt, viszont, ha tudnak belőle meríteni a fesztiválozók, már megérte megírnom.

A technika pedig nyilván tovább finomítható. A következő használat előtt azért, hogy a gyűrű egyrészt eléggé szoros legyen, viszont kevésbé szoruljon rá az anyagra, így kevésbe „rágcsálja” azt, ennek kiküszöbölésére azt találtam ki, hogy a gyűrű belső fogait vagy alul vagy felül "kihúzom", azaz kitöröm, amikor még a szalag nincs benne. Ami annyira nem egyszerű, mert a szinte minden anyagon átmenni képes orvosi szikével nem férek hozzá, a körömollóval lehet próbálkozni, de csak részleges lesz, inkább csak a fogak tetjén koptatja egy picit. Egy felhevített tű nyilván leolvasztaná a fogakat, nem vagyok sem idegsebész, sem órásmester, mi több, a kézügyességem az átlaghoz képest kimondottan rossz, viszont ebben az esetben elég lenne egy egészen apró, nem kívánt elmozdulás a felhevített tűvel, aztán a gyűrű úgy sérülhetne meg, hogy arról már levágósabb lehet, hogy valaki megpróbálta meghekkelni.

Záró megjegyzésként írom, hogy hasonlóan sok más itteni blogposztban leírthoz, ez a módszer is egy elméleti lehetőséget mutat be, proof-of-concepttel, ami nem jelenti azt, hogy próbáld is ki otthon azért, hogy átadd a haverodnak egy fesztiválon mondjuk, ami nemes dolognak tűnik, viszont nyilván sérti a rendezvény szervezőinek az érdekeit, azokat a szabályokat is, amiket egy rendezvénnyel való részvételkor elfogadsz, röviden fogalmazva csalás leszedni egy karszalagot azért, hogy utána más is tudja használni, hiszen az átruházhatatlanság a lényeg.

Azért nem használtam végig technikai szakkifejezéseket, mert lövésem sincs a témához, viszont ha ezt technika tanárként, anyagtechnológusként, lockpickerként, fizikusként olvasod, szivesen veszem, ha írsz, akár kommentben, akár magánban.

Ja, amúgy ezer hálám az esztergomi gimnazista csávónak, aki megmutatta a gyakorlatban, hogy az ingyenpiáért hogyan lehet duplán sorba állni - mivel korlátlan italfogyasztás van ugyan, de olyan suttyó módon megoldva, hogy a pultos akkor sem fog kettőt adni egyszerre egy vendégnek, ha amúgy tudja, hogy mindenki 15-30 percet várakozhat arra a piára.

 Ilyesmiből ismerheted fel, ha esetleg allergiás lennél valamilyen festékanyagra, amik a karszalagokra kerülnek.  

0 Tovább

A web tudja hol vagy: szinte mindig


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

1 Tovább