Re: [EXTERNAL] Follow up issues from WebRTC / PING TPAC meeting

Howdy Jan-Ivar, Youenn and Bernard (and everyone else :)

Sounds good, here is where PING will track the issues (using the issues given previously in this thread)

 - remove network status endpoint https://github.com/w3c/webrtc-stats/issues/374
 - device id keying (https://github.com/w3c/mediacapture-main/issues/598)
 - device labels (https://github.com/w3c/mediacapture-main/issues/640, newly created)


> What's also not a solution is “sites can only learn about devices the user has granted access too”, because it doesn't address the elephant in the room: one browser bulk-grants device permissions. That's a web compat headache for more privacy-respecting browsers. Basically, only Chrome would be able to implement a meaningful picker then.
> 
> Chrome today grants all cameras and all labels.
> Firefox today grants one camera and all labels by default.
> Which is more problematic? Which one do you want to make non-compliant?

Chrome is more problematic than Firefox given the described behavior.  But those aren’t the only two options.

The flow should be
0) site has access to no devices or device labels
1) site asks for category (or categories) of device
2) browser prompts user for one, many or all devices
3) site gains access to only the device, and device label, of the hardware the user selects.

I’ll also mention the above in the issue (again at https://github.com/w3c/mediacapture-main/issues/640)

Pete


> On Nov 4, 2019, at 7:52 AM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
> 
> Youenn said
> 
> "
> It would be nice to file all issues on GitHub and provide a list of these issues here for those following the discussion.
> Pete, have you already filed all issues (like the super-secret camera issue)? Would you be able to post here the list of issues?
> "
> 
> [BA] Yes, that would be nice - if only so that we can keep track where we are and what remains to be resolved.  
> From: youenn@apple.com <youenn@apple.com> on behalf of Youenn Fablet <youenn@apple.com>
> Sent: Sunday, November 3, 2019 11:27 PM
> To: Jan-Ivar Bruaroey <jib@mozilla.com>
> Cc: Pete Snyder <psnyder@brave.com>; youenn fablet <yfablet@apple.com>; Mike O'Neill <michael.oneill@baycloud.com>; public-privacy <public-privacy@w3.org>; public-webrtc@w3.org <public-webrtc@w3.org>
> Subject: [EXTERNAL] Re: Follow up issues from WebRTC / PING TPAC meeting
>  
> It would be nice to file all issues on GitHub and provide a list of these issues here for those following the discussion.
> Pete, have you already filed all issues (like the super-secret camera issue)? Would you be able to post here the list of issues?
> 
> Thanks,
> Y 
> 
>> On 2 Nov 2019, at 00:25, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> 
>> (Selectively quoting)
>> On 10/31/19 4:52 PM, Pete Snyder wrote:
>>> Device IDs
>>> ---
>>> 
>>> 
>>>> [double keying, pes edit] is the only thing that seems effective and realistic to me to mitigate correlation across top-level sites. deviceId seems like a red herring here.
>>>> 
>>>> If the remaining effort is to "reduce technical privacy debt" then we seem to agree there's no empirical privacy harm.
>>>> 
>>> (Trying to summarize aggressively)
>>> 
>>> 1) is there an issue we can move this discussion to?
>>> 
>> 
>> I believe Youenn is planning a PR on https://github.com/w3c/mediacapture-main/issues/607 to cover the baseline agreement from TPAC. We also have https://github.com/w3c/mediacapture-main/issues/598 which perhaps we can take over and use to discuss going further?
>>  • 607 <- Broad consensus that deviceIds must be double-keyed and not single-keyed when a page’s storage options are all double-keyed.
>>  • 598 <- Some interest in double-keying deviceIds regardless (though concerns with this have been raised since TPAC).
>> Or feel free to open a new one instead of 598 if you prefer.
>> 
>>> 2) Locking in current privacy harming functionality is an empirical harm, in that it makes it harder to improve things going forward
>>> 3) (related) the approach is privacy in depth: removing as much privacy-risky functionality as possible gives standards and vendors more space to experiment with other improvements in the future
>>> 
>> 
>> I disagree we're locking ourselves in by not locking down ids now, but let's discuss in the issue.
>> 
>>> Revealing unexpected device labels
>>> ---
>>> 
>>> 
>>>> Note all browsers (except Firefox desktop) prompt users without saying which camera or microphone they're being asked to share. Best to unplug it first.
>>>> 
>>> That Firefox desktop does better than everyone else is fantastic and to be celebrated.  And if what FF is doing is the only way to respect user wishes about what hardware users want to give the sites access to, then something like that should be in the spec.  Lets do it :)
>>> 
>>> But the idea that users need to plug and unplug devices because they visit certain websites is totally not appropriate for a privacy-respecting platform. It breaks any user intuition about isolation, etc etc etc.  I don’t know if you’re being serious or joking above the above, but if the former, I really encourage you to be more considerate towards your users.
>>> 
>>> E.g. “unplug your devices” is a workaround for inconsiderate, privacy violating software; Its a fail state, not a solution.
>>> 
>> 
>> What's also not a solution is “sites can only learn about devices the user has granted access too”, because it doesn't address the elephant in the room: one browser bulk-grants device permissions. That's a web compat headache for more privacy-respecting browsers. Basically, only Chrome would be able to implement a meaningful picker then.
>> Chrome today grants all cameras and all labels.
>> Firefox today grants one camera and all labels by default.
>> Which is more problematic? Which one do you want to make non-compliant?
>> .: Jan-Ivar :.
>> 
>> 
>>>> It seems plain that this is a privacy violation, and that the spec saying “sites can only learn about devices the user has granted access too” is a solution (maybe one among many, but at least one). 
>>>> 
>>> “Embarrassing labels" is just a motivating example.  The principal is that users need to be in control of what hardware sites can learn about and see.  Giving a site access to a webcam should not allow / enable identification beyond what’s learned from that webcam, etc
>>> 
>>> 
>>>> … if you want to mandate a UX flow where user-selection comes before permission—and I don't see how users can have an expectation here otherwise—then all browsers (except Firefox desktop) will have a lot of work to do.
>>>> 
>>> My goal is to get the platform to have strong, and user understandable, privacy properties.  That sites don’t get to escape the browser sandbox other than when, and in the ways, the user wants, is one of those.  Im agnostic about the way of getting there, but thats where a privacy—by-default platform needs to be. And I’m happy to help do the work to get there ;)
>>> 
>>> 
>>> Pete
>>>

Received on Monday, 4 November 2019 20:48:27 UTC