- From: Li Li <Li.NJ.Li@huawei.com>
- Date: Wed, 24 Oct 2012 16:20:49 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Martin, How about sending the tagged stream to a <video> element for self-view? Is it permitted? If so, I'm not sure if the <video> object will keep the tag. If it doesn't, the stream can run free. Even if it keeps the tag, as you said, requiring all other stream processing API outside WebRTC to deal with this constraint (and errors from it) is difficult. Is it true that such constrained streams can only follow this path: camera/mic -> peer connection -> network If so, we can force this path in WebRTC API easily without leaking our constraint/errors to other API. 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. 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. Thanks. Li -----Original Message----- From: Martin Thomson [mailto:martin.thomson@gmail.com] Sent: Tuesday, October 23, 2012 5:50 PM To: Li Li Cc: public-webrtc@w3.org Subject: Re: User media constraint: peerIdentity On 23 October 2012 14:40, Li Li <Li.NJ.Li@huawei.com> wrote: > This is an interesting idea. But I wonder how browsers can prevent a page from using any post-processing API [1] to access the constrained media stream. It's fairly straightforward. Tag the media stream, and refuse to permit any operation on that media stream *except* sending to an authenticated RTCPeerConnection. > Do we require those APIs to be aware of peerIdentity and refuse any such constrained media streams? Yes. To the extent that failure is a possibility and reporting that failure is probably necessary. This would introduce a new failure mode to each of those APIs. Most of the awareness would be attached to the stream itself. Of course, the extent to which this is possible depends on the details of the browser implementation. I imagine that this could be made very difficult to achieve.
Received on Wednesday, 24 October 2012 16:23:06 UTC