Thanks for the report. Note that the vibration API is independent of the notifications API.

Vibration in and upon itself is not a security or privacy risk (as the spec itself says) - it must be used in conjunction with other APIs or phishing designs to be effective. The spec does not mandate that we show permission prompts, and we have chosen not to in this case since we have judged that showing a prompt in this case is just as annoying to the user without significantly addressing any potential risks. Any potential indirect privacy risks are outweighed by the general irritation factor of having your device vibrate (or your device demanding permission to vibrate).

Instead, we prefer to address the conjoined items which would be enhanced by vibrate rather than force vibration itself to be a permission. We also have to balance how many options are exposed to users since on Android we have extremely limited UI space to present them.

We are taking other efforts to reduce the impact surface of the vibration API: blocking it in cross-origin iframes (https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/vibrate/blink-dev/7iVcwNcO3xw/WQSkkuk5BQAJ) and ensuring that a page must have been interacted with prior to being able to vibrate (https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/vibrate/blink-dev/QGcpjisxtik/reSqe_HgCgAJ)

The latter issue mentioned will likely resolve most of the annoyance, thank you for pointing it out.

While I understand the concern on the UI-side, I am not sure I agree.  Under "Site settings", you have a scrollable list.  Adding Vibration as another item in that list (or nesting in Notifications) seems pretty reasonable.  There are users like myself that will never want their browser to be able to have Vibration access and I would like the option to disable it entirely regardless of when I have visited a site (intentionally or unintentionally) before.

Tentatively marking as Available, as a feature request for a Vibration toggle in Site Settings. Dom, please WontFix if you think that we shouldn't add that.

For clarity, the question being asked here is whether we should add a non-prompting permission for vibration. This would allow it to be shown in Settings and explicitly disabled by the user, but it wouldn't ever prompt for permission (it would be almost impossible to do that with the current way the API is designed. Vibration is a sync API that returns a boolean based on whether it can or can't vibrate, so we can't block that in order to show a prompt).

I'm not really for or against adding a global toggle, but it wouldn't be a very high priority at the moment. There's a bunch of plumbing involved, plus UX side changes that would require the appropriate reviews. I'm not really convinced it would be used all that often, particularly if interventions manages to address most of the abusive usage of the vibration API.

Starting with Chromium 60, pages will no longer be able to vibrate your device unless you tap on the page first. It used by fake full-screen malware ads before to vibrate the phone. This is a step in the right direction, but I still think the Vibration API should ask the user permission (like camera access).

Looks like it's not possible to give users option to disable Vibration API per-site without the user permission. If the user taps the icon in the URL bar in Chrome on mobile it lists only granted (not all implemented in the browser) permissions for this page (BTW, Chrome on desktop shows all permissions). There is no "Add" button here to add Vibration API to the list and disable it for this page.

Thanks for the feedback. I'll reiterate that the way the vibration API is currently designed makes it impossible to add a prompting permission. navigator.vibrate() is synchronous - it needs to run and return immediately without waiting for anything. That means adding a permission prompt will block all JavaScript execution until the user responds. That's not something we can do.

Absent a permission, adding a setting to control vibrate loses a bunch of its utility (very few users will ever want to go and find it given the current layout of settings). That's why it's a low priority right now - particularly since the user interaction requirement helps prevent spurious vibrations pretty well.