Meta: When a Tracking Cookie Took a WebRTC Route

The Meta case in Bridges to Self asks whether a tracking value can cross from a web page into a native app even when the browser does not expose the app’s private storage. The paper’s answer is yes: Meta Pixel used a local WebRTC path to move the _fbp cookie toward Facebook and Instagram app processing, after which Meta’s back end could use the relationship. Following this flow shows why a protocol change can alter what a browser sees without changing the identity bridge itself.

How the cookie crossed contexts

The starting value was _fbp, a cookie used by Meta Pixel on the web. A cookie is normally associated with the website context that set it. The browser can send it to the site or script that is allowed to use it, but the cookie is not supposed to become a general-purpose key that native applications on the phone can read. Meta’s observed localhost flow created a new route for that value.

The native side began with app behavior rather than a page load. When Facebook or Instagram was moved into the background, a service in the app started listeners for the local traffic used by the implementation. The paper reports listeners on UDP ports 12580–12585 for STUN messages and on TCP ports 12387–12388 for other stages. The background timing mattered: the services started a few tens of seconds after the apps moved out of the foreground, while the browser could remain in the foreground as the person visited a site. A test that watched only an active app screen could therefore miss the receiving process.

When a page carrying Meta Pixel loaded, the script sent the _fbp value and related event information to Meta’s web endpoint. The paper says that this information could include the page URL, pixel identifier, page details, and events such as PageView, AddToCart, Search, and Checkout. The browser-side event data was not yet a native identity match. It was the input that Meta’s script prepared for the local handoff.

The unusual step used WebRTC. WebRTC is a set of browser interfaces for establishing real-time connections, such as audio, video, or data channels. To make such a connection, the browser gathers possible network paths and exchanges connection information with another peer. One protocol involved in that process is STUN, which lets a participant send a binding request to learn or test an endpoint. In the Meta flow, the browser’s WebRTC machinery was used to produce a message that a native local listener could inspect.

Meta’s implementation modified the browser-generated session description before the connection was established. This practice is known as SDP munging: changing the text-like description of a WebRTC offer or answer rather than passing it through unchanged. The paper reports that the script inserted the _fbp value into the ice-ufrag field of a WebRTC offer. An ICE username fragment normally helps identify a connectivity negotiation. Here, the field became a carrier for the web-side cookie.

The browser then generated a STUN Binding Request toward the loopback address.