- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 25 Oct 2012 09:43:30 -0700
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-webrtc@w3.org
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 16:43:59 UTC