Re: Dealing with isolation state mismatches

On 05/15/2014 07:21 AM, Martin Thomson wrote:
> This is probably best handled in a room, but here goes.
>
> A has isolated streams because it thinks it's making a "private" call.
>   (Scare quotes intentional.)
>
> B has regular streams.
>
> A and B try to establish a call.  Nothing in the signaling they are
> using (SDP, woo!) indicates that they are screwed.  The browser runs
> the O/A exchange and it seems OK, until the DTLS session blows up.
>
> Do we want a signal in SDP for this state?  I think that it would be
> nice.  We can put a wee attributey thing on the a=identity line.
>
> Sorry, scratch that, we can request that the RTCWEB working group
> consider this as a new requirement on their signaling work.
>

I'm not sure I quite get the "isolated" property's properties here.

When it was initially proposed, I thought it was intended for:

A runs a Javascript app X
A wants his media to end up only with B, not anyone else X wants to send 
it to
X marks the streams as "isolated", A checks that this is true (oops, UI 
needed), and is happy
X sends the streams to B.
B does what B does - records them, mixes them, relays them - whatever. 
This is OK, because A trusts B with his streams.

If we have the "isolation" property be signalled, and honored across the 
network, it means that there's a trust relationship (or rather, lack of 
trust) between A and the Javascript running in B's browser - let's call 
that Y.

So the requirement becomes that A wants assurance from Y that it's not 
peeking at the streams. This also prevents Y from offering functions to 
B for enhancing, processing, recording or relaying the streams in ways 
incompatible with isolation - there's a cost to everything.

I can't manage to make the logical leap that this is the right thing for 
all cases.

The necessary trust relationship to Y is between B and Y.
A negotiation of isolation can only say "Y promises that these streams 
are isolated, and B can verify that using his browser's UI".

So I get at least 3 cases falling out of this:

- A doesn't care. No isolation needed.

- A doesn't trust X, but trusts B and trusts that B takes care with his 
streams.
   X has to show evidence of isolation. A doesn't care what Y does; he 
trusts B to verify that,
   if needed.

- A doesn't trust X, has reasons to distrust Y, but trusts B to verify 
that Y does the right thing.
   X has to show evidence of isolation. Y has to show evidence to X that 
B should be able to
   verify that the streams are isolated.

Negotiation is only needed for the third case.

If isolation is of value in the second case, it seems that there should 
be a configuration option in the PC that says "Isolate incoming 
streams". In general, all means of producing streams should probably 
offer the option to indicate "these should be isolated" - strictly as a 
local matter.

Is the third case important enough that we really need this in the protocol?

Received on Thursday, 15 May 2014 09:00:54 UTC