Vibration API 2024-06-28 > 2024-09-20

[anssiko]

In the issue title above add the document name followed by the date of this request, then the date of your proposed deadline for comments.

• name of spec to be reviewed: Vibration API

• URL of spec: https://w3c.github.io/vibration/ (Why ED? See "Other comments")

• Current Rec/Note phase? Recommendation

• What and when is your next expected transition? After TPAC 2024

• What has changed since any previous review?

Please see the commit history for details and the changes section for an overview of the changes since the latest published version. Diff between the latest published version and the staged snapshot is available at htmldiff.

• Please point to the results of your self-review: Security and Privacy Self-review vibration#36
• Where and how to file issues arising? https://github.com/w3c/vibration/issues
• Pointer to any explainer for the spec?

This feature predates the explainer era, but its MDN entry serves as a good starting point.

Other comments:

Due to complexity of revising a Recommendation under the old process, TR for this specification did not receive these latest updates informed by implementation experience, but they were incorporated into the Editor's Draft instead. This caused some unfortunate confusion among readers not closely watching the specification. To clear this confusion, supported by reinvigorated interest and process improvements for revising a Recommendation, this API is now being revived on the Recommendation Track to allow bringing the updates from the ED back to TR and to allow for further improvements using the modern streamlined publication flow.

Thank you for your review!

[KimCerra]

we’re working on it with @simoneonofri

[simoneonofri]

Hi @anssiko, we have prepared an initial review. Let us know what you think.

Vibration API

Scope

Editor: @KimCerra, @simoneonofri

Metadata

• Commit: 58af2d3bca10bd9d01188553ce6f74ec7e5d9fc1
• Preview: https://pr-preview.s3.amazonaws.com/w3c/vibration/pull/35.html
• Security Request: Vibration API 2024-06-28 > 2024-09-20 #71
• Security and Privacy Self-review Security and Privacy Self-review vibration#36
• Second Edition Security implementations: https://www.w3.org/TR/vibration/

Abstract

This specification defines an API that provides access to the vibration mechanism of the hosting device. Vibration is a form of tactile feedback.

Use cases

Better user experience with tactile feedback, Gaming, and increasing features of PWA when application is on focus.

Security and privacy considerations

Vibration API is not a source of data on its own and, as such, is not producing any data that is possible to consume on the Web. However, it is known that it can serve as a source of events for other APIs. 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. In this sense, Vibration API provides an indirect privacy risk in conjunction with other mechanisms. This can create possibly unexpected privacy risks, including cross-device tracking and communication. Additionally, a vibrating device might be visible to external observers and enable physical identification and possibly tracking of the user.

For these reasons, the user agent SHOULD inform the user when the API is being used and provide a mechanism to disable the API (effectively no-op) on a per-origin basis or globally.

Review

Summary

	Fingerprinting and Cross-Device Tracking.	Draining Battery/User’s Resources DoS.	Simulate normal device behaviors.	Out-of-band/Side Channel communication
Standardize Max Length and Duration	⚫️
Include Random Vibration	⚫️			⚫️
Request User Consent	⚫️	⚫️	⚫️	⚫️
Minimize Information Disclosure in Error Messages	⚫️	⚫️
Limit API Usage		⚫️

Threats and Attacks

Fingerprinting and Cross-Device Tracking.

The max length and duration are implementation-dependent, meaning each browser or device manufacturer can set limits. This variability can create inconsistencies across devices, enabling attackers to identify and fingerprint devices based on how they handle vibration patterns.

For example, with or without other functions, such as accelerometers and gyroscopes, which detect motion and orientation, device fingerprinting can be exploited due to slight manufacturing variations.

Mitigations:

• Standardize Max Length and Duration
• Include Random Vibration
• Request User Consent
• Minimize Information Disclosure in Error Messages

Draining Battery/User’s Resources DoS.

Repeated or prolonged use of the Vibration API could degrade device performance, drain the battery, or annoy users through continuous or excessive vibrations.

