W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2014

[Bug 26937] Proposal: Only allow authenticated origins to access getUserMedia

From: <bugzilla@jessica.w3.org>
Date: Tue, 11 Nov 2014 03:34:29 +0000
To: public-media-capture@w3.org
Message-ID: <bug-26937-5753-fDfpwlETA4@http.www.w3.org/Bugs/Public/>

Praveen R Jadhav <praveen.j@samsung.com> changed:

           What    |Removed                     |Added
                 CC|                            |praveen.j@samsung.com

--- Comment #6 from Praveen R Jadhav <praveen.j@samsung.com> ---
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.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 11 November 2014 03:34:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:31 UTC