Martin: I don't like this API....

we put on for next week

[mt] Initial thoughts after reviewing the specification... There are a few problems that seem fairly evident to me:

1. The specification relies on sticky activation, which is true if the user has ever interacted with a page. That makes this less about interactive feedback (as you might get with a gamepad) and more like a notification. That is more the case when you consider that there is nothing preventing a background window/tab from engaging the API. If the intent of the API is to act like a notification, then the notification API is more appropriate. Requiring transient activation would seem to be more in line with expectations and be less likely to annoy. If the goal is to enable notifications, which seems to be one of the main use cases, then adding vibration capabilities to the notifications API might be better.

2. The privacy/security considerations don't consider annoyance as a major factor. This was part of why this was disabled. That might be partly mitigated by a transient activation requirement, which puts vibration much closer to playing audio. That seems like a good fit to me. Browsers have a bunch of ways of managing annoyance from unwanted noises. Reusing those techniques for vibration might make it less objectionable overall.

3. If activating vibration is observable cross-origin, perhaps the right thing to do is suppress things like accelerometer events for the duration of a shake.

4. I seem to recall that gamepads have different vibration strengths and frequencies. Why is this not a consideration here?

Martin: the primary privacy concern is annoyance. It's not too dissimilar from sound being annoying. If we were able to have a similar sort of approach to playing of sounds then that would be fine. Sounds relies with activation. I don't think that's appropriate for vibration.

Dan: what's the current spec say about permission requests?

Martin: current spec says nothing. It says the UA should inform the user when it's being used. I think that's garbage.

Dan: I kind of agree. Vibrations are interruptive.

Martin: notifications - have a notifications API. If you want to provide haptic feedback like in a form, then activation is appropriate. I would turn the feature off, but...

Yves: I think it's restricted to when screen is on.

Martin: ah... it's only available for foreground...

Dan: it should only be the active tab...

Martin: yes - it's only if it's in the foreground and visible.

Dan: then "activation" seems sufficient.

Martin: transient or sticky... Sticky is if you interact with the web site it stays ... you've interacted. Transient is .. you've touched the screen or hit a key and it's active for some short period of time.

discussion of transient vs. sticky

Martin: currently specified as sticky...

Dan: let's ask them to justify that...

Matthew: do UAs that support this offer an option to disable it?

Martin: no idea.. only implementation is chrome... Spec says "SHOULD" provide a mechanism to disable...

Matthew: every OS has a volume control on it... but maybe not similar controls for a vibration...

Martin: privacy principle on abusive behaviour... or notifications and interruptions

Martin: if you vibrate a device and another webpage has access to the accelerometer it can send coded messages. Require that the browser turns off the accelerometer while activiting vibration. I believe it's a physical requirement anyway.

Martin: satisfied with concerns?

Matthew: how strongly do we feel about sticky and turning it off?

Martin: it's a MUST. But does it make the whole api a bad idea?

Matthew: if our concerns were addressed we'd be satisfied. Then I agree.

Max: use case with two browsers active at the same time - and both use the api - what happens since the hardware only has one device? Does the API consider this situation? What's the user experience?

Martin: if you have two visible tabs on the device, if one requests vibration and the other one requests, it should just vibrate as much as both of them combined, the union of the two. I don't think that's necessarily problematic. If the patterns interact it'll just be solid vibration..

<blockquote> We're concerned about the abuse of this API to divert attention in inappropriate situations. We note that you're specifying sticky activation. Are there use cases that support this - rather than transient activation?

For the difference in activation types, we think that sticky activation might not be a good justification for the notification-style use case. If someone isn't engaging with the site, having it vibrate could be annoying. If the goal is to generate a notification, the notification API seems like a much better fit for that. At least with notifications, people are in control of how they are notified (sound, visual, vibration, or combinations).

There is a good analogy between this and audio, in that both might be engaged in a similar way and disabled with similar controls. However, have you considered adding a stronger normative requirement that UAs should be able to turn it off? It's not as easy to turn off a vibration with physical controls as it is with sound.

Security/privacy considerations don't treat annoyance as a problem. Interruptions is a privacy issue you should consider addressing. We like that the vibrations only activate when the page is visible, but that seems like something that should be directly addressed as a mitigation for that issue.

Security considerations should require that accelerometers and gyroscopes are disabled for other origins when vibrating.

</blockquote>