For example, a malicious script could repeatedly queue vibration tasks in the event loop, leading to frequent or continuous vibrations.

While the Vibration API has built-in limits, the event loop’s ability to quickly re-queue tasks could be exploited to create a denial-of-service (DoS) scenario, where the device’s battery is drained or the user is subjected to constant vibrations.

Mitigations:

• Request User Consent
• Minimize Information Disclosure in Error Messages
• Limit API Usage

Simulate normal phone behaviors.

It is possible to simulate legitimate phone behaviors with vibration, such as notifications, alerts, or incoming calls, to trick users into performing certain actions (e.g., clicking on a phishing link or providing sensitive information). The vibrations triggered could mimic real notifications from the OS or other legitimate apps, leading users to believe they are interacting with a trusted source.

For example, a scammer could create a website that mimics the behavior of a trusted service and use the Vibration API to simulate the phone's vibration for an incoming message or alert, prompting the user to respond in a way that compromises their security.

Mitigations:

• Request User Consent

Out-of-band/Side Channel communication.

The vibration can be an out-of-band or side-channel communication vector between different browser contexts or devices.

For example, one website could induce a specific vibration pattern that another device, nearby or in contact with the same surface, could detect and interpret, potentially creating a covert communication channel.

Mitigations:

• Include Random Vibration
• Request User Consent

Mitigations

Standardize of Max Length and Duration

Standardizing the maximum length and duration ensures that the same vibration pattern will produce the same results, regardless of the browser or device, thus minimizing the risk of cross-platform tracking.

Threats and Attacks:

• Fingerprinting and Cross-Device Tracking

Include Random Vibration

Introduce slight random variations in vibration patterns to obscure device-specific characteristics further, making fingerprinting more difficult.

Threats and Attacks:

• Fingerprinting and Cross-Device Tracking
• Out-of-band/Side Channel communication

Request User Consent

Permission controls require explicit user permission before any use of the Vibration API is allowed. This ensures that users know when their device’s vibration feature is being accessed. Permissions must be granted per site, ensuring each website obtains consent separately (e.g., not subdomain permission).

Provide the feature to disable the vibration for the specific tab, such as the mute for audio.

Threats and Attacks:

• Fingerprinting and Cross-Device Tracking
• Draining Battery/User’s Resources DoS
• Simulate normal device behaviors.
• Out-of-band/Side Channel communication

Minimize Information Disclosure in Error Handling

Use the same message if the API is not available because of hardware limitation or permission, and ensure that this lack of availability cannot be used to infer device-specific or user-specific information.

Threats and Attacks:

• Fingerprinting and Cross-Device Tracking.
• Draining Battery/User’s Resources DoS.

Limit API Usage

Global: A global rate limit should be implemented to restrict the number of vibration requests made within a certain period (e.g., per minute or hour), preventing excessive use.

Session-Based: To prevent prolonged abuse, set session-based limits on the total vibration duration or number of vibrations that can occur during a single-user session.

Site-based: per site and subdomains

Threats and Attacks:

• Draining Battery/User’s Resources DoS.

References

• https://www.w3.org/TR/permissions/
• https://www.w3.org/TR/fingerprinting-guidance/

[anssiko]

@simoneonofri @KimCerra, thank you for the detailed review! It is great to see these horizontal security reviews revived.

We'll discuss this feedback at our F2F and you're welcome to join us on 24 September 2024 at around 15:00 local / 22:00 UTC w3c/devicesensors-wg#69

[simoneonofri]

you're welcome @anssiko.

I have to see my schedule for TPAC, but I will do my best to drop in.

In any case, some further brainstorming might be helpful to see if there are other threats.

However, if any threats have already been “dealt with”, since we preferred to start with as loose an approach as possible, it would be important to add a paragraph on mitigations (and where they are in the standard) and then include an additional paragraph on the residual threat (so what is possible after mitigations)

Same thing for those threats for which you choose not to apply mitigations and why.

[anssiko]

