identify misbehaving origins by webrtc data channel misuse

[dkg]

@wseltzer and i were in the rtcweb discussion at IETF today, and there are several ways that webrtc can be used to gain additional private information about users, or to link concurrent private sessions.

for example, opening a webrtc data channel, collecting the ICE connection candidate IP addresses, and then closing the data channel.

It would be great if privacy badger were to detect this kind of misbehavior from an origin, and use it to identify the origin as something worth blocking.

(i did a skim of the codebase and the Changelog and didn't see anything like this, but maybe PB is already doing this. if so, feel free to close this report, thanks!)

[dkg]

another attack is to link private browsing tabs with non-private browsing tabs. this is done by an origin responsible for two different webpages. it makes each page try to establish a webrtc channel with each other; measuring the latency between the two pages can provide an indication of whether they are on the same host.

[ghostwords]

Could you expand on that second attack? I don't understand how it works exactly or where Privacy Badger would come in.

[wseltzer]

The final slide of https://datatracker.ietf.org/meeting/102/materials/slides-102-rtcweb-ip-handling-00 re context linkage

[dkg]

sorry about that -- it was pretty confusedly written, and i'm pretty fried :) I've just given it an edit to try to make it a bit clearer. hopefully wendy's pointer is helpful too. but feel free to ask more questions.

[dkg]

so what i could imagine for detection of the second attack would be PrivacyBadger keeping track of tabs that are making webrtc connections to other tabs.

[ghostwords]

Aha, gotcha, thank you.

I think enabling the optional "Prevent WebRTC from leaking local IP address" setting would block both attacks (and make detection impossible). (When enabled, the WebRTC IP handling policy is set to Mode 4 (disable_non_proxied_udp) of https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01#page-5.)

Since we keep this setting off by default, we could certainly try to add detection for suspicious WebRTC use patterns in the future.