- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 25 Oct 2012 10:24:55 +0200
- 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 } )
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.
>
>> 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