W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

Re: Dealing with isolation state mismatches

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 15 May 2014 11:31:48 +0000
To: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CFE4F75@ESESSMB209.ericsson.se>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:40 UTC