@simoneonofri thanks again for your extensive review. Here's an initial proposal on how to incorporate the proposed mitigations into the specification. We look forward to refining this proposal further with you at TPAC.

Standardize of Max Length and Duration

Add to Security and privacy considerations:

It is recommended that the user agent limits max length and max duration to ensure the same vibration pattern will produce the same results, regardless of the browser or device, thus minimizing the risk of cross-platform tracking.

My expectation is that the underlying platform APIs (e.g. Android Vibrator API) will normalize this behavior across hardware running on each OS and "implementation-dependent" allows each OS to make use of its platform limits. Or would it be preferred to normalize this across OSes? OS-level normalization might not reduce fingerprint entropy significantly, given OS information can be obtained from e.g. UA string?

Include Random Vibration

Add to Security and privacy considerations:

The use agent may introduce slight random variations in vibration patterns to obscure device-specific characteristics further, making fingerprinting more difficult.

Request User Consent

We have the following text in Security and privacy considerations for this consideration:

[T]he user agent SHOULD inform the user when the API is being used and provide a mechanism to disable the API (effectively no-op), on a per-origin basis or globally.

This is to retain web compatibility and work with sticky activation-based user activation-gating.

Minimize Information Disclosure in Error Handling

The vibrate() method returns a boolean to indicate whether the perform vibration operation succeeded. No other information is disclosed. This one bit of information enables applications to implement fallback behaviour as appropriate.

Limit API Usage

Add to Security and privacy considerations:

The use agent should employ global rate limiting to restrict the number of vibration requests made within a certain period (e.g., per minute or hour) to prevent excessive use.

[KimCerra]

@simoneonofri thanks again for your extensive review. Here's an initial proposal on how to incorporate the proposed mitigations into the specification. We look forward to refining this proposal further with you at TPAC.

Standardize of Max Length and Duration

Add to Security and privacy considerations:

It is recommended that the user agent limits max length and max duration to ensure the same vibration pattern will produce the same results, regardless of the browser or device, thus minimizing the risk of cross-platform tracking.

My expectation is that the underlying platform APIs (e.g. Android Vibrator API) will normalize this behavior across hardware running on each OS and "implementation-dependent" allows each OS to make use of its platform limits. Or would it be preferred to normalize this across OSes? OS-level normalization might not reduce fingerprint entropy significantly, given OS information can be obtained from e.g. UA string?

Hi @anssiko, thank you for the review! we agree that standardizing the Vibration API is crucial to prevent inconsistent behaviors across different operating systems and browsers. This kind of standardization can significantly help in reducing the risk of fingerprinting.
As @simoneonofri and I have discussed, attackers often disregard the user agent string, as it can be easily manipulated. Instead, real attackers tend to focus on behavioral patterns, such as those derived from the vibration API, because these provide more reliable and harder-to-alter information about the device. Ensuring a consistent implementation across platforms would be a strong step towards enhancing user privacy and security.

Include Random Vibration

Add to Security and privacy considerations:

The use agent may introduce slight random variations in vibration patterns to obscure device-specific characteristics further, making fingerprinting more difficult.

Request User Consent

We have the following text in Security and privacy considerations for this consideration:

[T]he user agent SHOULD inform the user when the API is being used and provide a mechanism to disable the API (effectively no-op), on a per-origin basis or globally.

This is to retain web compatibility and work with sticky activation-based user activation-gating.

Minimize Information Disclosure in Error Handling

The vibrate() method returns a boolean to indicate whether the perform vibration operation succeeded. No other information is disclosed. This one bit of information enables applications to implement fallback behaviour as appropriate.

Limit API Usage

Add to Security and privacy considerations:

The use agent should employ global rate limiting to restrict the number of vibration requests made within a certain period (e.g., per minute or hour) to prevent excessive use.

[anssiko]

@simoneonofri @simoneonofri, we discussed your review feedback at TPAC and below is a summary if it.

