W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2012

Re: IdP issues (was: Needs to be more clearly described)

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 18 Sep 2012 18:31:18 -0700
Message-ID: <50592066.2020605@alvestrand.no>
To: public-webrtc@w3.org
On 09/18/2012 11:15 AM, Martin Thomson wrote:
> On 18 September 2012 10:03, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
>> Martin,
>>    I'm trying to understand how the restrictions you mention below are enforced (e.g. "The media can only be added to an RtcPeerConnection where the remote end presents a domain certificate for "example.net".)  getUserMedia doesn't know anything about the PeerConnection object, and in general doesn't know how the MediaStream it returns will be used.  Could the information be added to the MediaStream object?  In your example a, the MediaSteam would be marked for unrestricted local use.  In b, it would be marked 'send to example.net' only, and in c 'send to authenticated user@example.net' only.
>>
>> We would need a language to express these restrictions inside MediaStream, and some way for the MediaStream's consumers (which could include any number of objects other than PeerConnection) to signal that they respect the restrictions.
>>
>> I'm not saying that this can't be done, just that it hasn't been...
> You are right, this hasn't been done.  A concrete proposal is probably needed.
>
> In my view it is not necessary to have any specific exposure for these
> usage restriction, MediaStreams could use private attributes to track
> this.  Though I would hope that some visibility is provided, lest
> there be inexplicable errors for users.  Perhaps "readonly DOMString
> peerRestriction" (which would be unset by default, though
> 'example.net' for b, 'user@example.net' in c) would help.
>
One reason it hasn't been done is probably that its use case was felt to 
be not compelling.

A page that is going to send your video stream off on a PeerConnection 
is probably almost always also going to want to connect the same video 
stream to a local <video> element, from which there are several APIs for 
extracting content. So unless we apply a lot of tainting mechanisms to 
the video, the JS is going to have access to the content of the video 
anyway, so more access control wouldn't buy you any additional security.

Security mechanisms are fairly expensive things, both in terms of 
policing the restrictions and in terms of making browser UIs that are 
capable of explaining what the user has agreed to. "I gave this web page 
access to my camera, I trust the Web page to do something sensible with 
it" is possible to explain.

I'd like to have the complete, compelling use case in hand that 
justifies the additional overhead before trying to design the functionality.

                    Harald
Received on Wednesday, 19 September 2012 01:31:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 19 September 2012 01:31:50 GMT