Egy újfajta követési módszert fedtek fel biztonsági kutatók, amelyet a Meta és a Yandex alkalmaz, és amely potenciálisan milliárdnyi Android-felhasználót érinthet. Megállapították, hogy egyes natív Android-alkalmazások – köztük a Facebook, az Instagram, valamint több Yandex-alkalmazás, például a Térkép és a Böngésző – rögzített helyi portokon keresztül, csendben figyelnek a követés céljából. Ezek a natív Android-alkalmazások olyan metaadatokat, sütiket (cookies) és utasításokat fogadnak a böngészőktől, amelyeket a Meta Pixel és a Yandex Metrica JavaScriptjei továbbítanak – ezek a szkriptek több ezer weboldalba vannak beágyazva. A felhasználók mobilböngészőiben betöltődő JavaScriptek rejtve kapcsolatba lépnek az ugyanazon eszközön futó natív alkalmazásokkal a localhost socketeken keresztül. Mivel a natív alkalmazások programozott módon hozzáférnek olyan eszközazonosítókhoz, mint az Android hirdetési azonosító (Android Advertising ID, AAID), vagy felhasználói azonosítókat kezelnek – mint a Meta-alkalmazások esetében –, ez a módszer lehetővé teszi a szervezetek számára, hogy összekapcsolják a mobilos böngészési munkameneteket és webes sütiket a felhasználói identitásokkal. Így a látogatók anonimitása megszűnik azon oldalak esetében, amelyek ezeket a szkripteket használják.

A kutatás feltárt egy új típusú követési technikát, amely kihasználja az Android platformok és böngészők azon sajátosságát, hogy a localhost socketekhez való hozzáférés jellemzően nem korlátozott. Ez az eljárás lehetővé teszi a weboldalak számára, hogy a natív alkalmazásokkal kommunikáljanak – a felhasználó tudta és hozzájárulása nélkül. Ez a web–alkalmazás közötti azonosítómegosztás megkerüli a tipikus adatvédelmi védelmeket, például a sütik törlését, az inkognitómódot és az Android jogosultságkezelését. Ráadásul megnyitja az utat a rosszindulatú alkalmazások előtt is, amelyek kihallgathatják a felhasználók webböngészési tevékenységét.

Lehet ezentúl mellőzni kellene a telefonodról a Facebook, az Instagram, és a Yandex alkalmazásait? A hatalmas GDPR-sértési botrány, hatalmas büntetéssel jár majd?

Visszaélési lehetőségek

A követési módszer a következő rendszerszintű védelmeket kerüli meg:

• Böngésző sandboxing (elszigetelés),
• Mobilplatform- és böngészőengedélyek,
• Webes hozzájárulási modellek (cookie banner, GDPR-értesítések),
• Ingyenesen kínált adatvédelmi módok (pl. inkognitó mód),
• Reklámazonosító (AAID) visszaállítása,
• Sütik törlése.

Ezek egyike sem elégséges annak megakadályozására, hogy egy weboldal JavaScript kódja a háttérben futó natív alkalmazásokkal kommunikáljon localhost portokon keresztül, és így tartós, platformokon átívelő felhasználói azonosítást végezzen.

Megjegyzés: A localhost socketek természetesen használhatóak legitim célokra (pl. fejlesztői tesztelés). Azonban jelen kutatás volt az első dokumentált eset, amikor ilyen mechanizmust élesben használtak valódi követésre, tömegesen.

Hogyan működik mindez?

Bár a Meta és a Yandex kissé eltérő módon hidalja át a webes és mobilos kontextusokat, mindkét esetben a localhost socketek nem megfelelő használatáról van szó. Az Android operációs rendszer lehetővé teszi bármely telepített alkalmazás számára, amely rendelkezik az INTERNET jogosultsággal, hogy a loopback interfészen (127.0.0.1) hallgató socketet nyisson. Az ugyanazon eszközön futó böngészők is elérhetik ezt az interfészt – felhasználói engedély vagy platformszintű közvetítés nélkül. Ez lehetővé teszi, hogy a weboldalakba beágyazott JavaScriptek kommunikáljanak a natív Android-alkalmazásokkal, megosztva az azonosítókat és a böngészési szokásokat. Így az ideiglenes webes azonosítókat tartós mobilalkalmazás-azonosítókkal lehet összekapcsolni, szabványos Web API-kon keresztül.

