Re: Follow up issues from WebRTC / PING TPAC meeting

On 10/24/19 7:02 PM, Pete Snyder wrote:
> Thank you for the summary.  Could you also describe the status of discussions about revealing the local network environment?  At TPAC it seemed like there was unanimous support for removing the “VPN” response, and near (though not complete) support or removing the end point all together.  The later is the PING suggested approach.

This matches my understanding, as well as the WebRTC TPAC summary in 
https://lists.w3.org/Archives/Public/public-webrtc/2019Oct/0046.html:

"Broad interest in removing or gating networkType. Remove “vpn” value."


>> There is consensus to double key device IDs if other storage like IDB are double keyed.
>> There is interest within the WG in having browsers to support full double key storage.
>> There is little interest within the WG in mandating browsers to double key device IDs if other storage like IDB is not double keyed.
>> This is in terms of implementation.
>>
>> In terms of specification, my personal opinion is that it is fine to describe where browsers want to go, not where browsers are right now.
>> I am thus fine mandating double keying once we have proper support in the HTML spec for getting the storage partition key.
>> The HTML spec bits are being worked on.
> The WG has described in several places how the spec can protect users of browsers with double key’ed storage.  Thats not the point of disagreement / uncertainty though.  My questions are all “how will the spec protect people using browsers w/o double key’ed storage” (i.e. the majority of web users)?  Unless the spec is not going to be implemented until everyone double keys storage (clearly not the case) then the spec needs to protect these users too.


Protect them from what exactly? This was challenged earlier in the 
thread, but looks unanswered. From 
https://lists.w3.org/Archives/Public/public-webrtc/2019Oct/0030.html:

"On 9/26/19 5:14 PM, Jeffrey Yasskin wrote (lifted excerpts):
 > Pete and I have already established that we disagree on this, but to
 > restate the other position:
 > 1. The theoretical privacy harm from an unpartitioned media device ID
 > is that it can cause the user to be correlated across top-level origins.
 > 2. In browsers that do not ship partitioned storage, the user is
 > already trivially correlated across top-level origins using that storage.
 > 3. Thus, the media device ID cannot *cause* the user to be correlated.
 > 4. So it causes no privacy harm that needs to be solved. That'll only
 > change when storage gets partitioned."


>> There is no consensus there, partly due to the fact that details are fuzzy (what means recycling in particular), also since double keying solves the same issue.
> 1. The device ids -> ints suggestion is a way to protect users of browsers that don’t double key
> 2. I’m happy to explain any ambiguity, but in short, if I plug in the same web cam twice, it gets the same int handle twice.  If a new device is added, it gets the next int.  These mapping of device ids -> ints are stored per domain.  Again, happy to explain further.


I spoke to this earlier as well, but didn't get a response. From 
https://lists.w3.org/Archives/Public/public-webrtc/2019Oct/0030.html:


"Nothing would break semantically, but I think Youenn is right any
counter becomes an id over time as devices are added/removed. Plus, if
the "per-origin" part is poorly implemented, the counter might correlate
across origins (users change tabs often, devices rarely). Users with
many devices would stand out. That sounds worse than what we have (in
the spec) now."


>> The spec does not mandate to expose all devices after giving access to a single device.
>> The spec does not mandate to expose only the exposed devices.
>> My understanding is that the current state there is ok with the WG and that changing implementations is difficult in terms of web compatibility.
> I completely understand that the spec is ambiguous here, regarding privacy protections.  Thats the point of this, to make the spec strong and unambiguous re privacy :)
>
> Re webcompat: if its difficult to change now, its only going to get more difficult going forward.  But there is no way we can lock in privacy harming behavior because its specified in a _draft_.  Thats incompatible with the standards process, and harmful to web privacy (as the WG noted during TPAC, most accesses to this information appears to be for fingerprinting purposes).  What is the possible user-serving benefit for “I give a site access to device A, so the browser now also tells the site information about device B”?

The user-serving benefit is in-content selection of which camera and/or 
microphone to use.


> Put differently, spec ambiguity (ie the spec does not mandate…) isn’t a solution to the spec’s privacy problems; its a contributing cause.
>
>
> So, all that being said, how can PING help the WG design ways of fixing the spec to include mandatory privacy protections for the privacy harms introduced in the spec?  Mike O’Neill has been doing great work demonstrating the problem, and we met with you all at TPAC and received a very different set of answers than above.

What "different answers" do you mean? I watched the recording before 
writing the WeBRTC TPAC summary. If you find a discrepancy, please let 
me know!

AFAIK "3) how device labels interact with permissions" or "why giving 
permission to a single device gives access to all device labels / ids)." 
were not discussed at TPAC.


