Vibration API 2024-06-28 > 2024-09-20 #71
Comments
anssiko
added
pending
simoneonofri
removed
the
pending
|
we’re working on it with @simoneonofri |
|
Hi @anssiko, we have prepared an initial review. Let us know what you think. Vibration APIScopeEditor: @KimCerra, @simoneonofri Metadata
AbstractThis specification defines an API that provides access to the vibration mechanism of the hosting device. Vibration is a form of tactile feedback. Use casesBetter user experience with tactile feedback, Gaming, and increasing features of PWA when application is on focus. Security and privacy considerationsVibration 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. ReviewSummary
Threats and AttacksFingerprinting 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:
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:
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:
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:
MitigationsStandardize of Max Length and DurationStandardizing 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:
Include Random VibrationIntroduce slight random variations in vibration patterns to obscure device-specific characteristics further, making fingerprinting more difficult. Threats and Attacks:
Request User ConsentPermission 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:
Minimize Information Disclosure in Error HandlingUse 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:
Limit API UsageGlobal: 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:
References |
|
@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 |
|
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. |
|
@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 DurationAdd to Security and privacy considerations:
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 VibrationAdd to Security and privacy considerations:
Request User ConsentWe have the following text in Security and privacy considerations for this consideration:
This is to retain web compatibility and work with sticky activation-based user activation-gating. Minimize Information Disclosure in Error HandlingThe 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 UsageAdd to Security and privacy considerations:
|
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.
|
|
@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.
Based on our discussion and implementation experience, we're planning to recommend a max length of 10 entries and max duration of 10 seconds.
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.
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.
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.
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. |
|
@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 |
Mitigates fingerprinting and tracking vectors that rely on inconsistencies across devices per W3C Security review recommendation: w3c/security-request#71 Note: max duration is expressed in milliseconds.
Mitigates fingerprinting and tracking vectors that rely on inconsistencies across devices per W3C Security review recommendation: w3c/security-request#71 Note: max duration is expressed in milliseconds.
|
@simoneonofri @KimCerra we have now integrated the changes suggested by your review |
|
For record, I keep links to PRs to resolve issues pointed during security review.
@simoneonofri @KimCerra please check and close this issue if you are fine.
spec updated by w3c/vibration#46
@anssiko how about to have an issue in vibration API repository for further discussion and its tracking?
related discussion at w3c/vibration#42, w3c/vibration#10
(same as above)
@anssiko how about to have an issue also for this? |
@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 |
|
Summarizing the threats and the remediation, and thank you for applying the mitigations:
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:
Thank you, |
|
@simoneonofri i removed the |
|
@pes10k thank you |
Expand "Request User Consent" considerations, add "Limit API Usage" considerations and suggested mitigations per W3C Security review feedback: w3c/security-request#71
|
@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. |
|
@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?
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? |
|
hi @simoneonofri , added security-tracker to the PR, please feel free to switch into -needs-resolution.
(I've emailed separatedly, but could you use filed issue/PR for discussion on specific points?) |
Update "Request User Consent" considerations, add "Limit API Usage" considerations and suggested mitigations per W3C Security review feedback: w3c/security-request#71
|
@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. |
|
@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. |
Opened, w3c/vibration#49 let me know if it is clear. Thank you |
|
@simoneonofri thanks for opening the dedicated issue, it looks good to me. |
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.
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!
The text was updated successfully, but these errors were encountered: