Re: Changing track sources...

I haven't thought this through fully either.  The answer could depend
on what sort of sink.

An RTCPeerConnection that is constrained to a single identity would
not accept this sort of switching.  That's actually the easy one.  All
unauthenticated to authenticated match-ups could be fixed to fail.

The problem arises when you have some sort of attribute attached to a
video element and that attribute was "known" to a user (through some
UI), but that property could change over time as different sources
were switched in.  It could enable some interesting bait-and-switch
techniques.  For instance, I know that this video comes from Matthew
and that it has been authenticated.  I verify this (somehow) and start
trusting it.  At some later point, the site switches in video of
Matthew doing something offensive (which would be a fake, of course).
You continue to "trust" that this video is authentic without noticing
that the status had changed.  These switches could be transitory so
that a user would be unlikely to detect the switch.

On 10 December 2012 12:40, Timothy B. Terriberry
<tterriberry@mozilla.com> wrote:
> A) Switching from a stream with a verified identity to one without.

This is the scary scenario.  I can't see how we can avoid this being possible.

> B) Switching from a stream with a verified identity to one with a different
> verified identity.

I don't see this as significantly different to (A).  This has the
potential to be even more confusing to users if the browser provides
some sort of boolean indication for authenticated streams.

> C) Switching from a stream without a verified identity to one with one.

That is the one case that I don't actually think anything special is required.

Received on Monday, 10 December 2012 22:32:12 UTC