RE: User media constraint: peerIdentity

Does the identity constraint have to get pushed down to the Track level?  Suppose someone creates a stream that is tied to foo@bar, and then tries to add the audio track from that stream to an unconstrained stream.  The addition would have to fail (or the stream become constrained), just as you indicated below for adding an unconstrained stream to a constrained PeerConnection.   So the constraints on the Stream, Track, and PeerConnection must all agree.

- Jim

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Thursday, October 25, 2012 12:43 PM
To: Harald Alvestrand
Cc: public-webrtc@w3.org
Subject: Re: User media constraint: peerIdentity

On 25 October 2012 01:24, Harald Alvestrand <harald@alvestrand.no> wrote:
> I think the input -> display path should always be possible, no matter 
> what the taints are - just like the <video> tag can display any 
> incoming stream on the screen, no matter how tainted (I believe).

Agree.  The catch is that drawing to the display with a tainted stream is fundamentally different to one without that lock.  For instance, an application can usually sample from a canvas.  This has to be blocked for the area where video is being displayed.  It might even be necessary to limit the set of possible style-transforms that can be applied to the display.  Treating the display output similarly to a cross-origin iframe seems most appropriate: only size and position can be controlled.

Audio is interesting.  Ideally, you don't want to be playing back audio that can be sampled from an untainted microphone.  On the other hand, I'm not sure if this is something worth solving.

> It may be simpler (and cleaner) to tie the two  to the same identity:
>
>   getUserMedia( mandatory: {availableToIdentity: foo@bar} ) => stream
>   pc = new RTCPeerConnection( mandatory: {connectedToIdentity: foo@bar } )
>   pc.addStream(stream)
>
> Either creation would fail if it wasn't possible to get a trustworthy 
> way to verify the identity, and the addStream step woudl fail if it 
> wasn't possible to verify that the two identities were the same.

That is what I had in mind.  Immediate feedback is good.  Throw an Error.

What about adding an unconstrained stream to an RTCPeerConnection that has a mandatory peerIdentity?  This would either require that the stream be untouched prior to adding and adding it applies the peerIdentity constraint; or reject the addition.  The latter is of course simpler, and is my current leaning.

--Martin

Received on Thursday, 25 October 2012 18:31:53 UTC