Re: Follow up issues from WebRTC / PING TPAC meeting

A bit late on the followup....

On 10/1/19 9:44 AM, Youenn Fablet wrote:
> Pete, please find inline.
>
> I think the idea is for me to write some PRs and have your feedback on these.
> This might help scoping the discussion and fine tuning the various changes to the specs we discussed (and agreed I think) at TPAC.
>  Y
>
>
>> On 1 Oct 2019, at 00:19, Pete Snyder <psnyder@brave.com> wrote:
>>
>>>>> Regarding values returned by enumerateDevices (#612)
>>>>> ---
>>> This is true if device-info permission is not granted to the page.
>>> If device-info permission is granted (after user granted access to the camera for instance), enumerateDevices will provide the full list of devices, with labels and ids.
>> Do I understand right that if I give access to a single device, enumerateDevices will return information about all devices?  This was not my understanding from the TPAC conversation, and more sig, it seems unnecessarily privacy harming.
> I do not know any browser implementing this approach right now.
> The permission spec states that granting getUserMedia is granting device info permission which grants information on all available devices.
> I think the spec allows what you are proposing but does not enforce it.
> The idea would be to emulate that devices being used are actually plugged in just before starting to use them.

Yes, the thinking in the WG was that when you have given access to a
single device, you have effectively given permission for a level of
tracking that is strictly greater than what can be accomplished using
enumerateDevices, so a) it doesn't give any incremental harm to privacy,
b) it gives the user convenient access to changing devices without
having to "grope in the dark" for them, and c) it is relatively easy to
explain to the user how to manage it. (A prompt of "you have granted
access to the front camera, but you now have to do special things to
figure out whether or not you have a back camera" didn't seem like an
usability feature).

Background on one camera vs multiple cameras: In the first iteration of
WebRTC, both Chrome and Firefox implemented permission for single cameras.

Based on user feedback, Chrome switched its approach to normally
granting access to either all cameras or none, while Firefox kept on
granting access to one camera at a time. The spec was written so that
both implementation methods were allowed. When we started hanging other
permissions off the camera access, these were mostly field-tested first
with the Chrome permission model, so the question of whether it mattered
which camera you were given access to was not seriously considered.

It makes more sense to discuss this with enumerateDevices, since it
actually says something about devices separately, but personally, I
think we've made the right tradeoff.

>
>> Could enumerateDevices just return only the union of
>> 1) always return an object that does not include any device ids or labels, one entry describing every possible device type
>> 2) information about any device the user has given permission too
> Sadly, I think this would break existing websites, see for instance how most webrtc providers implement their device pickers.

In such a concept, I can't see how to construct an useful user dialog
that lets the user ask for permission to use a second camera.

It may make sense to remove from the enumerateDevices output devices
that are in the "denied" permission state, but I don't think it makes
sense to remove those that are in the "ask" state.