Meta/Facebook Pixel: _fbp süti megosztása webes környezetből Meta Android-alkalmazásokkal

Amikor a Meta (Facebook) Pixel JavaScript betöltődik egy Android mobilböngészőben, a saját domainre vonatkozó _fbp sütit a WebRTC segítségével UDP portokon (12580–12585) keresztül továbbítja minden olyan alkalmazásnak az eszközön, amely ezekre a portokra figyel. Megállapítottuk, hogy a Meta tulajdonában álló Android-alkalmazások – köztük a Facebook (pl. 515.0.0.23.90-es verzió) és az Instagram (pl. 382.0.0.43.84-es verzió) – figyelnek ezekre a portokra. Ezek az alkalmazások elérhetők a Google Play Áruházban.

A Meta Pixel az SDP Munging technikát használja a _fbp süti tartalmának elrejtésére

A Meta Pixel egy SDP Munging néven ismert technikát alkalmaz, hogy a _fbp süti tartalmát elrejtse az SDP protokoll ice-ufrag mezőjében. Ez az eljárás azt eredményezi, hogy egy STUN Binding Request üzenet kerül elküldésre a localhost (loopback) címre – ahogy az alábbi ábra is mutatja (az eredeti szöveg szerint). Ez az adatáramlás nem figyelhető meg a Chrome szokásos hibakereső eszközeivel (például a DevTools segítségével).

Nem útmutató az SDP Munginghoz – de érdemes megérteni

Az SDP (Session Description Protocol) visszatérő téma a WebRTC környezetében, beleértve a webrtcHacks blogbejegyzéseit és a szabványosítási vitákat is. Az SDP módosításának nem hivatalos, kézzel végzett formáját nevezik SDP Mungingnak. Ez a gyakorlat megkerül bizonyos API-k által szabályozott működést, és problémás is lehet.

Ez a rész nem útmutató a munginghoz, hanem áttekintést ad arról, mi az SDP munging, miért alkalmazzák, és miért nem lenne szabad használni.

Röviden az SDP szerepe a WebRTC 1.0-ban

A WebRTC 1.0 API lehetővé teszi a helyi audio/video és adat továbbítását egy távoli WebRTC partnerhez. Az ehhez szükséges paraméterek átadására szolgál az SDP. Bármilyen helyi műveletet is végzünk, az eredményül létrejövő SDP-t el kell küldenünk a partnernek (vagy hagynunk kell, hogy ő készítse el a saját reprezentációját), amit aztán a setRemoteDescription() metódussal alkalmaz a saját WebRTC kapcsolatában.

A webrtcHacks részletes soronkénti útmutatót is közöl az SDP felépítéséről.

Az SDP főbb feladatai:

• ICE paraméterek: Hálózati kapcsolat kiépítéséhez a partnerek között, beleértve a lehetséges ICE candidate-eket is.
• DTLS paraméterek: A DTLS kézfogáshoz és az SRTP kulcsok cseréjéhez, amelyek az audio/video titkosított továbbítását teszik lehetővé.
• RTP paraméterek: Meghatározzák, milyen médiafolyamokat kíván küldeni és fogadni a peer.

Mi az az SDP Munging?

Az SDP munging azt jelenti, hogy manuálisan módosítjuk az SDP-t, ahelyett hogy a WebRTC API-k automatikus működésére hagyatkoznánk. Például egy gyakori munging-módszer a kodekek törlése vagy prioritásuk megváltoztatása az SDP-ben.

A munging alkalmazható két helyen:

pc.createOffer()
  .then((offer) => {
    // itt lehet módosítani az SDP-t
    pc.setLocalDescription(offer);
    // vagy a szignálás során küldeni a partnernek
  });

Az SDP tehát módosítható:

• a setLocalDescription() előtt (helyileg), vagy
• a szignálási folyamat során, amikor a másik peer-nek küldjük.

Miért nem megengedett az SDP módosítása?

A WebRTC szabvány szerint az offer és a setLocalDescription közötti munging nem megengedett, és InvalidModificationError hibát eredményezhet.

