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

Re: Dealing with isolation state mismatches

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 15 May 2014 13:40:51 +0200
Message-ID: <5374A7C3.8050408@alvestrand.no>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 05/15/2014 01:31 PM, Stefan Håkansson LK wrote:
> 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?
>
>
I see a real danger of that. OTOH, I also see some pressure towards 
convergence.

People want to copy what works well.
Received on Thursday, 15 May 2014 11:41:19 UTC

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