Re: Dealing with isolation state mismatches

On 2014-05-15 13:13, Harald Alvestrand wrote:
> 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.

Correct. But the gUM one is the only one required by this draft.

> 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's a rather complicated UI - difficult for the average user to 
understand. OTOH, for the very specific case (your second case), it 
might be OK.

Do you see a risk in UI's diverging too much - that the user experience 
for a service (and perceived and actual privacy/security control) may 
differ too much depending on the UA used?

Received on Thursday, 15 May 2014 11:32:13 UTC