Miért ilyen szigorú ez a szabály?
Mert a böngészőknek nagyon nehéz lenne értelmezni a kézzel elvégzett módosításokat, és kitalálni a fejlesztő szándékát. Például, ha JavaScripten keresztül bárki módosíthatná az ICE ufrag/pwd mezőket (amelyeket a Meta is kihasznál), az komoly biztonsági problémákat okozna.

Az újabb böngészőverziók (Chrome, Firefox) ezért már engedik, hogy a setLocalDescription() paraméter nélkül is meghívható legyen – ilyenkor a legutóbbi offer vagy answer automatikusan alkalmazásra kerül. Ez a jövő útja, de még nem minden platform támogatja teljesen.

Összefoglalás: hogyan használja ezt a Meta?

A Meta a fent leírt SDP munging segítségével manipulálja az SDP struktúrát, hogy a _fbp süti tartalmát az ice-ufrag mezőbe rejtse. Ez az adat aztán egy STUN üzenetként kerül továbbításra a localhost UDP portjaira, ahol az eszközön futó Meta-alkalmazások (pl. Facebook, Instagram) várakoznak az adatfogadásra. Ezzel a módszerrel a webes sütik és a mobilalkalmazásban használt állandó azonosítók összekapcsolhatók, kikerülve az Android biztonsági és adatvédelmi védelmeit.

Munging a szignálás során

Az SDP munging második formája a szignálási folyamat során történik. Ez nem tiltott, mivel a WebRTC specifikáció nem határozza meg pontosan, hogyan kell a szignálást (jelzéscserét) lebonyolítani. Így lehetőség nyílik kreatív megoldásokra és kerülőutakra, például azokra, amelyeket a szerző a simulcast playground projektjében alkalmazott.

Ez a munging megtörténhet:

• a helyi kliens oldalán,
• a szignálószerveren, vagy
• a távoli kliensnél.

Ez továbbra is teljesen érvényes módja az SDP ajánlatok (offer) és válaszok (answer) kezelésének, és a jövőben sem fog eltűnni. Ugyanakkor figyelmeztetés: ha valami elromlik, a fejlesztő maga felelős a következményekért.

Tényleg még mindig szükség van az SDP mungingra?

Az SDP munging betiltásáról szóló viták már 2016 óta zajlanak (Tsahi Levent-Levi már akkor is írt egy hasznos blogbejegyzést – és a tanácsai ma is megállják a helyüket). Bár azóta lassan halad a WebRTC szabvány SDP-mentes működése felé, néhány előrelépés már történt.

Példák, ahol már nem szükséges munging:

• Bizonyos esetekben, például sávszélesség-módosításnál, az ORTC objektum-orientált API már képes kiváltani az SDP mungingot.
  (Lásd a WebRTC ORTC mintapéldáit.)

De még mindig vannak esetek, ahol szükség van rá:

• Például ha valaki sztereó hangot szeretne lejátszani Freeswitch használatával, akkor a böngésző által küldött helyi SDP-t kell módosítani, és hozzáadni a következőt az opus kodek sorához: stereo=1.
  Ez a lehetőség dokumentált hibához is vezetett, mivel a megoldás nem volt nyilvánvaló, és sok időt és kutatást igényelt.

• Másik fontos példa: a simulcast (több videófolyam párhuzamos küldése különböző felbontásokban).
  A simulcast támogatása lényegében változatlan azóta, hogy a szerző 2014-ben megírta az első elemzését a Google Hangouts működéséről.

  Bár a Chrome már biztosít API-t a simulcast SDP-módosítás nélküli engedélyezésére, ez az eljárás nem működik, ha a távoli fél küldi az offer-t.
  Ráadásul a Chrome nem szerepeltet SSRC-ket ebben az esetben, ami komoly gondot okoz az SFU (Selective Forwarding Unit) fejlesztőknek, és akadályozza a széles körű alkalmazást.

Milyen gyakori az SDP munging?

A ChromeStatus statisztikái alapján kapunk választ erre a kérdésre.
A RTCLocalSdpModification nevű mérőszám azt mutatja, hányszor történik SDP munging a setLocalDescription előtt – ez az a változat, amit a Chrome közvetlenül képes mérni.

