The user must be able to disable use of the Vibration API

[matatk]

The Security and privacy considerations section states:

For these reasons, the user agent MAY 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.

APA WG previously reviewed this API and made a comment that users SHOULD be able to disable use of the API. We've reviewed the latest version, and feel that things have changed such that this requirement ought to be a (RFC 2119) MUST now. Here are the key reasons:

• More apps could be using vibration as a means to send signals to the user via notifications, as well as the OS. There are also many frequent sources of notifications these days. There is scope for the user to be confused as to which app (or part of the OS) is sending the notification.

• Some users may find the haptic feedback too intense. Notifications could be jarring for them, and games (where the vibrations may happen very often) could be difficult for them to interact with, due to the frequent haptic feedback.

[anssiko]

@matatk and APA WG, thank you for your re-review. The context and rationale for the recent change in this RFC 2119 term is in #47 (review)

The group's plan is to imminently publish a new CRS that matches current implementations and to continue evolve the specification with special consideration for issues -- including this one -- that suggest changes to existing implementations and thus may impact web compatibility.

The group is aware of an early experimental implementation in Firefox that showed a UI to the user to allow disable the API. We want to gather more implementation experience on this. The past design discussions around this feature are documented in 2.11 of #36 to inform the work.

The group would like to explicitly confirm with you that APA WG is supportive of this approach so that we can proceed with the CRS publication. Thank you!

[matatk]

Hi @anssiko; yes; APA WG is happy with your proposed approach. We look forward to following up with you after the CRS is published.

P.S. I realise that adding the 'needs resolution' label might have been confusing until after the CRS is published; apologies for that.