On Friday, March 15, 2019 at 8:35:41 AM UTC-7, Tom Ritter wrote: > Thanks for more details on the use case. > > On Wed, Mar 6, 2019 at 1:35 AM <d...@mozilla.com> wrote: > > > > On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote: > > > To add to Dan's comments here... > > > > > > Assuming that I'm reading this correctly [1], the fingerprinting risks are > > > pretty extreme here. In the touch spec, we have a monotonically > > > increasing > > > counter that doesn't appear to be origin-bound in any way. What is the > > > purpose of this identifier? In the light spec, we have full RGB control > > > over the light. Does the light change back to a default state when the > > > origin is no longer the primary input focus? > > > > > > Implementing specs of a private GitHub account is fine for the purposes of > > > getting feedback, but I think that we want a clearer signal that this is > > > an > > > accepted approach before we ship something like this. When you consider > > > the potential for security and privacy implications, this is particularly > > > important. > > > > > > > > > > Hi Martin, > > > > Sorry for reply late. > > We will restrict theses APIs to secure contexts to help it be more secure. > > Regarding to the touchId, the reason we wanna make it monotonically > > increasing is order to recognize if fingers have been released after the > > last touch. Let me give you two examples. > > > > Example 1: Let’s say touchId is currently set to 0 and no fingers are > > touching the touchpad. When a finger touches the touchpad, touchId of this > > event would be 1. As that finger moves around the touchpad, new touch > > events are added with updated coordinates, however, the touchId is still 1 > > to denote that the finger has not been lifted from the touchpad. If the > > finger is released and touches again, the touchId would then be 2. > > > > Example 2: In the case of multi touch, the first finger that touches the > > touchpad would have a touchId of 1. The next finger that touches the > > touchpad before the first finger is released would have a touchId of 2. If > > the first touch finger is released and touches again, that touchId would be > > 3. This way, the application can distinguish between different touches > > that have or haven’t been removed from the touchpad. > > > In this situation, it seems like the actual value of the field doesn't > matter, only that it is increasing relative to the last value. So it > should be possible to have separate values based on the origin. > > Not doing so creates a cross-origin tracking and fingerprinting vector. >
Thanks for your feedback! First of all. I am not quite sure I understand the cross-origin tracking mean, the `touchId` will increase when there is a new touch on the touchpad. It is exactly increasing relative to the last value, I would like to know why it would be an issue. We also have some APIs like timestamp that are also increased relative to the last value. If you suggest to separate the value, what is the possible approach? > > > In terms of lightColor, we would give the default color to [0, 0, 0] if > > there is no one set it yet or when it is just plugged in. Then, the > > application is allowed to set the controller's lightbar color whenever they > > want. I have reached the author and ask him add this description into his > > proposal. > > It appears that one can set but cannot read the lightColor, so that's good. > > GamepadPose gives me a lot of concern as well. If I have a gamepad > resting on my desk, I don't want every website to get a persistent > identifier about me because of the pose it's resting in. I think/hope > that there's something in the main gamepad spec where you can't > enumerate gamepads until the user has interacted with them, but I > don't recall for sure. > > I am very opposed to shipping this spec without addressing these concerns. > > -tom In our implementation, we will wait until users' first intention like button press, axis movement. Then, Firefox will fire a `gamepadconnected`[1]. Chrome also does the same restriction although the spec doesn't describe this is a must. Regarding to GamepadPose, we only implement it for VR controllers, we only can start to poll input events once users confirm they wanna enter the VR mode. Then, keep waiting for the first event like button press, axis movement, or pose change. Lastly, we will fire a `gamepadconnected`. Also, once they switch the VR tab to the background, we will close this VR session and don't listen to VR input events any more. [1] https://dxr.mozilla.org/mozilla-central/rev/25398e555020fef80c7b2a06a0d4c667e861cd6f/dom/gamepad/GamepadManager.cpp#425 - Daosheng Mu _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
