Ursprünglich veröffentlicht: https://www.kuketz-blog.de/web-zu-app-tracking-wie-meta-yandex-android-nutzer-deanonymisieren/
TL;DR Meta (Facebook/Instagram) und Yandex missbrauchen seit 2017 bzw. 2024 offene localhost-Ports auf Android, um Browser-Cookies mit Geräte-IDs ihrer Apps zu verknüpfen. Der Trick umgeht Inkognito-Modus, Cookie-Löschen und Werbe-ID-Reset. Milliarden Nutzer und Millionen Webseiten sind (oder waren) betroffen. Erste Schutzmaßnahmen sind bereits in Chrome 137 & Brave integriert. Meta hat den Code am 3. Juni 2025 weitgehend entfernt. Bis die »Lücke« geschlossen ist: Tracker blockieren, Browser aktualisieren, generell auf Meta-/Yandex-Apps verzichten bzw. diese deaktivieren, falls eine Deinstallation nicht möglich ist. Hintergrund Die Forschergruppe »Local Mess« zeigt, dass Webseiten-Skripte von Meta Pixel und Yandex Metrica über die Loopback-Adresse 127.0.0.1 mit installierten…
Wär schön wenn man entsprechende Bugzillaeinträge nachreichen könnte, sobald sie öffentlich bekannt sind.
Habe eine Frage:
ist die Ausgabe von „netstat“ hilfreich, um lauschende Apps zu entdecken? so z.B.:
raven:/ $ netstat -a -e | grep "LISTEN "
Hier erschienen für mich nur zwei Verdächtige, allerdings beide lauschend auf tcp6 auf localhost, und das waren Terminal (die neue App von Android, die lief gerade) und youtube (hatte ich letztens mal aktiviert, jetzt gleich wieder deaktiviert)
Das laufende System vom Terminal (192.168.0.2) benötigt zwar eine Verbindung zu 192.168.0.1(eine weitere IP des Gerätes, wenn das Terminal läuft), um überhaupt zu laufen, ansonsten gehen die Verbindungen dieser VM an z.B. NetGuard auch total vorbei.
Ergänzung: Vanadium in den Standardeinstellungen ist für die WebRTC-Variante (Meta-Variante) nicht anfällig und ist mit der heutigen Vanadium Config Version 95 gegen die Yandex-Variante gepatcht worden.
Ich fände es gut, wenn die Gegenmaßnahmen unterteilt würden, in welche, die das Problem wirklich angehen und andere, die es nur rudimentär beheben:
- Apps löschen hilft nur, wenn man die Apps kennt, die diese Methode des Trackings nutzen. Es könnte noch andere, unbekannte Apps geben, die die gleiche Methode nutzen
- Bei Blocklisten wissen wir auch nie ob alles geblockt wird, was diese Methode verwendet
- Die richtigen WebRTC-Einstellungen und der Chromium-Patch sind hingegen Mitigations, die das Problem als solches auch angehen. Braves Mitigations ebenfalls.
Die „Block Outsider Intrusion into LAN“ Liste in uBO sollte das aber zuverlässig verhindern. Womit auch z.B. Firefox-Nutzer geschützt wären.
Ansonsten schützt auch Dynamic Filtering in uBO mit einer globalen block-Regel für Facebook und Yandex.
uBlock Origin
EDIT: Wobei die genannte Liste auch in uBO Lite zur Verfügung steht.
danke
erstmaliges Erscheinen ist sonst immer nicht so toll für diejenigen, die es nicht kennen, ich habe es auch erst verstanden, als ich ins Menü schaute
PS: und was ist mit den ganzen WebApps?
Ich habe schon mehreren miese Bewertungen im Playstore gegeben, weil facebook eingebunden war, bei der „Mein Magenta“-App sah man damals in der Reaktion darauf das Problem nicht …
Sorry! Da es in diesem Forum wohl das am meisten empfohlene Add-on ist und schon häufig darüber diskutiert wurde, dachte ich, diese Abkürzung sei bekannt.
Ansonsten kannst du dir vielleicht auch mal mein Tutorial anschauen.
Sorry, ich bin ja noch selbst darauf gekommen, aber es gibt auch genug, die lesen nicht erst das ganze Forum durch, ehe sie wegen eines Problems hier vorbeischauen.
Meta und Yandex sind keine Open Source Projekte. Bei ihnen ist alles hinter verschlossener Türe.
Das bezieht sich auf Mozilla Projekte (z.b. Fixes für FF).
noch zu:
bzw.
in meinen Tests funktionierte das Profil-übergreifend auch mit der „externen“ IP des Gerätes
die Maßnahmen nur auf Localhost zu beschränken, ist nicht unbedingt die Lösung, innerhalb eines Profils wird es wohl auch die VPN-IP tun, habe ich aber nicht explizit getestet
Brave und WebDAV
nochmal mit der IP des NetGuard-„VPN“, hab WebDAV auf allen lauschen lassen, weil die IP nicht zur Wahl stand →
Ich denke nicht, dass dein Test so aussagekräftig ist bzgl des Trackingproblems. Der Webseitenkontext ist bei dir ein anderer als für einen Test notwendig wäre.
Möglicherweise, wenn das Script eines solchen bösartigen „Pixels“ keine Chance hat, die anderen IP-Adressen herauszufinden. Ich kenne sie im Test. Die von NetGuard ist default immer gleich. Die von RethinkDNS auch, da sollte es zumindest per IPv4 nicht profilübergreifend funktionieren.
Mir ging es eher darum, zu zeigen, daß der Zugriff auch mittels anderer IPs als der von localhost möglich ist.
Die Browser müßten den internen Zugriff auf die anderen also auch blocken.
nur auf IPv4 bezogen, im Screenshot sieht man, daß die IPv6-Adressen von Rethink unterschiedlich sind
NetGuard zeigt auch im vertraulichen Profil die Adressen von RethinkDNS in einem anderen Profil, also sind die aller Profile prinzipiell sichtbar, NetGuard hat nur nicht genug Platz reserviert, um alle drei*2 anzuzeigen
OT: die App habe ich bewertet, nur die Google-KI hat mir eine Mail geschickt, daß die Bewertung ausgeblendet wird …
PS: heute nun hab ich „Youtube Music“ beim Lauschen erwischt (hatte aber gestern einer im heise-Forum zum Artikel auch schon geschrieben)
Das hat damit nichts zu tun. Das Problem ist, dass dein Test überhaupt nicht der hier diskutierten Tracking-Methode entspricht. Du gibst direkt eine lokale Origin in die Adresszeile des Browsers ein. Das sollte auch mit den neuen Mitigations noch funktionieren, da das eine legitime Anwendung ist.
Das Problem tritt erst dann auf, wenn du eine nicht-lokale Webseite in die Adresszeile des Browsers eingibst und diese plötzlich mit Diensten auf localhost kommunizieren kann, ohne die explizite Zustimmung des Nutzers. Das ist aus technischer Sicht ein völlig anderer Fall.
Mir ist klar, daß ich das explizit ala Nutzer eingegeben habe. Vielleicht ist mein Verständnis von „localhost“ falsch, aber bisher habe ich das immer mit „127.0.0.1“ in Verbindung gebracht, nicht mit den anderen Adressen. Die anderen Adressen sind zwar quasi auch lokal, aber eben auch von extern erreichbar.
Wenn diese auch für z.B. „Brave“ als „localhost“ gelten, dann hätte man mit der Erklärung das ganze abkürzen können.
Ist es so?
BTW: jetzt lauschten die Google Play Dienste
Sie sollten eben nicht von extern erreichbar sein, aber das zeigst du mit deinem Test nicht. Bist du damit vertraut, wie Browser einen Kontext und Einschränkungen für Webseiten herstellen, z.B. mit der Same Origin Policy, CORS usw.?
Wenn sie an das jeweilige Interface gebunden sind und nicht zum Beispiel NetGuard aufgrund der VPN-Beschränkungen den Zugriff nicht zuläßt, dann sollten die jeweiligen lauschenden Port auch von extern an dieses Interface angebundenen Geräten erreichbar sein.
Weniger, hätte zwar Relevanz in Bezug auf die verwendeten Browser, aber da ich das Problem weniger im Browser sehe, als eben im System (von Android), welches selbst profilübergreifende Aktionen erlaubt, die nicht zulässig sein dürften.
Natürlich ist der Browser als Schnittstelle zur Außenwelt von Relevanz, aber ansich sollte das System ihn daran hindern, entsprechende Aktionen überhaupt auszuführen, zweiter Schritt ist, daß der Browser keine Aktionen zuläßt, die nicht im Nutzerinteresse sind. So stellt der Browser eher eine Art Stopschild dar.
Kürzlich gab es ja wieder eine Problem mit Chrome, schrieb wohl wiedermal irgendwohin …
… Aufgabe des Systems sollte es sein, ihn daran hindern zu können.
Ob nun Meta, Yandex oder Google, das sind quasi die trojanischen Pferde, die ohne weitere Nutzeraktionen diese Lücken im System nutzen und die Daten ausschleusen, so man sie nicht blocken kann.
Es werden Workarounds um Lücken gebastelt, ohne dem Nutzer standardmäßig Eingriffsmöglichkeiten zu geben.
Das ist ein anderes Thema und hat nichts mit dem Thema hier zu tun.