w3c / vibration

Vibration API

Vibration API

This repository contains the Vibration API specification.

vibration's Issues

Updating privacy considerations to reflect recomentations.

I think we should consider updating the considerations to reflect some of the discussions on the lists (including PING), to specify more direct recommendations (including, more directly, this one https://lists.w3.org/Archives/Public/public-device-apis/2016Feb/0072.html_. Can we go with the following?

Vibration API is not a source of data on its own and as such is not producing any data 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 device that is vibrating might be visible to external observers and enable physical identification, and possibly tracking of the user.

For these reasons, the user agent SHOULD inform about the past and present use of the API. Additionally, the user agent MUST allow a mechanism of limiting the the potential of using the API to create vibration patterns.

Updating privacy considerations - recovery of two identifiers

Hello,

After carefully analyzing the spec, it seems it could be possible to actually recover the max patterns list and max duration length values. While at this moment there is no actual apparent risk since the current implementers appear to limit the max pattern length to 128 and max duration to 10 seconds, it is not clear what could be implementing the spec in the future.

For example, an algorithm monitors DeviceOrientation events and causes a single vibration, increasing the duration while tracking the time when device is vibrating. At some point, the time would stop to ascend, indicating the platform's max duration. This is an identifier.

We could update the privacy considerations to reflect this, i.e.

"It is theoretically possible to recover the values of max length and max duration using external detection sensors. In some scenarios, those values could act as identifiers."

Once again, this concerns a situation where in some case, e.g. Web of Things devices, those values would start to be different. In any case, this would make the spec future proof.

ISSUE-146: Add vibration strength control

Any ETA/status for my proposed "Add vibration strength control" https://www.w3.org/2009/dap/track/issues/146 ?

Maybe iOS now supports vibration strength control, or needed to open issue/proposal for Apple. Anyway after standard is proposed, vendors must/expected to fallow it. I think standards proposal must be made before vendors began its own implementation in non-standard way.

---

Vibration API strength proposal with stair-stepping/smooth volume
reduce/increase:

navigator.vibrate([
    {
        "time": 200, // Required property.
        "volume": [0, 80] // Minimum 0, maximum 100, default 100. [0, 80] smooth volume increase - starts volume strength at 0 and smoothly increases to 80 till end.
    },
    {
        "time": 1000, // 1000 ms
        "delay": 50, // Will start vibrate after 50 ms. Default 0 ms
        "volume": [0, 100, 0] // Smooth volume reduce-increase-reduce - starts at 0, smoothly increases to 100 in 50 ms and smooth reduce to 0 at end.
    },
    {
        "time": 200,
        "volume": [50] // Stair-stepping volume - will start and end volume strength 50.
    }
]);

or the same in simplified version without keys:

navigator.vibrate([{200, [0, 80]}, {1000, 50, [0, 100, 0]}, {200, [50]}]);

and single 1s vibrate with full strength and without delay:

navigator.vibrate({1000});

shouldn't the title be "Vibration API (Second Edition)"?

i am trying to track the W3C TR space and it seems that usually, editions are made identifiable so that it's possible to refer to both the stable published REC and the updated version. https://www.w3.org/TR/webstorage/ would be one such example.

Privacy considerations

Vibration can be used in conjunction with other techniques to enhance fingerprinting.

Vibration is also often externally visible, so causing a device to vibrate can be used by a third party able to observe locally to identify the device in question.

api.Navigator.vibrate - Throwing intervention error of vibration after user already interacted with UI.

Google Chrome Version 87.0.4280.88 (Official Build) (x86_64)

What information was incorrect, unhelpful, or incomplete?

Missing one Vibration API to check whether developer can trigger vibration or not.

What did you expect to see?

Allow me to trigger vibration when user interact with UI elements.

Did you test this? If so, how?

I tried to trigger vibration after element clicked (click and on hold), and trigger event in touchmove, but if finger still on hold, vibrate API will still assume user not yet interact, and throw error below.

[Intervention] Blocked call to navigator.vibrate because user hasn't tapped on the frame or any embedded frame yet: .

MDN page report details

• Query: api.Navigator.vibrate
• MDN URL: https://developer.mozilla.org/en-US/docs/Web/API/Vibration_API
• Report started: 2020-12-24T05:50:02.542Z

Block navigator.vibrate in cross-origin iframes

Chrome is blocking the vibration API in cross-origin iframes.

The current spec allows for that behaviour, but if that's the one other browsers are converging toward, we should probably make it the explicitly required behaviour.

Require user activation for navigator.vibrate

This was previously discussed in WICG/interventions#47. It looks like Chrome shipped this restriction, see https://chromestatus.com/feature/5644273861001216. I think it makes sense to make this change in the spec as well.

Change WebIDL ref to WebIDL-1

We currently refer to /TR/WebIDL/ ; I think while we are at updating the spec, we should reference /TR/WebIDL-1/

Use visibilityState rather than hidden

The Page Visibility API documents hidden as deprecated in favour of visibilityState — it would make sense for the Vibration API to refer to the visibilityState algorithm instead of the hidden state algorithm.

(noted by @plehegar )

Accessible Platform Architectures WG feedback

On 2016-10-06 DASWG call agreed to address this in v2:

https://lists.w3.org/Archives/Public/public-device-apis/2016Sep/0024.html

Vibration should require user's permission

It looks like an omission that Notifications API requires user's permission to issue notifications which also include vibration patterns, but the Vibration API doesn't require any sort of permission. There is a provision in the "Security and privacy considerations" section that UA should provide mechanism for disabling the API but there is already a standard mechanism for that purpose, the Permissions API. I suggest adding explicit user permission requirement instead of the general provision of an unspecified disabling mechanism.

Vibration does not work in silent mode.

Vibration does not work when the mobile device settings are silent mode. Did you intent? If so, this seems to be stated together in the document.

Or do not you have a way to vibrate when it is silent mode?