-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vibration API (Second Edition) #907
Comments
This: In particular, it is known that certain sensors such as accelerometers or gyroscopes are prone to tiny imperfections during their manufacturing. As such, they provide a fingerprinting surface that can be exploited utilizing the vibration stimuli generated via the Vibration API. It is not easy to explore this "bug," but it would be excellent to have some kind of mitigation or to disable this function entirely. |
Yeah, my concern with it was the potential annoyance of any website being
able to shake your device.
|
Same concerns over on the WebKit side, FWIW. |
Currently in Firefox for Android the Vibration API does nothing because it requires a permission but the permission is not implemented, see https://bugzilla.mozilla.org/show_bug.cgi?id=1495036 For the fingerprinting concern, I'm not sure prompting the user is a good fix since it's not reasonable to convey that aspect and expect users to understand. Is it ok to allow users who accept the prompt to be fingerprinted? Maybe making the affected sensor APIs artificially less sensitive or report less precise numbers while the device is vibrating is more effective. |
Doesn't the fingerprinting risk require that the site be able to simultaneously measure? That is, it would need accelerometer access to fingerprint using this. A simple fix for that would be to disable accelerometer inputs (maybe pretend that nothing is happening) while vibrating. That's probably a sensible thing to do anyway so that the rumbling doesn't throw things out. My understanding is that we have plenty of other reasons to disable accelerometer access anyway. When the keyboard is open and focused on cross-origin input fields, accelerometer access could be used to learn what is being typed. Another nice thing about the vibration API is that it doesn't say how intense the vibrations need to be. So if you accept the API call, you can immediately claim compliance, even if you don't have any means to physically shake the device or couldn't be bothered to generate vibrations. That fact can be exploited to cover the concern about annoyance. Sites can ask for vibrations all they like, but they won't get vibrations unless (insert conditions here). |
Webkit has it as opposed. |
Maybe not a standards position thing, but I'm confused about the spec's implementation report's claim that this is implemented by Firefox Android, but #907 (comment) seems to suggest otherwise? (and I guess also what @martinthomson said above about mitigating annoyance concerns by literally not vibrating, which entirely defeats the purpose of the API even existing) Can anyone clarify? That seems kinda serious if the W3C has this specification as a W3C Recommendation on the basis that this is implemented by Firefox. If it's the case that the spec is not actually implemented or supported, it may be prudent to request that W3C consider obsoleting the Recommendation status. |
@marcoscaceres I believe it regressed some time after version 36. |
This is officially opposed by WebKit now. |
Are there any updates on the position on this spec? |
Not related to position, but discussion on the outdated implementation report: |
Request for Mozilla Position on an Emerging Web Specification
@
-mention GitHub accounts): @anssikoOther information
In their words:
The API is specifically designed to address use cases that require simple tactile feedback only. Use cases requiring more fine-grained control are out of scope for this specification. This API is not meant to be used as a generic notification mechanism. Such use cases may be handled using the Notifications API [NOTIFICATIONS] specification. In addition, determining whether vibration is enabled is out of scope for this specification.
The text was updated successfully, but these errors were encountered: