Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
On Mon, Mar 25, 2019 at 10:05 PM wrote: > > 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 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. Oh, excellent, then the desired behavior is already built in. > > 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.) Excellent. On Mon, Mar 25, 2019 at 10:10 PM wrote: > > There's a research question that suggests: gamepad accelerometers are > > pretty good, can they be used to recover what someone is typing based on > > those vibrations? Setting a minimum activation threshold to start using > > the controller might be wise. A button press is guaranteed to activate it, > > so we can be a little less sensitive for that. > > This is a good thought although not every gamepad has vibrate function. We > can do this enhancement for the devices own this functionality. I grabbed an XBox One controller (quite new, with good joysticks) and set it on my desk to run some tests. It activates when I move a joystick and informs the page. My normal typing does not activate it; however if I sit down at my desk and bump the desk or put my elbows on it with some (but not a painful amount) of force that also activates it. I suppose my ideal opinion here is that we only activate on button press rather than joystick but at the least increasing the threshold for the joystick is important. -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
On Friday, March 22, 2019 at 9:56:20 AM UTC-7, Martin Thomson wrote: > On Thu, Mar 21, 2019 at 1:11 PM Tom Ritter wrote: > > > 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. > > > > There's a research question that suggests: gamepad accelerometers are > pretty good, can they be used to recover what someone is typing based on > those vibrations? Setting a minimum activation threshold to start using > the controller might be wise. A button press is guaranteed to activate it, > so we can be a little less sensitive for that. This is a good thought although not every gamepad has vibrate function. We can do this enhancement for the devices own this functionality. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
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 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
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
On Thu, Mar 21, 2019 at 1:11 PM Tom Ritter wrote: > 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. > There's a research question that suggests: gamepad accelerometers are pretty good, can they be used to recover what someone is typing based on those vibrations? Setting a minimum activation threshold to start using the controller might be wise. A button press is guaranteed to activate it, so we can be a little less sensitive for that. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
> > > 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 and look up the uint64_t using the OriginAttrbutes of the top level page. 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
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 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
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
On Fri, Mar 15, 2019 at 11:35 AM Tom Ritter wrote: > Thanks for more details on the use case. > > On Wed, Mar 6, 2019 at 1:35 AM 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. > I assume you mean the origin of the top-level page here. As far as I can tell from the current spec, we can implement this restriction based on the current spec but since we are the first engine to ship this it seems prudent to change the spec as well in order to ensure all future implementations would implement this in a privacy-preserving manner. > Not doing so creates a cross-origin tracking and fingerprinting vector. > > > > 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. > There is: https://w3c.github.io/gamepad/#dom-navigator-getgamepads. But note that with resist fingerprinting mode we always return an empty array from navigator.getGamepads(). > I am very opposed to shipping this spec without addressing these concerns. > > -tom > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > Thanks, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
Thanks for more details on the use case. On Wed, Mar 6, 2019 at 1:35 AM 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. > 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
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 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. Cheers, Daosheng Mu > > On Tue, Feb 26, 2019 at 11:08 AM Daosheng Mu wrote: > > > Hi Daniel, > > > > We didn't have a chance to discuss privacy issues in Gamepad Extension or > > Gamepad API. We were trying to get responses for the Privacy review [1] but > > without any updates yet. > > > > Cheers, > > > > [1] > > https://lists.w3.org/Archives/Public/public-privacy/2018AprJun/0030.html > > > > -- > > Daosheng Mu > > Software Engineer | Mozilla > > d...@mozilla.com > > > > > > On Mon, Feb 25, 2019 at 2:47 PM Daniel Veditz wrote: > > > > > Neither of the words "security" or "privacy" appear in this spec (most w3 > > > web specs have at least a token attempt at a "Privacy and Security > > > Considerations" section). At a surface glance this appears to add > > > additional fingerprinting exposure. Have you talked to the privacy team > > > about ways to minimize this? > > > > > > -Dan Veditz > > > > > > On Mon, Feb 25, 2019 at 11:45 AM Daosheng Mu wrote: > > > > > >> Summary: > > >> In order to support controllers which have multi touch and light bar > > >> features like Sony DualShock 4. The `*multi touch*` and `*light > > >> indicator*` > > >> APIs for gamepad extensions are the things we must have. In > > >> `*GamepadTouch*` > > >> API, it would make us know touch surface's dimension and its unique id. > > We > > >> also will have a way to know where is the place we are touching > > according > > >> to its position and the unique id. Regarding to > > `*GamepadLightIndicator*`, > > >> it could tell users the color of controller's light bar. The color is a > > >> 8-bit size integer for defining `*red*`, `*green*`, `*blue*`, or other > > >> colors to indicate the on-off light indicator is ON. > > >> > > >> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1523350 > > >> > > >> Link to standard: > > >> W3C Multi touch spec proposal: > > >> https://github.com/knyg/gamepad/blob/multitouch/extensions.html > > >> W3C Light indicator spec proposal: > > >> https://github.com/knyg/gamepad/blob/lightindicator/extensions.html > > >> > > >> Platform coverage: Windows, Mac OS, Linux > > >> > > >> Estimated or target release: Firefox 68 > > >> > > >> Preference behind which this will be implemented: > > >> "dom.gamepad.extensions.multitouch" and > > >> "dom.gamepad.extensions.lightindicator" > > >> > > >> Do other browser engines implement this? Nope > > >> > > >> web-platform-tests: none exist (and I don't plan to write WPTs but we do > > >> have gamepad mochitest, I will add new tests to cover these two new > > APIs.) > > >> > > >> Is this feature restricted to secure contexts? Nope > > >> > > >> How stable is the spec? This
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
On Wed, Feb 27, 2019, at 6:43 AM, James Graham wrote: > The current thinking is that hardware interaction APIs which rely on > mocks to test should specify the API for testing as part of the > specification (e.g. [1]). So it seems like the same approach could be > used here. > > [1] https://webbluetoothcg.github.io/web-bluetooth/tests This is neat! I don't think I had seen any prior art for this when we were doing the original Gamepad API work. It seems like it would be straightforward to take the existing Gamepad test interface[1] we use for Mochitests and include it in the Gamepad spec in a form that could be used for web-platform-tests. -Ted 1. https://searchfox.org/mozilla-central/rev/2a6f3dde00801374d3b2a704232de54a132af389/dom/webidl/GamepadServiceTest.webidl ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
On 26/02/2019 22:49, d...@mozilla.com wrote: On Tuesday, February 26, 2019 at 2:15:57 AM UTC-8, James Graham wrote: On 25/02/2019 19:44, Daosheng Mu wrote: web-platform-tests: none exist (and I don't plan to write WPTs but we do have gamepad mochitest, I will add new tests to cover these two new APIs.) Why do you plan to not write web-platform-tests? I imagine there may be technical challenges, but we should ensure that those are well understood before falling back on browser-specific tests. In the absence of web-platform-tests what's the strategy to ensure that implementations of this feature are interoperable and we don't end up fighting compat fires in the future? Gamepad tests require a real gamepad to run them, so wpt/gamepad are all manual tests in Firefox [1]. Our solution is making a GamepadTestService to help us do this puppet tests, the GamepadTestService will be launched once we run our gamepad mochitest and perform as a real gamepad under our automated testing. Besides, there is no tests for Gamepad extension so far. Therefore, if there is no big change, I would continue following the same scenario as before. The current thinking is that hardware interaction APIs which rely on mocks to test should specify the API for testing as part of the specification (e.g. [1]). So it seems like the same approach could be used here. [1] https://webbluetoothcg.github.io/web-bluetooth/tests ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
On Tuesday, February 26, 2019 at 2:15:57 AM UTC-8, James Graham wrote: > On 25/02/2019 19:44, Daosheng Mu wrote: > > > web-platform-tests: none exist (and I don't plan to write WPTs but we do > > have gamepad mochitest, I will add new tests to cover these two new APIs.) > > Why do you plan to not write web-platform-tests? I imagine there may be > technical challenges, but we should ensure that those are well > understood before falling back on browser-specific tests. > > In the absence of web-platform-tests what's the strategy to ensure that > implementations of this feature are interoperable and we don't end up > fighting compat fires in the future? Gamepad tests require a real gamepad to run them, so wpt/gamepad are all manual tests in Firefox [1]. Our solution is making a GamepadTestService to help us do this puppet tests, the GamepadTestService will be launched once we run our gamepad mochitest and perform as a real gamepad under our automated testing. Besides, there is no tests for Gamepad extension so far. Therefore, if there is no big change, I would continue following the same scenario as before. [1] https://github.com/web-platform-tests/wpt/tree/master/gamepad [2] https://searchfox.org/mozilla-central/source/dom/tests/mochitest/gamepad/mock_gamepad.js ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
-- Daosheng Mu Software Engineer | Mozilla d...@mozilla.com On Tue, Feb 26, 2019 at 1:14 AM Julien Cristau wrote: > On Mon, Feb 25, 2019 at 8:45 PM Daosheng Mu wrote: > >> Is this feature restricted to secure contexts? Nope >> > > Why not? > > I agree. I will make it be restricted to secure contexts especially for this kind of hardware API. Actually, I also think all Gamepad API should only allowed to be access in secure contexts. > Cheers, > Julien > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
On 25/02/2019 19:44, Daosheng Mu wrote: web-platform-tests: none exist (and I don't plan to write WPTs but we do have gamepad mochitest, I will add new tests to cover these two new APIs.) Why do you plan to not write web-platform-tests? I imagine there may be technical challenges, but we should ensure that those are well understood before falling back on browser-specific tests. In the absence of web-platform-tests what's the strategy to ensure that implementations of this feature are interoperable and we don't end up fighting compat fires in the future? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
On Mon, Feb 25, 2019 at 8:45 PM Daosheng Mu wrote: > Is this feature restricted to secure contexts? Nope > Why not? Cheers, Julien ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
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. On Tue, Feb 26, 2019 at 11:08 AM Daosheng Mu wrote: > Hi Daniel, > > We didn't have a chance to discuss privacy issues in Gamepad Extension or > Gamepad API. We were trying to get responses for the Privacy review [1] but > without any updates yet. > > Cheers, > > [1] > https://lists.w3.org/Archives/Public/public-privacy/2018AprJun/0030.html > > -- > Daosheng Mu > Software Engineer | Mozilla > d...@mozilla.com > > > On Mon, Feb 25, 2019 at 2:47 PM Daniel Veditz wrote: > > > Neither of the words "security" or "privacy" appear in this spec (most w3 > > web specs have at least a token attempt at a "Privacy and Security > > Considerations" section). At a surface glance this appears to add > > additional fingerprinting exposure. Have you talked to the privacy team > > about ways to minimize this? > > > > -Dan Veditz > > > > On Mon, Feb 25, 2019 at 11:45 AM Daosheng Mu wrote: > > > >> Summary: > >> In order to support controllers which have multi touch and light bar > >> features like Sony DualShock 4. The `*multi touch*` and `*light > >> indicator*` > >> APIs for gamepad extensions are the things we must have. In > >> `*GamepadTouch*` > >> API, it would make us know touch surface's dimension and its unique id. > We > >> also will have a way to know where is the place we are touching > according > >> to its position and the unique id. Regarding to > `*GamepadLightIndicator*`, > >> it could tell users the color of controller's light bar. The color is a > >> 8-bit size integer for defining `*red*`, `*green*`, `*blue*`, or other > >> colors to indicate the on-off light indicator is ON. > >> > >> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1523350 > >> > >> Link to standard: > >> W3C Multi touch spec proposal: > >> https://github.com/knyg/gamepad/blob/multitouch/extensions.html > >> W3C Light indicator spec proposal: > >> https://github.com/knyg/gamepad/blob/lightindicator/extensions.html > >> > >> Platform coverage: Windows, Mac OS, Linux > >> > >> Estimated or target release: Firefox 68 > >> > >> Preference behind which this will be implemented: > >> "dom.gamepad.extensions.multitouch" and > >> "dom.gamepad.extensions.lightindicator" > >> > >> Do other browser engines implement this? Nope > >> > >> web-platform-tests: none exist (and I don't plan to write WPTs but we do > >> have gamepad mochitest, I will add new tests to cover these two new > APIs.) > >> > >> Is this feature restricted to secure contexts? Nope > >> > >> How stable is the spec? This is a proposal from a vendor, I suppose it > >> would be some minor adjustments coming when other developers start to > >> implement it. I would suggest to make it pref'd off by default until > this > >> proposal be merged to w3c's branch. > >> > >> > >> -- > >> Daosheng Mu > >> Software Engineer | Mozilla > >> d...@mozilla.com > >> ___ > >> dev-platform mailing list > >> dev-platform@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-platform > >> > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
Hi Daniel, We didn't have a chance to discuss privacy issues in Gamepad Extension or Gamepad API. We were trying to get responses for the Privacy review [1] but without any updates yet. Cheers, [1] https://lists.w3.org/Archives/Public/public-privacy/2018AprJun/0030.html -- Daosheng Mu Software Engineer | Mozilla d...@mozilla.com On Mon, Feb 25, 2019 at 2:47 PM Daniel Veditz wrote: > Neither of the words "security" or "privacy" appear in this spec (most w3 > web specs have at least a token attempt at a "Privacy and Security > Considerations" section). At a surface glance this appears to add > additional fingerprinting exposure. Have you talked to the privacy team > about ways to minimize this? > > -Dan Veditz > > On Mon, Feb 25, 2019 at 11:45 AM Daosheng Mu wrote: > >> Summary: >> In order to support controllers which have multi touch and light bar >> features like Sony DualShock 4. The `*multi touch*` and `*light >> indicator*` >> APIs for gamepad extensions are the things we must have. In >> `*GamepadTouch*` >> API, it would make us know touch surface's dimension and its unique id. We >> also will have a way to know where is the place we are touching according >> to its position and the unique id. Regarding to `*GamepadLightIndicator*`, >> it could tell users the color of controller's light bar. The color is a >> 8-bit size integer for defining `*red*`, `*green*`, `*blue*`, or other >> colors to indicate the on-off light indicator is ON. >> >> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1523350 >> >> Link to standard: >> W3C Multi touch spec proposal: >> https://github.com/knyg/gamepad/blob/multitouch/extensions.html >> W3C Light indicator spec proposal: >> https://github.com/knyg/gamepad/blob/lightindicator/extensions.html >> >> Platform coverage: Windows, Mac OS, Linux >> >> Estimated or target release: Firefox 68 >> >> Preference behind which this will be implemented: >> "dom.gamepad.extensions.multitouch" and >> "dom.gamepad.extensions.lightindicator" >> >> Do other browser engines implement this? Nope >> >> web-platform-tests: none exist (and I don't plan to write WPTs but we do >> have gamepad mochitest, I will add new tests to cover these two new APIs.) >> >> Is this feature restricted to secure contexts? Nope >> >> How stable is the spec? This is a proposal from a vendor, I suppose it >> would be some minor adjustments coming when other developers start to >> implement it. I would suggest to make it pref'd off by default until this >> proposal be merged to w3c's branch. >> >> >> -- >> Daosheng Mu >> Software Engineer | Mozilla >> d...@mozilla.com >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
Neither of the words "security" or "privacy" appear in this spec (most w3 web specs have at least a token attempt at a "Privacy and Security Considerations" section). At a surface glance this appears to add additional fingerprinting exposure. Have you talked to the privacy team about ways to minimize this? -Dan Veditz On Mon, Feb 25, 2019 at 11:45 AM Daosheng Mu wrote: > Summary: > In order to support controllers which have multi touch and light bar > features like Sony DualShock 4. The `*multi touch*` and `*light indicator*` > APIs for gamepad extensions are the things we must have. In > `*GamepadTouch*` > API, it would make us know touch surface's dimension and its unique id. We > also will have a way to know where is the place we are touching according > to its position and the unique id. Regarding to `*GamepadLightIndicator*`, > it could tell users the color of controller's light bar. The color is a > 8-bit size integer for defining `*red*`, `*green*`, `*blue*`, or other > colors to indicate the on-off light indicator is ON. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1523350 > > Link to standard: > W3C Multi touch spec proposal: > https://github.com/knyg/gamepad/blob/multitouch/extensions.html > W3C Light indicator spec proposal: > https://github.com/knyg/gamepad/blob/lightindicator/extensions.html > > Platform coverage: Windows, Mac OS, Linux > > Estimated or target release: Firefox 68 > > Preference behind which this will be implemented: > "dom.gamepad.extensions.multitouch" and > "dom.gamepad.extensions.lightindicator" > > Do other browser engines implement this? Nope > > web-platform-tests: none exist (and I don't plan to write WPTs but we do > have gamepad mochitest, I will add new tests to cover these two new APIs.) > > Is this feature restricted to secure contexts? Nope > > How stable is the spec? This is a proposal from a vendor, I suppose it > would be some minor adjustments coming when other developers start to > implement it. I would suggest to make it pref'd off by default until this > proposal be merged to w3c's branch. > > > -- > Daosheng Mu > Software Engineer | Mozilla > d...@mozilla.com > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
