Webrtc-pc: Mandating [SecureContext]

[ylafon]

This is a followup of w3ctag/design-reviews#228 and w3c/webrtc-stats#347.

Here is a quote from the last issue above:

The TAG, during its last f2f felt that interoperability issues would arise if someone was implementing per specification and not requiring [SecureContext], so as you imply that all implementations already do that, more good than harm would be done by adding it in the specification.

Thanks.

[alvestrand]

We had that for getusermedia for a while - Chrome didn't require secure context while Firefox did (I think that was the way it went). It led to some pages (in particular demos) that worked in one but not the other.

I wouldn't be opposed to just encoding the state of the art and marking RTCPeerConnection as [[SecureContext]]. draft-ietf-rtcweb-security-10 gives rather strong arguments why loading from an HTTP origin or using mixed sources is foolish, but doesn't seem to contain a mandate for secure contexts (or I missed it); it would be nice to mandate not being foolish.

[youennf]

It might be good to separate the issues:

1. navigator.mediaDevices.getUserMedia is not restricted to secure contexts in most browsers. It will usually reject the promise due to being called in an insecure context. It seems legitimate to update the spec according the current behavior. Ideally, we would mark it (or even better mediaDevices) as SecureContext. The compatibility risk probably needs to be assessed.

2. Is there a scenario where navigator.mediaDevices.enumerateDevices would usefully resolve in contexts where getUserMedia will not be available?

3. navigator.getDisplayMedia is probably currently aligned with navigator.mediaDevices.getUserMedia in terms of behavior. It would be nice to update the spec accordingly. The compatibility risk to move it to SecureContext is probably lower.

4. RTCPeerConnection is not restricted in shipping browsers AFAIK. I do not see a clear motivation to make such change at this point. For instance, RTCPeerConnection has some functional similarities to WebSocket which is not restricted either.

[youennf]

https://github.com/w3c/mediacapture-main/issues/540 is filed for 1 and 2.
https://github.com/w3c/mediacapture-screen-share/issues/77 is filed for 3.

[fippo]

Is there a scenario where navigator.mediaDevices.enumerateDevices would usefully resolve in contexts where getUserMedia will not be available?

I don't think so. Throwing NotSupportedError seems reasonable and limits the fingerprinting surface, even though the information is already limited to number and kind of devices.

[jan-ivar]

Thanks @youennf for filing those issues.

@ylafon can we close this issue based on 4, since only RTCPeerConnection is covered by this spec?

[ylafon]

LGTM, I'm closing it.
Thanks!

[youennf]

@cynthia mentioned the possibility to make RTCPeerConnection SecureContext in https://github.com/w3c/mediacapture-main/issues/540#issuecomment-434281606.

[cynthia]

Thanks for forwarding the feedback points to here. Would be interested in hearing in particular if there were any strong objections, if not - I would like to have this issue re-opened for consideration.

[jan-ivar]

I'd say the main objections are those in point 4 above.

Considering that most fundamental building blocks of RTC require a secure context, I think this should be safe to do

There are data channel uses of RTCPeerConnection that do not fundamentally¹ rely on camera or microphone. That's where they're similar to WebSockets.

_{1. Notwithstanding that browsers blur this line today by overloading camera and microphone permissions as a trust-vector for ip leakage.}