Multicast subscription timing cross-site identifier

[JensenPaul]

If IP multicast is used, is there a way to partition this resource per site? Various browsers are working to or already partitioning resources (e.g. caches, socket pools) per site to prevent providing cross-site identifiers. This draws from https://www.w3.org/TR/fingerprinting-guidance/#no-new-cookies

I'm imagining one site subscribing to a random subset of 64 multicast streams, then another site attempts to subscribe to all 64 multicast streams and sees which subscriptions occur instantly (because computer already subscribes with its IP address).

[GrumpyOldTroll]

The proposed API has ways to protect against this as long as the service provider cooperates.

A recent update to the explainer fleshes this out slightly better, but the mechanism works by preventing browser users (at least those who have not disabled protections) from joining unauthorized flows by refusing to answer DORMS queries from wrong origins, which will prevent the join from succeeding. So a 3rd party malicious page wouldn't be able to join flows they have no involvement with. Also, the DORMS queries themselves won't be instantaneous from different sites, and would be required in order to start the listening socket even if something else on the machine has already joined it.

However, the mechanism you mention might be possible to do for streams that share a DORMS domain name, if you provide a service that provides traffic for many sites (or perhaps if there's a malicious ad that runs on pages that come from many sites, if it's reporting to some central tracker).

The referenced fingerprinting link says "Avoid unnecessary new local state mechanisms." and asks whether the functionality can be achieved with local storage or existing cookies. Obviously this functionality can't, so I don't think it falls afoul of the referenced best practice.

But with that said, looking at the timing of a join for identification is an interesting angle that might be worth checking more closely, if there's something that can flesh out the threat model a little better. That particular observable might be defeatable if necessary by adding a random delay if already joined or something, but I'm not really sure it's necessary.

This seems like you could do a similar timing-based fingerprinting effort by, for instance, timing the fetch of potentially-cached images across several sites, when you have some control across-site over what to fetch (like maybe if you're an ad engaged in malicious fingerprinting). Has that ever been seen in the wild, and if so was there a way to defeat it?

[JensenPaul]

In the case of cross-site tracking, threat models (e.g. https://w3cping.github.io/privacy-threat-model/#hl-recognition-same-site) include the service provider being complicit I think. In the 64 multicast streams example I mentioned, I was assuming the 64 streams were provided by the two sites (or a malicious third-party running on two sites) wishing to join a users' identity across the two sites.

WRT "Avoid unnecessary new local state mechanisms.", the local state I was referring to was whether or not the device had joined a particular stream. AFAIK a device might only have one IP address and one IP address can only join a mutlicast stream once, thus creating a local state mechanism visible across sites. Is there any way to partition this multicast joining by top level site, e.g. is there a way to allow a device to join a stream multiple times (so each site open in a browser joins independently of other sites open in the browser)? Barring joining independently, adding a random delay proportionate to other joins on that device may also work.

[GrumpyOldTroll]

Thanks for the link to the threat model. And also (belatedly) for the original to the fingerprint-guidance doc. After reading the full thing more carefully I agree it's important to apply the overall guidance there in our design document.

the local state I was referring to was whether or not the device had joined a particular stream

I agree the join status is local state and that it's partially observable via the timing between the join and the receiving of data.

It's not a great signal, since it'll also probably come in under the "already joined" threshold for flows joined by other devices in the same LAN and in some cases probably those joined on the same CMTS/OLT/etc, but I agree it's a signal that could be probabilistically leveraged to some extent.

And in that sense, the mitigation you suggested (somehow issuing a separate join, as if you had another separate IP address you could use on your LAN) wouldn't help even if it was feasible, because the next-hop router would already have the multicast tree built and this is where the vast majority of the timing difference between joined and not-joined would come from, so the signal would still be almost just as strongly present.

So as a rough outline of my initial view of this issue and an early-stage draft of info that should end up in the design doc, I'd say this feature does provide a fingerprinting surface with these characteristics:

• fingerprinting attacks would be active

• The severity factors are:

  • entropy: tunable to an extent by attacker, but has some limitations (see below)

  • detectability: highly detectable. This behavior will be immediately obvious to researchers.

  • persistence: not persistent

  • availability: context-dependent (see below for proposed mitigation addressing this)

  • scope: consistent across origins

Recommended mitigations:

• For browsers offering a very high privacy environment such as a TOR browser, the multicast API should be disabled. In addition to the fingerprinting surface, the multicast API would leak information about the joined (S,G)s to the next-hope router for the local LAN, and to some extent to the upstream ISP.

• For a context like "private browsing mode", the surface is comparable to what's achievable via sender-side IP correlation, so it's recommended to poll the user before allowing joins for a site(?)

• Recommended to allow per-site whitelist and blacklist user management for the multicast API(?)

Does that basic outline work and seem reasonable? Any suggestions?

I guess I'm not quite sure how achievable the fingerprinting is, either, which ties into the limitations mentioned in the entropy part. It's typical that there's rate limiting on the join rate by the network, so most of the time trying to join ~32 flows at once will leave some of them failing, but they could still be joined serially. But also, there will be bandwidth limits, and the available timing observation resolution will depend strongly on the packet rate, but higher packet-rate flows will likely run into bandwidth limitations, whereas lower packet-rate flows will give a poor signal from timing resolution. So although there is some fingerprinting surface, it's inherently going to have some network-dependent limitations, and will struggle to be a really useful signal across a wide range of users.

That said, some tunable countermeasures that can be user-configured and have different profiles for different privacy-hiding contexts seems like a good idea, and thanks for raising the issue.

Please comment further as you have any, and I'll try to make sure the issue is addressed in the design doc.