Skip to content
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

Open
MrBrain295 opened this issue Oct 14, 2023 · 11 comments
Open

Vibration API (Second Edition) #907

MrBrain295 opened this issue Oct 14, 2023 · 11 comments
Assignees

Comments

@MrBrain295
Copy link

Request for Mozilla Position on an Emerging Web Specification

  • Specification title: Vibration API (Second Edition)
  • Specification or proposal URL (if available): https://www.w3.org/TR/vibration/
  • Explainer URL (if available):
  • Proposal author(s) (@-mention GitHub accounts): @anssiko
  • Caniuse.com URL (optional):
  • Bugzilla URL (optional):
  • Mozillians who can provide input (optional):

Other 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.

@cosmic-zip
Copy link

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.

@MrBrain295
Copy link
Author

MrBrain295 commented Oct 15, 2023 via email

@marcoscaceres
Copy link
Contributor

Same concerns over on the WebKit side, FWIW.

@zcorpan
Copy link
Member

zcorpan commented Oct 18, 2023

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.

@martinthomson
Copy link
Member

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).

@MrBrain295
Copy link
Author

Webkit has it as opposed.

@marcoscaceres
Copy link
Contributor

marcoscaceres commented Nov 15, 2023

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.

@zcorpan
Copy link
Member

zcorpan commented Nov 15, 2023

@marcoscaceres I believe it regressed some time after version 36.

@MrBrain295
Copy link
Author

This is officially opposed by WebKit now.

@MrBrain295
Copy link
Author

Are there any updates on the position on this spec?

@marcoscaceres
Copy link
Contributor

Not related to position, but discussion on the outdated implementation report:
w3c/vibration#33

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Needs proposed position
Development

No branches or pull requests

5 participants