>
>>>>> Regarding uniqueness of device IDs (#607)
>>>>> --
>>>>> For new hardware types (e.g. external speakers): device IDs MUST NOT be globally unique, but opaque-identifying integers (or some other non-identifying, non-unique handle).
>>> I think the idea is that for browsers exposing speakers through enumerateDevices, device IDs will be double keyed.
>>> There is discussion to find an alternative to that approach, hopefully I’ll have a full proposal soon.
>> My understanding (and it seems, not only my) from the TPAC conversation was that any new spec work would, at a minimum, not use UUID style device Ids, regardless of double keying, etc.  I don’t know if thats compatible with what you just said above. Can you clarify?
>>
>> Its my error / mistake to give "external speakers” as an example in the above.
> Oh I see. I agree with the general approach to expose progressively things as they are being used.

I don't agree with this general approach. I think this is going to be
confusing to the user.

I agree with the approach of hiding things completely when the user has
said that he will never permit access, but I don't agree with hiding
devices for which the user is expecting to be prompted for permission.

>
>>>>> Regarding "network type" identifiers in returned stats (#374)
>>>>> ---
>>>>> The standard will be updated to to remove this value from the returned dictionary of stats returned (e.g. no type key, and no "wifi", "ethernet", "vpn" value).
>>> The WebRTC WG plans to gather feedback from WebRTC stats users.
>> I don’t have any objection to asking more folks for feedback, but if the value privacy violating (and it sure seems to be), I don’t think its appropriate to connect the WG’s decision on the survey response.  E.g. "we’re only going to leave the non-web-compat-relevant privacy-harming value in the spec if its popular" isn’t a good way forward ;)

It's not a question of popularity, but a question of cost vs benefit.

If we can get most of the benefit while removing most of the privacy
impact, we probably should.

>>
>>>> Re double-keying device ids
>>>> ---
>>> The issue is not really that users will be reprompted.
>>> Websites will not be able to setup the call configuration as done the last time if last call happened in a different top level origin.
>> Sorry, I don’t follow this.  Once the site’s not able to re-set the call up (because the relevant stored value is being written to by two diff site instances), the most recent one will say “I can’t seem to find the device I expect to” and reprompt the user (as if the user had disconnected a web cam or whatever).  Can you point to popular code in the wild that would break / not reprompt? 
>>
>>> This creates a compat risk for WebRTC SDK vendors without getting much privacy benefits if other storages are not double keyed.
>> We all agree that double keying is better than not double keying I think at this point.  The goal is to also protect the privacy of folks on non-double-keyed browsers.
> I am not sure this is a goal of the WG but anyway, two mitigations we are adding will help a lot:
> - Most third party iframes are not able to use getUserMedia by default (they require feature policy opt-in using allow attribute for instance). In that case, enumerateDevices is expected to return an empty list.
> - device Ids are not provided until user grants getUserMedia
>
>>> If double keying for other storage is not shipped in some browsers, cross-site tracking will continue whatever we do about device IDs.
>>> Note also that the WG decided that device IDs will not be accessible until capture permission is granted.
>>> This can be shipped much sooner and will make actual usage of device IDs for tracking purposes much harder.
>> The web platform has so many privacy harming bugs in it that its going to take a long time to undo all the harm thats been caused.  The relevant question isn’t “will this particular fix stop tracking”, its “does it make things less-bad in a way that doesn’t break too many reasonable use cases”.  (Re break, still trying to understand how realistic this is from the above).
>>
>> But point taken about IDs not being available until permission is granted.  Thats better than the status quo (yeah!), but still more privacy-harming that is necessary (boo!)
>>
>>>> 4) the current spec text of “device ids should be reset when storage is reset” does not address the privacy concern, especially as some browsers move to dynamic policies for handling JS set storage (e.g. there is no single global “storage clear” event to decide when to reset device Ids against, but lots of small micro, per value decisions)
>>> I am not sure to follow, could you elaborate?
>> This is covered in the issue, but the short version is
>>
>> 1) some privacy-preserving browsers are moving away from the idea of a "single storage epoch” (I.e. “Im clearing all storage now”) to a large number of overlapping, per value “storage epoch”.  E.x. Safari and Brave clear all JS set cookies 7 days after being set, ITP2.3 does the same thing for all JS set storage, etc etc etc.  These frequent small-events is an intentional alternative to rare “clear everything” interventions like “clear all cookies”.
>>
>> 2) It's not clear how the standard should be read in this light.  There is no single “storage is cleared” event to key off.  You either harm the goals of these privacy preserving efforts (since the device id can be preserved / carried over between these mini epochs, see below), or wind up with all sorts of weird web compat issues (if you reset deviceIds anytime any storage value was deleted, you’d have deviceIds being reset on all sorts of odd, unpredictable schedules)
> Agreed we might need to clarify this.
> My understanding is that, whenever some storage of the given partition is cleared, we clear device IDs.
> Yes, we might end up in some compat issues but, if we started to clear some website data, there might be compat issues anyway.
>
> My recommendation to web developers is to use ideal deviceId constraints, so that if the device is not there, or device IDs are reset, the application will still get some audio/video.
>
>> E.g. 
>> // Day 0
>> window.localStorage.deviceId = deviceId
>> // Day 1
>> window.localStorage.deviceIdCopy = window.localStorage.deviceId
>> // Day 7 
>> window.localStorage.deviceId is cleared
>> // Day 7 pt 2
>> if (!window.localStorage.deviceId) window.localStorage.deviceId = window.localStorage.deviceIdCopy
>> // Day 8
>> window.localStorage.deviceIdCopy is cleared
>>
>>
>> TLDR its not a solution to have a long-lasting privacy harming value, but key it off storage lifetime.
>>
>>> I am unclear whether the PING WG would like us to continue digging in this approach given the plan is to mandate double keying.
>>> Can you clarify this?
>> Order of preference (attempting to summarize PING conversations)
>>
>> 1. Use non-uuid device handles AND double key on all platforms
>> 2. Use non-uuid device handles
>> 3. Double key UUIDs on all platforms
>> 4. Double key on some platforms (e.g. platforms that already double key)
>>
>> 1 would be great and show the most commitment to privacy. 2 would be great, 3 would be acceptable if non-uuid’s was unworkable.  4 is not a solution.
> I think the plan is to update the spec to align with 3.


