On Wednesday, March 20, 2019 at 7:10:54 PM UTC-7, Tom Ritter wrote: > > > > 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? > > Any state that is shared and exposed to unrelated origins becomes a > potential vector for either directly tracking or otherwise correlating > a user. For example: > > a) A heavy gamer may rack up a touchid in the millions during a > browser session. When visiting sites a.com and b.com, they see that > one person in particular has a gigantic touchid. They have a good idea > it is the same visitor to both sites. > > b) A user leaves a game on a.com and starts a game on b.com. By > comparing timestamps and touchid, the sites are quite certain it is > the same user who left with touchid 400 and appeared with touchid 401. > > As far as separating the value; it kind of depends on how you > implement it; but let's say you were going to use a static uint64_t or > something like that. Instead of heaving a static uint64_t, create a > Dictionary<OriginAttributes, uint64_t> and look up the uint64_t using > the OriginAttrbutes of the top level page. >
Regarding to `touchid, IIUC, it is a data member of a Gamepad, that means the attribute wouldn't be accessed across other pages. For examples, a gamepad whose `touchid` is 6 and `timestamp` is 5000 in a gamepad tab, when visiting to an another Gamepad tab, we will spawn a new gamepad object for this tab and its `touchid` and `timestamp` are 0. Therefore, I could not finding the possible usage case of OriginAttrbutes. > Also, as Ehsan mentioned, we should change the spec so that touchId is > keyed by the top level domain. > > > 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. > > Okay, good, not making this data available until the user activity > engages with the gamepad/VR controller (mostly) assuages my concerns > on this component. My remaining concern is around the sensitivity of > axis movement. If I have my controller on my desk, and I am > typing/bumping it - I am curious if that would cause the controller to > suddenly activate. I don't think I have a gamepad to test with > though. > > -tom For the sensitivity of axis movement, I aware Firefox needs do adjustments for this part. The axis of gamepad in Firefox always gives its first intent once its value is not 0. That means if some Gamepad axes value are not 0 even they are idle, the gamepad will be activated immediately. I will fix this issue shortly, I think 0.5 [0~1] threshold is a good value. (Chrome did the same threadhold from my tests.) Cheers, Daosheng Mu. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