• 2018 márciusában adták hozzá ezt a mérést, és júniusban került be a stabil verzióba.
• Akkor a munging a betöltések ~0,04%-ánál fordult elő.
• Ez mára 0,075%-ra emelkedett.
• Összevetésül: a getUserMedia API-t csak a betöltések 0,07%-ában használják, így a valódi SDP munging arány valószínűleg ennél magasabb.

A simulcast-munging pontos mérésének első eredményei a következő hetekben várhatóak.

Munging, tűnj el végre?

Ennek ellenére – hosszú távon az SDP mungingot el kell hagyni.
A Chrome már nyomon követi a deprekációját, de a tényleges eltávolítás nem várható a közeljövőben.

Már a Chrome 82 verzióban is szerepelt egy fejlesztés:
a chrome://webrtc-internals oldalon a böngésző észleli és jelöli az SDP módosítását a setLocalDescription előtt, egyszerű karakterlánc-összehasonlítással.

Ez lehetővé teszi a fejlesztőknek, hogy:

• átvizsgálják alkalmazásaikat,
• azonosítsák az SDP munging eseteit,
• és eldöntsék, létezik-e helyette hivatalos API vagy szabványos megoldás.

Ha olyan esetben használsz SDP mungingot, amelyre még nem létezik alternatíva, érdemes jelezni a fejlesztőknek.
Egy Twitter thread már most is tartalmaz jó válaszokat és példákat.

A _fbp süti rejtett útja: Webről natív appba, majd szerverre

A Meta Pixel működése mögötti technikai folyamat újabb rétegeire derült fény. A következő szakasz részletezi, hogyan juttatja el a _fbp nevű süti tartalmát a Meta (Facebook, Instagram) a böngészőből a natív mobilalkalmazásokba, majd a szerverekre – a WebRTC protokoll kihasználásával.

A teljes _fbp adatfolyam lépésről lépésre

1. A felhasználó megnyitja a Facebook vagy Instagram natív alkalmazást.
   Az alkalmazás háttérbe kerül, és háttérszolgáltatást indít, amely figyeli a bejövő TCP-forgalmat (port: 12387 vagy 12388) és egy elérhető UDP-portot a 12580–12585 tartományból. Ehhez a felhasználónak bejelentkezve kell lennie.
2. A felhasználó böngészőben megnyit egy Meta Pixel integrációt tartalmazó weboldalt.
   A weboldal jogi környezetétől függően hozzájárulást kérhet a követéshez.
3. A Meta Pixel JavaScript a _fbp sütit elküldi a natív alkalmazásnak WebRTC-n keresztül.
   Ennek technikai módja az ún. SDP munging, amelynek során a _fbp értéket beleírják az SDP protokoll ice-ufrag mezőjébe, és egy STUN Binding Request üzenetben továbbítják a localhost felé.
4. Ugyanez a JavaScript elküldi a _fbp süti értékét a Meta szervereire is.
   A cél URL: https://www.facebook.com/tr, ahol a _fbp mellett más adatok is szerepelnek:
   • az oldal címe (dl),
   • böngésző- és eszközinformációk,
   • eseménytípus (ev), pl. PageView, Purchase stb.
5. A Facebook vagy Instagram alkalmazás megkapja a böngészőből jövő _fbp értéket, és GraphQL API-n keresztül továbbítja azt a https://graph.facebook.com/graphql végpontra.
   Ezzel összekapcsolják a böngésző süti azonosítóját a felhasználó Facebook- vagy Instagram-fiókjával, vagyis cross-site követést valósítanak meg a _fbp süti segítségével – annak ellenére, hogy az elvileg csak first-party süti.

Változás 2025 májusától: SDP helyett TURN

2025. május 17. után a Meta Pixel szkriptje új módszert vezetett be: a _fbp továbbítása WebRTC TURN segítségével történik, nem pedig STUN/SDP munging útján.

Ez a változás azért fontos, mert:

• a Chrome fejlesztői jelezték, hogy az SDP mungingot hamarosan letiltják, különösen az ilyen nem rendeltetésszerű használatok miatt.
• A TURN módszer megkerüli az SDP mungingot, így továbbra is működik a _fbp átadás, még ha az SDP manipuláció tiltottá válik is.

