Malicious Use of the HTML5 Vibrate API

There is a new API in town! HTML5 will (soon) let you make the user's device vibrate. What fun! Obviously, it's useful for triggering alerts, improved immersivness during gameplay, and all sorts of other fun things like sending Morse Code messages via vibration.

At the moment, Chrome (and other Android browsers) ask for permission before accessing features such as geo-location, camera, address book etc. This is a security measure to prevent your private information leaving your hands without your knowledge.

At the moment, accessing the HTML5 Vibrate API doesn't trigger an on-screen warning. Its use is seen as pretty innocuous. Because, realistically, the worst it can do is prematurely drain your battery. Right?

I'm not so sure.

Evil Thoughts

We've all seen those scummy adverts designed to look like Windows pop-ups. They usually pose as a legitimate system request - "Update Java" or similar.

Suppose a malicious web page pops up a fake system notification and vibrates at the same time. How confident would you be of telling the difference between a legitimate pop-up and a .png on the web page you're viewing. After all, the phone buzzed - so it must be genuine.

Fake Airdrop
Are you really receiving an "AirDrop" - or is this page trying to trick you?

Autoplaying sound on adverts in annoying - auto-vibration could be just as irritating. Imagine searching through tabs until you found the single advert which was pulsing away trying to get you to buy new insurance.

For now, the intensity of the vibration cannot be controlled - only the duration. It is not impossible to conceive of malicious code being able to exploit an unpatched browser flaw and overdrive the motor to destruction.

Faking Telephone Calls

When combined with HTML5 Audio, it would be possible to create a fairly realistic "Incoming Call" screen which vibrated and played a ringtone. Once "answered", the page could play some audio which says "Hi, can you call me back urgently - my number is [premium rate line]" and then, perhaps, automatically open up the dialer using the tel: URI.
Phone call in browser scam
Could you tell if the above was a real phone call? If you looked closely, probably, but when the browser is playing your phone's default ringtone and the handset is vibrating, it would be pretty easy to be confused. Combine it with a WebRTC call and you're looking at a very convincing scam.

Video Demo

Source Code

Here's a basic example which you can try on your own phone - demo site.

  1. <body>
  2.  <script type="text/javascript">
  3.   navigator.vibrate = navigator.vibrate ||
  4.        navigator.webkitVibrate ||
  5.        navigator.mozVibrate ||
  6.        navigator.msVibrate;
  8.   navigator.vibrate([1000, 500, 1000, 500, 1000, 500, 1000, 500, 1000, 500, 1000, 500, 1000, 500]);
  9.  </script>
  10.  <img width="100%" src="phone.png" onclick="window.location.href='tel:09098790815';" />
  11.  <audio autoplay="autoplay">  
  12.   <source src="ring.mp3" />  
  13.  </audio>
  14. </body>

At the moment, the auto-vibrate and auto-ring only work on Firefox for Android. But no doubt other browsers will follow suite soon.


Firefox was the only browser I found which supported Vibrate - on Android, neither Samsung's browser, Chrome, or Opera did - iPhone also doesn't yet support it. No one cares about Windows Phone or BlackBerry - so I didn't test them*.

Firefox doesn't currently ask for permission when a page requests access to vibrate.

Do you think browsers should warn before a page vibrates - or is the risk too low? I guess we'll have to see if the scammers take advantage of it - and whether there is a user backlash.

*Update: thanks to the comments on Reddit and on HackerNews it would appear that BB10 does support the vibrate API, Windows Phone doesn't.


A picture of Dominique Hazael-Massieux Dominique Hazael-Massieux

