Re: Follow up issues from WebRTC / PING TPAC meeting

(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