Ugyanakkor 2025. június 2-ig nem észleltek aktív hallgatózást az új TURN-hoz használt portokon a Facebook és Instagram appok részéről.

Mi az a _fbp süti?

A Meta hivatalos cookie-szabályzata szerint:

„Az _fbp süti célja, hogy azonosítsa a böngészőket hirdetési és analitikai célokra. Élettartama 90 nap.”

Ez a süti a Web Almanac 2024 szerint a harmadik leggyakoribb első féltől származó süti az interneten – a top 1 millió weboldal 25%-án megtalálható.

Mivel first-party süti, elvileg nem használható fel több weboldalon keresztüli követésre. Ugyanakkor a fent ismertetett módszer segítségével:

• összeköthetők a különböző weboldalakon létrejött _fbp értékek,
• így megkerülhetők a böngészők beépített követésvédelmi mechanizmusai,
• és ellentmond a felhasználók adatvédelmi elvárásainak.

Yandex: 2017 óta ez a működésük része

A Yandex is alkalmaz hasonló trükköket, sőt, már 2017 óta.
A Yandex Metrica szkriptje:

• hosszú, nehezen értelmezhető paraméterekkel küld HTTP-kéréseket a localhostra,
• az alábbi TCP portokat használja: 29009, 29010, 30102, 30103.

A kutatások szerint:

• a Yandex saját alkalmazásai (Térkép, Navigátor, Böngésző stb.) hallgatóznak ezeken a portokon,
• a yandexmetrica[.]com domain 127.0.0.1-re (loopback) oldódik fel,
• az adatátvitel HTTPS-en keresztül történik, a fent említett helyi portokra,
• ezzel elrejtik az adatgyűjtést, és megnehezítik a hagyományos felhasználói vagy biztonsági észlelést.

Következtetés

A _fbp süti útjának WebRTC-n keresztül történő továbbítása:

• technikai bravúr, ugyanakkor agresszív adatgyűjtési módszer,
• meghaladja az általános felhasználói tudás és átláthatóság kereteit,
• és komoly kérdéseket vet fel a böngészők, adatvédelmi szabályozók és a közvélemény számára is.

Yandex Metrica és a háttérkommunikáció: Android azonosítók továbbítása a böngészőn keresztül

A Yandex Metrica megfigyelési architektúrája egyedi és technikailag összetett megoldást használ arra, hogy a natív mobilalkalmazásokban elérhető Android-specifikus azonosítókat (például az AAID-t) eljuttassa a böngészőből futó JavaScript szkripthez. Az alábbi részletezés bemutatja a teljes adatáramlási folyamatot, a háttérben hallgatózó alkalmazások viselkedését, valamint azt, hogyan kerülnek az érzékeny eszközazonosítók vissza a Yandex szervereihez.

A teljes adatfolyam a weboldaltól a Yandex szerveréig

1. A felhasználó megnyit egy Yandex alkalmazást (pl. Yandex Maps, Search, Navigator, Browser).
   Az app háttérbe kerülése után háttérszolgáltatást indít, amely figyel:

   • HTTP portokon: 29009, 30102

   • HTTPS portokon: 29010, 30103

2. A háttérszolgáltatás portlistát kér a Yandex szervertől.
   A kérést a startup[.]mobile[.]yandex[.]net (vagy hasonló) címen keresztül végzi. A válasz JSON formátumú, tartalmazza:

   • a portok listáját,

   • egy first_delay_seconds értéket, amely meghatározza, mennyi idő múlva kezdődjön a hallgatás.
     Tesztek szerint ez az érték néha több nap késleltetést is jelenthet (pl. 3 nap).

3. A felhasználó böngészőben meglátogat egy Yandex Metrica szkriptet tartalmazó weboldalt.
   A szkript:

   • elküld egy kérést a Yandex szerver felé obfuszkált paraméterek lekérésére,

   • ezek után HTTP/HTTPS kérést küld a localhost felé a fent említett portokon keresztül.

