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 <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 <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