Re: User media constraint: peerIdentity

On 24 October 2012 09:20, Li Li <Li.NJ.Li@huawei.com> wrote:
> How about sending the tagged stream to a <video> element for self-view? Is it permitted?

That should be OK.  As long as the <video> tag is tainted
appropriately so that the app can't sample from that display area.
The same applies to playback from authenticated peers anyhow.

> Is it true that such constrained streams can only follow this path:
>
> camera/mic -> peer connection -> network

Probably the following, recognizing that network (using
RTCPeerConnection) requires a specific tie to identity:

input -> display
  or
input -> network -> display

> We can construct a peer connection object with peerIdentity:identity constraint, and use a new constraint "targetConnection: pc" in getUserMedia() to tie the stream to the peer connection object.

That's a reasonable idea.  Specify to whom the connection should be
established prior to connecting.  The second constraint could ensure
that failures are faster and more obvious, though the opacity of
RTCPeerConnection remains a problem in this regard - it may not
provide any substantial benefit in this regard.

> With these constraints, the getUserMedia() success callback and pc.localStream will return null to prevent the page from accessing the stream other than sending it to a remote peer.

Tighter integration between gUM and RTCPC makes implementation of this
far more complex.  I'd rather use the tagging to ensure that the path
is kept clean.  That means that every other aspect is largely the
same.  pc.localStream[s] can just return the same tainted stream, just
as the streams from the peer in pc.remoteStreams are tainted.  This
keeps the usage model consistent.

--Martin

Received on Wednesday, 24 October 2012 23:20:32 UTC