What happened to the webrtc feature?

[danjenkins]

I can see that the original webrtc feature got pulled into two separate things (getUserMedia and webrtc) but now webrtc doesn't exist? Can someone explain why? Came across some third party code on a website the other day (they're investigating but I expect its from a dependency of a dependency) that was using the RTCPeerConnection API (among loads of others) to fingerprint users - the original website owner say they don't have a need to fingerprint users so I can only assume they didn't mean for this to happen and I immediately thought of feature policies being able to stop use of the WebRTC APIs - I see midi and usb are included; why wouldn't we stop the use WebRTC apis too?

[Malvoz]

CSP? w3c/webappsec-csp#287

[clelland]

I don't actually know enough about WebRTC to know whether this makes sense or if restricting RTCPeerConnection is sufficient, but if so, we should add that back as a feature. @henbos -- can you comment on the feasibility of a policy here?

[henbos]

I think @alvestrand knows the context better.

[lgrahl]

As discussed in the PR, we should at least consider an on/off switch and I'd prefer having this sooner than later. We can still improve on it later.

[Malvoz]

It seems from rather quickly reading the CSP PR comments that the issue lies in not being able to scope src to adress literals? I'm in no position to say if CSP can adopt parametric features, but that shouldn't be an issue for Feature Policy?

[clelland]

CSP seems best suited for declaring what resources a page is allowed to connect to; while a boolean switch would be a good fit for feature policy, especially if the intent is to also extend restrictions into child frames.

My only question is whether blocking use of RTCPeerConnection is enough, or if there are other interfaces that also need to be included.

And actually, that doesn't need to be worked out here; a PR to https://github.com/w3c/webrtc-pc can define the feature, and call into https://html.spec.whatwg.org/#allowed-to-use as necessary. If that's adopted, we can update https://github.com/w3c/webappsec-feature-policy/blob/master/features.md with a link to the relevant text.

[lgrahl]

Basically, the problem is that connectivity checks sent by WebRTC contain a small amount of custom data and can contain arbitrary IP addresses to establish a direct connection (see w3c/webappsec-csp#287 (comment)). I currently do not see a way to constrain that.

See this demo for an example to leak unsecured data to an IP of your choice.

And actually, that doesn't need to be worked out here; a PR to https://github.com/w3c/webrtc-pc can define the feature, and call into https://html.spec.whatwg.org/#allowed-to-use as necessary. If that's adopted, we can update https://github.com/w3c/webappsec-feature-policy/blob/master/features.md with a link to the relevant text.

Thanks for that info. @alvestrand, should we pick this up in webrtc-pc then?