We hope this response will unblock the security review so that we can move forward to publish a refreshed CR of this specification and continue improve it based on data collected from real-world usage and further reviews. As you may recall, we're here in process of obsoleting the old 2016 Recommendation, to be replaced with a CR Snapshot that reflects the current implementations, to be subsequently iterated on and improved.

Standardize of Max Length and Duration

Based on our discussion and implementation experience, we're planning to recommend a max length of 10 entries and max duration of 10 seconds.

Include Random Vibration

Based on implementation experience, we've learned IPC in modern engines already adds randomness and acts as a mitigation in itself. That said, we could consider adding 0-10 ms at the end of the pattern to further mitigate the issue.

Request User Consent

The group did not reach consensus on this and maintained its position that sticky activation-based user activation-gating is appropriate based on feedback from real-world users. As further background information, this design was an outcome of an iterative development process with with users of the feature.

Minimize Information Disclosure in Error Handling

At most one bit of information is disclosed regardless of the failure mode. No error messages that could disclose information whether the failure is due to a hardware limitation or permission, or some other reason, are surfaced. We believe this is an appropriate mechanism. We will continue to iterate on this design with real-world user feedback, paying attention to the fallback use cases.

Limit API Usage

We're proposing to collect data from real-world users to understand what specific values to use for global rate limit that'd restrict the number of vibration requests made within a certain period. We will propose this in a future update to the specification when we have a large number of samples available to make an informed decision.

[anssiko]

@simoneonofri @KimCerra we're proposing to integrate the following mitigations into the specification: #71 (comment)

Would you give us a go-ahead signal for that?

Edit: PR with the proposed changes: w3c/vibration#46

[anssiko]

@simoneonofri @KimCerra we have now integrated the changes suggested by your review
w3c/vibration#46 after considering refinements discussed at TPAC. We believe this security review is now completed -- feel free to close and label accordingly. We will get in touch with you again as we continue improve this API in its future versions. Thank you for your careful security review!

[himorin]

For record, I keep links to PRs to resolve issues pointed during security review.

We hope this response will unblock the security review so that we can move forward to publish a refreshed CR of this specification and continue improve it based on data collected from real-world usage and further reviews. As you may recall, we're here in process of obsoleting the old 2016 Recommendation, to be replaced with a CR Snapshot that reflects the current implementations, to be subsequently iterated on and improved.

@simoneonofri @KimCerra please check and close this issue if you are fine.

Standardize of Max Length and Duration

Based on our discussion and implementation experience, we're planning to recommend a max length of 10 entries and max duration of 10 seconds.

spec updated by w3c/vibration#46

Include Random Vibration

Based on implementation experience, we've learned IPC in modern engines already adds randomness and acts as a mitigation in itself. That said, we could consider adding 0-10 ms at the end of the pattern to further mitigate the issue.

@anssiko how about to have an issue in vibration API repository for further discussion and its tracking?

Request User Consent

The group did not reach consensus on this and maintained its position that sticky activation-based user activation-gating is appropriate based on feedback from real-world users. As further background information, this design was an outcome of an iterative development process with with users of the feature.

related discussion at w3c/vibration#42, w3c/vibration#10

Minimize Information Disclosure in Error Handling

At most one bit of information is disclosed regardless of the failure mode. No error messages that could disclose information whether the failure is due to a hardware limitation or permission, or some other reason, are surfaced. We believe this is an appropriate mechanism. We will continue to iterate on this design with real-world user feedback, paying attention to the fallback use cases.

(same as above)

Limit API Usage

We're proposing to collect data from real-world users to understand what specific values to use for global rate limit that'd restrict the number of vibration requests made within a certain period. We will propose this in a future update to the specification when we have a large number of samples available to make an informed decision.

@anssiko how about to have an issue also for this?

[simoneonofri]

@simoneonofri @KimCerra we're proposing to integrate the following mitigations into the specification: #71 (comment)

@anssiko we're going to meet today (as the SING just received an FO, we're still working on a totally voluntary effort)

@himorin thank you for the tracking

[simoneonofri]

Dear @anssiko @himorin,

