Why Blocking One Channel Does Not Close the Boundary

The browser response to the Meta and Yandex findings in Bridges to Self illustrates a difficult design choice: how do you stop silent web-to-app identity linking without breaking every useful service that runs on a device? This chapter compares the defenses by the surface they actually govern—domain, port, destination, protocol, or user permission—and then tests that comparison against the paper’s IPv6 and mDNS findings. The reader should leave able to distinguish a useful interruption of one implementation from a boundary that protects the underlying relationship.

What each mitigation actually controls

A blocklist is the most direct response to a named campaign. Brave and DuckDuckGo maintain lists of tracker domains, and the paper reports that Brave blocked the domains used by Meta and Yandex while DuckDuckGo updated its list after disclosure. This can be effective when the browser recognizes the script or its back-end destination before the exchange begins. It is also easy to explain operationally: a known source is denied.

But a blocklist governs names, not the local communication interface. The paper notes that DuckDuckGo missed three infrequently used alternate Yandex domains, and that blocklisting does not restrict the underlying channel. If a related script uses a domain that is not on the list, or if another actor uses the same kind of local endpoint, the local path remains available. A blocklist can stop a known participant without changing the browser’s general rule about what public pages may contact.

Directly blocking localhost requests addresses a different surface. Brave blocked HTTP(S) requests to 127.0.0.1 and localhost, which prevented the HTTP method used by Yandex Metrica and an early Meta implementation. Yet the paper reports that Brave did not block a domain such as yandexmetrica.com when that domain resolved to loopback, and did not block localhost WebRTC. The destination was local in both cases, but the browser’s rule recognized only some forms of that locality.

This is why a literal address check is narrower than a destination policy. A page can name a local address directly, use a hostname that resolves to a local address, or use a browser API that discovers a route through a different protocol. If a control examines only the visible spelling of the URL, the control can be bypassed by changing the name while retaining the local endpoint. If it examines only HTTP, a WebSocket or WebRTC path may fall outside its scope.

Restricted ports are another targeted measure. The paper reports that Chrome added the ports used by Meta and Yandex to its restricted-port list through a public trial and that the researchers confirmed blocked connections in console and error output. This is a meaningful short-term mitigation: the known listeners cannot receive the known traffic through those ports in the tested conditions. It also has a clear limitation. The Yandex implementation obtained ports from server-side configuration, and Meta changed protocols and port ranges during its campaign. Port blocking can interrupt an observed deployment while leaving an actor free to use a different port or transport.

Firefox demonstrates a mode-specific defense. Enhanced Tracking Protection blocked Meta Pixel in Strict mode in the authors’ tests. The STUN-based method failed in Firefox even when the script loaded, but the paper notes that the later TURN-based method might have succeeded before the campaign ended.