> How can we help get privacy protections in the spec?

If you could follow up and answer some of the stalled challenges raised 
in this thread that would be great thanks! I feel the more specific we 
can be here, the more productive it'll be.

Thanks,

.: Jan-Ivar :.


>
> Pete
>
>
>
>
>>> Would it be possible for the WG to summarize the current state of things, and where things have changed since the conversation at TPAC?
>> Stronger enumerateDevices filtering is being worked on (see https://github.com/w3c/mediacapture-main/pull/632).
>> Once there is agreement there, the next steps to discuss in that area will be:
>> - Discuss whether we can replace device-info permission by a browsing context state.
>> - Discuss whether we can fully conceal the presence/absence of capture devices.
>>
>> Hope this helps, let’s continue the discussion.
>>
>> Thanks,
>>  Y
>>
>>> Thanks!
>>>
>>>
>>>
>>> Pete Snyder
>>> {pes,psnyder}@brave.com
>>> Brave Software
>>> Privacy Researcher
>>>
>>>> On Oct 10, 2019, at 3:44 AM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
>>>>
>>>>>> Pretty sure revoking camera and microphone permissions revokes device-info permission in all browsers: https://jsfiddle.net/jib1/LbtxeLvw/show
>>>> Not on Chrome, Chromium Edge or Firefox
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: Jan-Ivar Bruaroey <jib@mozilla.com>
>>>> Sent: 09 October 2019 00:43
>>>> To: Youenn Fablet <youenn@apple.com>
>>>> Cc: michael.oneill@baycloud.com; Pete Snyder <psnyder@brave.com>; public-privacy <public-privacy@w3.org>; public-webrtc@w3.org
>>>> Subject: Re: Follow up issues from WebRTC / PING TPAC meeting
>>>>
>>>> On 10/7/19 2:48 AM, Youenn Fablet wrote:
>>>>
>>>>>> The remaining discussion appears to be what's shared once this implicit device-info permission is granted, which is lots of stuff. Like labels.
>>>>> It seems part of the issue comes from the fact that browsers may decide to grant the device-info permission forever after a getUserMedia prompt is granted once.
>>>>> This might be difficult for users to remember and understand.
>>>> Sorry I meant to focus on the deviceId still. I aimed to show that—assuming we follow the parts of Safari's model we agree on—the deviceId is not exposed until the label is exposed. That they both leak when the device-info permission is granted is kind of irrelevant, since neither the id nor the label (e.g. "HD PRO Webcam C920") expire on revocation of the device-info permission. By that I mean they're already leaked and presumably stashed in storage.
>>>> To stress my point: double-keying the deviceId seems silly when you have the label of which it is a hash (+ origin).
>>>> Sure, if you don't have storage then the label goes away with the device-permission (it disappears from future enumerateDevices() calls).
>>>>> This behaviour is in user agent land and the spec does not say anything about it right now. Maybe the spec should provide guidelines and warn against that.
>>>> Pretty sure revoking camera and microphone permissions revokes device-info permission in all browsers: https://jsfiddle.net/jib1/LbtxeLvw/show
>>>>> Or we could go further and only expose device info on a page based on specific user actions on that page, like if getUserMedia promise is resolved successfully.
>>>>> Maybe we should remove the concept of the device-info permission, which is different and more difficult to explain than a camera permission or a geolocation permission.
>>>> This is effectively what Firefox implements by default.
>>>>>> Which leads me to my last idea:
>>>>>>  • Remove deviceId
>>>>>>  • Add a deviceName constraint (no-op without device-info permission)
>>>>>> Then let JS store the label instead:
>>>>>>   const stream = await navigator.mediaDevices.getUserMedia({video: {deviceName: localStorage.chosenCamera}});
>>>>>>   localStorage.chosenCamera = stream.getVideoTracks()[0].label;
>>>>>> We only needed deviceId in the first place to cover the "choose camera beforehand" use-case, when there's no label.
>>>>>> Would that make us happy?
>>>>> In a perfect world, I am not sure we would like to expose all device labels.
>>>>> Labels are very persistent and, except for built-in capture devices, might be very user specific.
>>>>> On the contrary, the browser is in full control of device Ids, can regenerate them at will.
>>>>> Device IDs can also handle complex cases that labels cannot.
>>>> I agree with this. While I meant it as a genuine proposal (getting rid of deviceId would let us rip out a bunch of code, and close some outstanding issues to boot), I also meant to show the diminishing returns of getting rid of or trying to taper deviceId exposure alone.
>>>> .: Jan-Ivar :.
>>>>

Received on Friday, 25 October 2019 20:41:35 UTC