4. A Yandex natív alkalmazás válaszol a localhost kérésekre.
   A válasz egy Base64-kódolt bináris adatcsomag, amely tartalmazza:

   • az Android Advertising ID-t (AAID),
   • más Java API-kon keresztül elérhető egyedi azonosítókat, mint például:
     • UUID,
     • Google Advertising ID (ha elérhető),
     • esetleg Yandex-specifikus eszközazonosítók.

5. A böngészőben futó Yandex Metrica szkript fogadja a választ, majd továbbítja:

   • a natív alkalmazástól kapott eszközazonosítókat,

   • az előzőleg lekért obfuszkált paraméterekkel együtt
     a Yandex Metrica szerver (pl. mc[.]yango[.]com) felé.

Yandex vs. Meta: eltérő adatáramlási modellek

Tulajdonság	Meta Pixel	Yandex Metrica
Kommunikáció típusa	WebRTC (SDP/STUN/ TURN)	Localhost HTTP/HTTPS socket
Adat célhelye	Natív app → Meta szerver (GraphQL)	Webes JS → Yandex szerver (mc.yango.com)
Azonosítók továbbítása	App küldi a _fbp értéket a szerverre	Weboldal JS küldi az eszköz ID-ket
Hallgatózó komponens	TCP/UDP portokon futó WebRTC listener	Lokális HTTP szerver az alkalmazásban
Egyedi azonosítók bevonása	Böngésző süti (_fbp)	Android AAID, UUID, Advertising ID
Beépített késleltetés (obfuscation)	Nem dokumentált	first_delay_seconds (~akár 3 nap)

Weboldalak viselkedése a Meta Pixel és Yandex Metrica kapcsán: Elemzés a követés mértékéről és időbeli alakulásáról

A következő összefoglaló a Meta Pixel és a Yandex Metrica által alkalmazott technikák elterjedtségét, működését és időbeli fejlődését mutatja be, különös tekintettel arra, hogy ezek a gyakorlatok milyen gyakran történnek felhasználói hozzájárulás nélkül. A vizsgálatok reprezentatív weboldalmintán alapulnak, nem teljes körűek, de így is súlyos adatvédelmi kérdéseket vetnek fel.

Vizsgálat módszertana

• A weboldalakat automatikus crawler látogatta meg.
• Összes cookie engedélyezése után 10 másodperces várakozás következett.
• A rendszer figyelte a:
  • HTTP-kéréseket,
  • WebSocket-kereteket,
  • WebRTC-hívásokat.
• Külön futtatás történt úgy is, hogy nem történt hozzájárulás a cookie-ablakhoz.

Eredmények: Hány weboldalon fordul elő az eszközszintű követés?

Meta Pixel

Régió	WebRTC/WebSocket kommunikáció a natív alkalmazások felé	Hozzájárulás nélkül is történik
EU	15,677 oldal	11,890 oldal
US	17,223 oldal	13,468 oldal

Felelős közzététel és gyártói reakciók

A kutatók a felfedezésüket felelősen jelentették a legfontosabb Android böngészőgyártók felé, ami több javításhoz vezetett:

Válaszlépések:

Böngésző	Válasz
Google Chrome	Javítás részben már élesítve, más fejlesztés alatt
Mozilla Firefox	Patch alkalmazva Android-verzióban	139.0.3: Mitigated a recently-disclosed privacy leak. The leak was caused by other apps installed on the phone that created and listened on ports accessed by the browser. 139.0.4: Further enhancements to the recently-deployed mitigations for the Local Mess privacy leak.
DuckDuckGo Browser	Védelmi mechanizmus beépítve
Brave	Gyors együttműködés, frissítés kiadva

Weboldal-tulajdonosok tájékozottsága: csekély vagy hiányos

Bár a Meta Pixel és a Yandex Metrica dokumentációiban semmilyen hivatalos említés nem található erről az újfajta követési módszerről, a webfejlesztői közösség már 2024 szeptemberétől kezdve észlelte a gyanús localhost-hívásokat. Ezekről tanúskodnak az alábbi visszajelzések a Facebook fejlesztői fórumain:

• „Facebook SDK config file making call to localhost”

• „Why does my Pixel Javascript access http://localhost when in an embedded web view on Android?”

