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

Re: User media constraint: peerIdentity

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 25 Oct 2012 10:24:55 +0200
Message-ID: <5088F757.3050809@alvestrand.no>
To: public-webrtc@w3.org
On 10/25/2012 01:20 AM, Martin Thomson wrote:
> 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

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).

However, if you like telecommuting in black & white, and go input -> JS 
decolorizer -> display, this would not work with tainted streams.
>> 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.
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 } )

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.
>> 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 Thursday, 25 October 2012 08:25:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:34 UTC