(disclaimer: I'm involved in the W3C group that is developing the vibration API)

Re "Imagine searching through tabs until you found the single advert which was pulsing away trying to get you to buy new insurance.", the vibration API spec is pretty clear that you should only vibrate from a visible Web page. And I expect that if vibration proves to be used annoyingly, browsers may end up providing easy way to mute "web sites", or even handle them as they have handled pop ups.

Re unpatched browser flaw destroying the motor, it would also have to be on an OS that doesn't prevent applications to do so; and if one starts from a flawed browser, then no permission grant in the world would change anything to the problem (because you could then also assume that that permission grant could be buggy).

While vibration may add credibility to your (clever) pseudo-call attack, arguably the audio and visual aspects are sufficient to make it convincing on its own. I think the real attack vector here is that calling an innocuous looking number can cost you money.

I guess the case can be made that users don't expect Web pages to have certain capabilities, and the surprise this creates can be exploited maliciously; but that's probably true of any new capability, and unless we want to gate any such new capability behind a browser prompt, this is probably unavoidable.

See also some of my recent research on browser permission management:

A picture of Terence Eden Terence Eden

Hey Dom,

Thanks for your comment. I agree that some scenarios are unlikely. Its real danger, as you've identified, is that unexpected behaviour can lend credence to an otherwise obvious attack. For example, if you take a look at this fake "Android virus alert" - how much more convincing would it be if the phone vibrated with its "alert"?

It will be interesting to see how this develops - and I look forward to reading more about the permissions model.


A picture of Michael van Ouwerkerk Michael van Ouwerkerk

I worked on this feature for Chrome on Android, and this is our current approach. 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.

A picture of chris heilmann chris heilmann

Well, all it proves that you can fake an interface. The call still has to be initiated by you. Makes it look scary but also is not the normal way you would have an incoming call act on the OS. It is Phishing, plain and simple. Also, you need to match my dialtone that I set, and as you can not read that one it'll be weird to hear another one.

A picture of Terence Eden Terence Eden

True - but I wonder how many people change their default ringtone. Whenever I hear an iPhone ring, I see several people reaching for their pockets!

You're right that the call has to be initiated - but it could just as easily be a premium rate SMS, or a prompt to install some malware, etc.

A picture of chris heilmann chris heilmann

All of which have the same issue. A sms:// domain still needs the user to install it. A prompt to install software will very much tell you what that software wants to access and to do and apps that reach data or functionality of your phone that is sensitive (at least in FxOS) need to be hosted on the marketplace and get a security review. Normal web sites are not allowed to access everything .
I very much agree that vibration allows you to get the user's attention much better than without it, but I am not sure about the credibility aspect of it. In essence this is like a fake browser toolbar and a ping sound - or a desktop notification like Chrome has with a ping sound.

My fave fake interface lately was this:

A picture of Terence Eden Terence Eden

Again, I don't disagree with you. This is purely about about shortcutting the user's expectations. It still requires interaction. Those fake toolbars, I'm sure, get more clicks when they play "Windows Error.wav" than when they don't.

A picture of Terence Eden Terence Eden

Ah, that's a hangover from when I was trying to get a different piece of audio to play when you "answered" the phone. Something like "Call me back urgently - I'm sending my number to your phone."

A picture of joe joe

Yes, permission should be required for both vibrate and simple sound. The fact that we haven't had this has led to auto-playing videos disrupting the user unnecessarily. There is no question that both should be controlled by the user.

A picture of Hellman Holst Hellman Holst

Combined this with WebRTC and the whole world of e-Dildonics is opened wide for you to exploit for fun or profit or both.

A picture of Terence Eden Terence Eden

That doesn't stop a malicious actor binding the event to an innocuous touch action. For example, add it to a scroll down event, add a 10 second delay before vibrating / playing. How would you know what caused it?

A picture of akismet-76a258d7a4a518ae4001f0beb83012e6 akismet-76a258d7a4a518ae4001f0beb83012e6

Of course, it doesn't stop a malicious someone from doing evil things, it just makes his work more complicated (find a way to induce the user to touch the interface first and not just binding to the onload event). And that's why, in my opinion, it would still prevent most users from these unsolicited spams behaviours.

After all, can you really stop someone malicious from doing malicious things ? I don't think the "ask for permission popup" model would offer us a better guaranty...


Leave a Reply