Ezek a hozzászólások világszerte jelentkeztek, ám Meta részéről nem érkezett hivatalos válasz vagy technikai magyarázat. Egy fejlesztő így fogalmazott:

„Meta részéről semmiféle elismerés nem történt. A támogatási kérésemre sablonválaszt kaptam, majd nem reagáltak tovább. Szégyen, hogy nem vállalnak felelősséget. Ezekre az eszközökre támaszkodunk, de nincs kontrollunk felettük – a minimum az lenne, hogy elmagyarázzák, mi történik.”

Ez rávilágít arra, hogy a követés technikai rétegeit gyakran elrejtik a weboldal-üzemeltetők és fejlesztők elől is, akik csak SDK-konfigurációkat használnak, nem mélyülnek el azok hálózati viselkedésében.

Felhasználók tájékozottsága: gyakorlatilag nulla

A kutatás szerint a felhasználók semmilyen figyelmeztetést nem kapnak arról, hogy:

• Weboldalak a mobiltelefonjukon futó alkalmazásokkal kommunikálnak;
• A böngészőben futó JavaScript kódok helyi hálózati kapcsolatot létesítenek a háttérben;
• A natív alkalmazások (pl. Facebook, Yandex) érzékeny, eszközszintű azonosítókat (pl. AAID, UUID) küldenek vissza a weboldalnak.

Mindez akkor is megtörténik, ha a felhasználó:

• Nincs bejelentkezve sem a Facebook, sem a Yandex fiókjába a mobil böngészőjében,
• Privát böngészési módot (Incognito) használ,
• Törli a sütiket vagy böngészési adatokat,
• Nem járult hozzá a követéshez a cookie-banneren keresztül (vagy az el sem jelent meg).

Ez azt jelenti, hogy a követés:

meghaladja az Android platform jelenlegi adatvédelmi és szigetelési korlátait, beleértve a sandboxingot és a kliensoldali adatállapot törlését is.

Hozzájárulás nélküli követés – a legnagyobb aggály

A kutatás során végzett második böngészőfeltérképezési kampány szándékosan nem kattintott a cookie-hozzájárulási felületekre, hogy kiderüljön, megtörténik-e a követés hozzájárulás nélkül is.

Eredmények:

Metrika	EU (nincs hozzájárulás)	US (nincs hozzájárulás)
Meta Pixel localhost-hívás	11,890 weboldal	13,468 weboldal
Yandex localhost-hívás	1,064 weboldal	1,095 weboldal

 Köszönetnyilvánítás és szerzői információk

A kutatásban részt vevő csapat hálásan köszöni minden böngészőgyártónak a gyors és együttműködő fellépést, akik érdemi lépéseket tettek a localhost-alapú követés elleni védelem érdekében. A Chrome, Mozilla, DuckDuckGo és Brave fejlesztőcsapatai példamutató módon reagáltak a felelős bejelentésre.

Kiemelt köszönet illeti:

• Álvaro Feal – Mobilalkalmazások elemzésében nyújtott segítségéért
• Tom Van Goethem – A felelős sebezhetőség-bejelentés gondos kezeléséért
• Bart Preneel – Médiakommunikációs támogatásáért
• HTTP Archive Project – A nyilvánosan elérhető adatkészletért, amely lehetővé tette a hosszú távú elemzést
• Schloss Dagstuhl – Leibniz Center for Informatics – Az együttműködés elindításáért és ösztönzéséért

Kapcsolatfelvétel

A teljes kutatócsoport elérhető a következő e-mail címen:
localmess@pm.me

Szerzők (ábécésorrendben)

Név	Intézmény	Beosztás	Email
Aniketh Girish	IMDEA Networks	PhD hallgató	aniketh.girish@imdea.org
Gunes Acar	Radboud University (Digital Security Group & iHub)	Egyetemi adjunktus	g.acar@cs.ru.nl
Narseo Vallina-Rodriguez	IMDEA Networks	Egyetemi docens	narseo.vallina@imdea.org
Nipuna Weerasekara	IMDEA Networks	PhD hallgató	nipuna.weerasekara@imdea.org
Tim Vlummens	KU Leuven (COSIC)	PhD hallgató	tim.vlummens@esat.kuleuven.be

(forrás)