The ranking between 2 and 3 is unclear to me, given that (as mentioned
in the WG) if we don't reuse non-uuid device handles, the pattern of
valid device handles will be fingerprinting after a few unplug/replug
events.

Using predictable handles (1, 2, 3) also allows probing for valid
devices without calling enumerateDevices - which was the reason we went
with recommending UUIDs in the first place.

At the moment, I think updating the spec to align with 3 is what seems
to be closest to consensus of the WG.


>
>>> As of why I am not sure how the proposal works, let’s take an example.
>>> Say we start with two cameras (back and front) that we give 1 and 2 as device IDs. Everything is fine.
>>> Let’s say now that a new camera is being plugged in.
>>> We give it device ID 3.
>>> Let’s say now that another new camera is being plugged in.
>>> We give it device ID 4.
>>>
>>> Now, we want persistency so that web pages can say 'I want device 3 at next visit’.
>>> This should be working except if user clears website data like cookies for that particular website.
>>> But we can no longer clear device IDs for this particular website since this will affect all websites.
>>>
>>> Also, if next time, we only have device IDs 1, 2 and 4, this information will be available to all origins that have device info permission.
>>> This would leak some interesting cross-site tracking information.
>>> We could then decide to use 1, 2 and 3 instead but then the web site is unable to select persistently device 4.
>> Sorry im having real trouble following the above, or at least the new privacy harms introduced.  The only change suggested here is that browsers do something equivalent to keeping an internal map of consecutive ints to “uuids", and expose the ints to the site instead.  This is orthogonal to double keying (it makes both the double keying option better AND it makes the non-double-keying option better).  This seems to be most relevant if the WG is dead set against requiring double-keying on _all_ platforms.  
> Is the map int->uuid partitioned? What is its lifetime? How is it better in the double-keying option?
> Consensus at TPAC is to require deviceIds double-keying in the specification.
>
>> In other words, there is no scenario where moving from UUIDs -> sequential ints reveals _more_ information, or would (its self) effect the life time of any value. 
>>
>>> AIUI, the double-keyed proposal solve this issue and is easier to implement by browser engines.
>> I’m totally baffled; what is the WG proposing to do to solve the current privacy harm on platforms that don’t double key all storage?  
> As said above, some mitigations can be shipped in those platforms sooner than double keying.
> The WG is defining a specification in the hope implementers will follow it.
> That is why it is important to have all implementers on board, which seems to be the case here.
> I am not sure what the WG can/should do in addition to that.
>
>>> FWIW, I like fixed device IDs and am advocating for using some for output speakers.
>>> This should in particular work great for devices that are always there for a given device (say loudspeaker/earpiece).
>> If you feel im misunderstanding you, or we’re talking past each other, maybe a call would be good.  I’d be happy to join you next time you have a WG call if that’d be helpful.
>>
>> Even if we’re disagreeing, thank you for taking the time to continue discussing this :)
>>
>> Pete

Having the issues be discussed where people can see the discussion is
always better than not communicating about them - thanks for being there!

Received on Wednesday, 2 October 2019 08:32:20 UTC