Re: Dealing with isolation state mismatches

  I think that Donald Sterling just found out that it would be awfully 
nice to be sure that your interlocutor isn't recording the 
conversation....(Ignore this remark if you don't  follow US sports.)

On the other hand, I'm not sure how strong a guarantee we can give. Even 
if we allow isolation to be negotiated, A would have to trust B to have 
a conformant UA that enforces isolation.  He can't be sure that B 
doesn't have a rogue UA that negotiates like a WebRTC endpoint, but 
allows B to do whatever he wants with the media.


On 5/15/2014 5:00 AM, Harald Alvestrand wrote:
> 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?
>
>
>
>
>

-- 
Jim Barnett
Genesys

Received on Thursday, 15 May 2014 14:53:21 UTC