Re: Follow up issues from WebRTC / PING TPAC meeting

This thread has gotten unmanageably large (my fault) so I’m going to try and agro consolidate.  If more context is needed folks can scroll back if needed, just to keep the thing sane.  If I’ve mis-stated / summarized anything, please chalk it up to honest mistake.


Network info data
---

>> Terrific.  Was just checking whether that had changed since TPAC.  Is there an issue I can subscribe to, to keep up on the progress.
> 
> Yes, https://github.com/w3c/webrtc-stats/issues/374

Great!  I will follow up there.


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?
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’ve made both of these points several times now, both at TPAC and on these threads.  I am happy to link back to them if its helpful.
> 
> Thanks, but I was rather hoping you'd engage directly with the email comment I quoted from your co-PING-member which contradicts your position. There seems to be disagreement within the PING working group here. I don't know who speaks for the PING working group as a whole.

and 

> I think the disagreement (even within PING) is over whether there is >0 net privacy gain today of mandating further effort when users are trivially correlated by localStorage without partitioning.

PING is a lot of people; most reviews happen in parallel.  There is no way we could try to scale to reviewing the entire platform if every review was done with all 40+ people on each review.  So in general we just follow principals like (i) if there is a more private way to achieve the functionality w/o loss of functionality, always prefer that” (seems the case with int ids), and (ii) don’t leak hardware info w/o user consent, among others.


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.

> 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 Thursday, 31 October 2019 20:52:09 UTC