Summarizing the threats and the remediation, and thank you for applying the mitigations:

Mitigation	Status	Notes
Standardize of Max Length and Duration	🟢	related discussion w3c/vibration#46
Include Random Vibration	🟢	related discussion per w3c/vibration#46
Request User Consent	🔴	related discussions per w3c/vibration#42, w3c/vibration#10, cc'ing pes10k as we share the mitigation
Minimize Information Disclosure in Error Handling	🟠	related discussions per w3c/vibration#42, w3c/vibration#10
Limit API Usage	🟠	Waiting feedback

Waiting for the feedback for "Minimize Information Disclosure in Error Handling" and "Limit API Usage", considering the threats/mitigation table, we don't have mitigations for Simulate normal device behaviors (as the mitigation is Request User Consent), so:

• @pes10k, have you some insights on the removal of the privacy-needs-resolution label?
• If the group would like to accept the threat:
  • Insert the Theat in the "Security considerations section" (and maybe in the Privacy one) that the threat it was identified, analyzed, then accepted with the business justification and/or alternative mitigations for the same Threat (e.g., activation-gating?)
  • Monitor the threat for further mitigation possibilities

Thank you,

@KimCerra @simoneonofri

[pes10k]

@simoneonofri i removed the privacy-needs-resolution label because, while i the issues and improvements i mentioned in the privacy review would be useful improvements, I dont think any of them are critical or blocking (wrt privacy)

[simoneonofri]

@pes10k thank you

[anssiko]

@simoneonofri thank you for the summary. I've pushed a PR w3c/vibration#47 to update Privacy and security considerations that expands "Request User Consent" and adds "Limit API Usage" considerations. For "Limit API Usage", I also opened w3c/vibration#48 to collect more data (in a non-blocking manner wrt the publication plan).

@himorin my expectation is that these actions will unblock this review. If you feel we should open additional issues to track some other aspects, feel free to do so. I look forward to the publication.

[simoneonofri]

@anssiko thank you. I was looking at w3c/vibration#47

Considering the latest threat, do you think it is possible to specify better what is said here?

• If the group would like to accept the threat:

  • Insert the Theat in the "Security considerations section" (and maybe in the Privacy one) that the threat it was identified, analyzed, then accepted with the business justification and/or alternative mitigations for the same Threat (e.g., activation-gating?)
  • Monitor the threat for further mitigation possibilities

Also, since I think it might be of value to those reading the specification, it might make sense to structure the security and privacy section by presenting the list of threats in a concise manner (e.g., bulleted list), then the mitigations implemented. If there's the open point of simulating behavior, how do you plan to handle it? as outlined in RFC 3552 or a light version of RFC 6819?

[himorin]

hi @simoneonofri , added security-tracker to the PR, please feel free to switch into -needs-resolution.

Considering the latest threat, do you think it is possible to specify better what is said here?

(I've emailed separatedly, but could you use filed issue/PR for discussion on specific points?)

[anssiko]

@simoneonofri thanks for the RFC 6819 reference. I suggest we discuss the threat model and mitigations structure in a dedicated issue. I'd like the group to consider that topic carefully and in a non-blocking fashion wrt the TR refresh that is imminent.

We've done some prior work in this space in the context of the Generic Sensor API and Compute Pressure API threats and mitigations. Perhaps we can come up with a blueprint on how to structure these considerations informed by relevant RFCs and other resources. Thanks for driving improvements in this area.

[anssiko]

@simoneonofri to unblock the CRS publication, could you please confirm you're satisfied with the proposed approach.

I believe an explicit way to do so would be to close this issue and open dedicated issue(s) in https://github.com/w3c/vibration/issues as suggested by @himorin.

[simoneonofri]

I believe an explicit way to do so would be to close this issue and open dedicated issue(s) in https://github.com/w3c/vibration/issues as suggested by @himorin.

Opened, w3c/vibration#49 let me know if it is clear. Thank you

[anssiko]

@simoneonofri thanks for opening the dedicated issue, it looks good to me.