Re: Malicious Use of the HTML5 Vibrate API

I added a comment there as well. I think in Chrome for Android we now have
a pretty solid set of constraints on this API. It's basically about page
visibility. This expresses itself in many easy to use and natural ways.

Vibration will stop when the user:
* Navigates away
* Reloads the page
* Switches to a different tab
* Closes the tab
* Sends the browser to background
* Turns the screen off

It should also not start at all if vibration is turned off for the phone as
a whole i.e. it's on silent.

There are also limits to how long the device will vibrate.

Try it out here:

Also, if the user doesn't like the page, he can close it and not go there
again. It is the most basic way of user control in a browser, and proven to
be quite effective. If it turns out that this feature really does get
abused a lot, like browser popups did, then we'll have more data. This
would give better insight into how to counter the abuse without degrading
the user experience for valid usage.

Let's not cripple new APIs too much before we have seen real abuse. I think
info bars, permission dialogs, etc are quite invasive. Such measures scare
developers away from using the feature, they're afraid to ask the user for
permission in case the user gets scared or annoyed by it.



On Mon, Jan 20, 2014 at 1:30 PM, Kostiainen, Anssi <> wrote:

> On 17 Jan 2014, at 22:38, Lisa Seacat DeLuca <> wrote:
> > Has everyone seen this?
> >
> >
> Thanks for the pointer. Do you think there is something we could do
> specification-wise?
> The spec is already clear on that regular web pages that are invisible
> cannot vibrate the device.
> Also, the user consent mechanism to use (or not to use) is left to the
> implementation. In this specific case, I think the "ask forgiveness”
> approach used in the Fullscreen API might work pretty well to mitigate the
> attack:
> I’m planning to do an update to the spec soonish to close my open actions,
> so if there are suggestions e.g. to the non-normative sections to improve
> feel free to propose suggestions.
> Generally I echo Dom’s comments (in the blog post) that the same issues
> apply to many new capabilities added to the platform that allow regular web
> content to behave more like native apps, use new capabilities traditionally
> available to native apps only.
> Thanks,
> -Anssi

Received on Monday, 20 January 2014 15:21:26 UTC