Vibration should require user's permission

[andrey-logvinov]

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.

[anssiko]

The Notifications API permission model does not special case vibration. The same "granted" permission is required for all notifications regardless of the use of vibration.

[andrey-logvinov]

This is correct, but to vibrate the device through notification, notification permission is still required. On the other hand, to vibrate the device via Vibration API, no permission is required at all. This does cause some concern, e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=507703

The specification already contains provision that UA should inform the user when the Vibration API is being used and allow to disable vibration on per-origin basis or globally, but does not specify the mechanism for informing the user and disabling the vibration. I suggest considering explicitly specifying a permission for use with Vibration API, because permission requests both inform the user that a certain feature is going to be used and allow to disable the use of the feature on per-origin basis.

[anssiko]

Agreed to defer to v2 on today's call.

[lknik]

We also could actually give a MUST in the privacy considerations (i.e. ask for permissions). Or just stipulate this is subject to permissions. For v2.

[andrey-logvinov]

A MUST will invalidate at least the current Chromium implementation which neither informs the user nor provides a mechanism to disable vibration. So this is no really different from adding a permission in regard of existing implementations validity, which is the reason this issue is deferred to v2.

[anssiko]

Correct. The consensus was to defer this feature to v2, and publish a Proposed Edited Recommendation (PER) that reflects the current implementations (aka reality), after integrating the editorial change #7.