For reference:
* definition of authenticated origin https://w3c.github.io/webappsec/specs/mixedcontent/#is-origin-authenticated
* a recent TAG discussion on the topic that ends with the following resolution:
"RESOLUTION: We support efforts by browser vendors to restrict privacy-sensitive features to secure origins. This includes ones that have not historically been restricted as such, like geolocation or webcam access." http://www.w3.org/2014/09/29-tagmem-minutes.html

EKR has agreed to write some text

WG decision: We will not disallow HTTP access, but there will be language in the text outlining why it might be a bad idea.

What's the rationale for the decision?

I want to get the TAG's thoughts in writing, as well as my interpretation of what was agreed to on yesterday's call.

In general, per our recent TAG resolution, we believe privacy-sensitive features should be restricted to secure origins. And getUserMedia (as well as mediaDevices.enumerateDevices, to a lesser extent) is definitely a privacy-sensitive feature, by any accounting.

When it comes to dealing with the real world, we recognize that especially for specs that have lots of code out there, like geolocation or getUserMedia, fixing this is going to be a process. So we're definitely not saying "the spec and all browsers should move getUserMedia to secure-origins-only right now."

Also of note, we're not saying that e.g. navigator.getUserMedia should require secure origins, but navigator.webkitGetUserMedia should not, or that MediaDevices.getUserMedia should require secure origins, but navigator.getUserMedia should not. A browser should make the move all at once; otherwise, attackers can just use the un-secured API.

As such, in our opinion the best way to make a forward-looking move is to explicitly outline that supporting GUM on HTTP is depracated, and to give a path toward its eventual removal. A good example of this being done already in the platform is with XHR: see https://xhr.spec.whatwg.org/#sync-warning.

Here's a draft of the kind of warning I would imagine:

"When on an insecure origin, user agents are strongly encouraged to warn about usage of MediaDevices.getUserMedia, navigator.getUserMedia, and any prefixed variants in their developer tools. User agents are encouraged to experiment with removing these APIs entirely when on an insecure origin, as long as they remove all of them at once (e.g., they should not leave just the prefixed version available on insecure origins). This will enable us to eventually remove insecure access to this feature from the platform."

We didn't talk about it much, but I think the TAG would generally suggest that enumerateDevices be restricted to secure origins out of the box. (Personally I think this kind of protection-from-fingerprinting privacy is somewhat of a lost cause, but in general the TAG, and I believe much of the web standards community, disagrees with me on that.)

I am a novice in WebRTC and maybe I am not fully aware of the reason behind using getUserMedia to access client's camera/microphone from server. If the server is adding some effects on top of client's camera/microphone data, it makes sense, but for a peer to peer communication (for what WebRTC is being developed), I don't see why server should be receiving video/audio data at all.
I was going through an IEEE paper regarding security concerns of WebRTC (http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6894480) and there they have proposed to add peerIdentity constraint to getUserMedia so that video/audio data from one client is made accessible to its peer only if a session is created which actually makes sense.
Also, being from a mobile industry, I am concerned about the power consumption as the camera and microphone won't be turned off even though the browser is hidden and no WebRTC calls are active. This can be a major performance issue for browsers in mobile devices. Maybe an equivalent browser calls to getUserMedia for disabling camera/microphone should help.
Providing client's presence information to server and camera/microphone data directly to peer device after negotiation should suffice IMO(Ofcourse I am limiting server's scope). This should reduce security concerns as well.
Please correct me if I am wrong.

Text integrated:

https://github.com/w3c/mediacapture-main/pull/104