Re: Dealing with isolation state mismatches

On 05/15/2014 11:52 AM, Stefan Håkansson LK wrote:
> On 2014-05-15 11:01, 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
> This is the key point to me. The only UI we have is the gUM one.

That's an UI designer's decision. Consider the attached screenshot - the 
page dropdown menu in Chrome contains a "media allowed" info entry where 
you can remove access. That's another piece of UI.

>   That is
> the opportunity when the UA can tell the user ("A") that "media can't be
> recorded, and only be sent to B".
>
> So the logic for me becomes that B's app cannot record, or forward the
> media (of course this can only work if B is using a conforming UA) - so
> we would need to carry those properties over in some way.
>
> This is a "I trust the UA, I trust myself, I trust B, but I distrust the
> app (my app and B's app)" case.

That's my second case.

>
>