Covert web-to-app tracking via localhost on Android

Original Article ↗ Hacker News Discussion ↗

Nature of the exploit

  • Meta Pixel on Android used WebRTC (STUN, later TURN) to send a first‑party tracking cookie to UDP ports on localhost, where FB/IG apps were listening, letting Meta link “anonymous” web browsing to logged‑in app identities.
  • This bypasses browser controls like cookie clearing, Incognito/private mode, and Android’s normal permission model, and potentially lets any app listening on those ports eavesdrop.
  • Yandex used HTTPS to yandexmetrica.com on a high local port, implying the app ships a cert/key and can impersonate that origin locally.
  • After disclosure, Meta rapidly removed the STUN code; many see the instant rollback as tacit admission that this wasn’t an accident.

Browsers, localhost, LAN access, and WebRTC

  • Many are surprised browsers allow arbitrary web pages to talk to localhost/LAN at all; see it as a long‑known but under‑addressed attack surface.
  • There are legitimate localhost/LAN uses (desktop app detection, ID/eID card software, WebDAV shares, hardware diagnostics, status boards).
  • Existing mitigations: uBlock Origin’s “Block outsider intrusion into LAN” list, the Port Authority extension, and work on standards like Private Network Access and new permission‑based LAN access models.
  • WebRTC is defended as essential for browser‑based video/chat, but several argue it should be gated by clearer permissions, especially for localhost targets.

Legal and regulatory angles

  • Many argue this likely violates GDPR and the ePrivacy Directive (using first‑party cookies and consent mechanisms to secretly enable cross‑site tracking via native apps).
  • Suggestions include massive, escalating fines and even criminal liability; skepticism that large US tech execs will ever face serious consequences.
  • Separate thread debates third‑party cookie deprecation, Google’s Privacy Sandbox, and whether competition regulators unintentionally helped preserve tracking.

Advertising, tracking, and business models

  • Long debate on whether targeted tracking ads should be banned, versus just banning tracking and keeping “broadcast‑style” ads (like TV or billboards).
  • Some claim user‑level targeting demonstrably “works” and funds free services; others argue its effectiveness is overstated and that customers ultimately pay via higher prices.
  • Proposals include: strict limits on data use, stronger auditability for digital ads, and private or micropayment‑based models.

Mitigations and user behavior

  • Common advice: uninstall Meta apps, use only the web versions; disable background app refresh; minimize installed apps; favor F‑Droid / open‑source apps.
  • Technical defenses: uBlock Origin (especially LAN filters), Pi‑hole/NextDNS, RethinkDNS/firewall rules, disabling WebRTC (e.g., media.peerconnection.enabled), and using hardened ROMs like GrapheneOS.
  • Some note this undermines Android work/personal profile separation, since localhost listeners can bridge compartments if a site embeds Meta/Yandex code.

Ethics and developer responsibility

  • Many see this as “spyware” behavior; debate whether low‑level engineers just “did their job” or should refuse such work.
  • Broader reflection that ad‑tech has normalized invasive tracking, while the older “hacker for freedom/privacy” culture is now a minority amid mainstream computing.