Malicious Use of the HTML5 Vibrate API
shkspr.mobi
shkspr.mobi
Uhm, if your argument against a HTML5 API is "it's possible that the browser is hackable" then I don't see the discussion going very far. Like, you can use the same argument against HTTP support.
Combine it with a WebRTC call and you're looking at a very convincing scam.
WebRTC does require explicit user permissions.
I honestly don't see how the buzzing is in anyway crucial in in the explained examples. You can mimic real UI and trick users. This has been around on desktop for ages with fake Windows dialogs. Take away the buzz in the example on the webpage and the majority of people will still "pick up the phone".
It's certainly not "crucial" - but it's a lot easier to trick someone by exploiting their brain's heuristics.
Phone vibrating means alert. I think that could be enough to trick people into overlooking elements like the title bar being visible, etc.
For example, I've noticed that some dodgy web adverts play the default Windows Error.wav when displaying a fake "Your codecs need updating" error dialogue. Not crucial, but adds credence.
I agree that the browser hacking is unlikely and probably shouldn't be mentioned.
It's not that it's unlikely, it's just irrelevant. "We might accidentally introduce a security flaw" could be used as an argument against building absolutely anything.
> Autoplaying sound on adverts in annoying - auto-vibration could be just as irritating.
Sound can be mutated. I don’t know how difficult could be to turn off the vibration.
Of course, HTML-based ones can reach a larger number of users with little investment, so it's reasonable to expect this will occur more frequently in the future.
There's a great app for Android (in Sweden, I suppose there are similar apps for other countries) that searches digital phone registries on an incoming call and after about a second displays whatever data it has found on the incoming call screen (such as Telemarketing Company, Salesperson, etc) It also uses some form of rating system so if enough users have flagged a number, it will warn me about it. This has saved me countless of calls.
I suspect malware works the same. It costs little to deploy, so even if 1 in 10,000 people are fooled, it can be lucrative.
Some APIs are allowed by default and some aren't. For the discussion about Vibration, see: https://wiki.mozilla.org/WebAPI/Security/Vibration
Personally I don't see this as a big problem at all.
Neither Vibrate nor WebAudio require permissions from the webpage. Like basic JavaScript they always run. They're not security/privacy risks per se, just something that, like so many other things, could be used to support a phishing attack.
I'm already seeing this really bad trend of ads redirecting to the app store which makes the page that did it completely unreadable (going back to safari shows an empty page) and now there's the prospect of the phone vibrating to the blinking of the various ads wanting my attention?
If this goes on like this, I'll really need an adblocker on my phone.
The audio was a surprise, since it runs my HTML5 radio software just fine. I'm guessing the demo used OGG or some other audio format not supported by mobile IE.
The demo uses MP3.
Firefox was the last holdout, and they capitulated last year [1]; FF for XP and up and FF for Mac now support MP3. There are very few practical reasons not to use MP3.
[1]: http://stackoverflow.com/questions/4923136/why-doesnt-firefo...
MP3 has native HTML5 audio support on web browsers (Chrome, FF, IE, Safari) for Windows XP and up, modern Macs, and any modern Droid, iOS, or Windows Phone sold in the last 5 years.
It makes MP3 the broadest supported format out there.
Are there not restrictions at the OS or hardware level to prevent this?
FWIW I liked this article. But one thing to note is that -- at least in Firefox/Firefox OS -- a page/app can only vibrate the phone if it's "visible". In the browser, a page is visible if it's in the topmost tab, if the browser app is the currently-focused app, and if the screen is not locked/off.
At least, that's how it's supposed to work. :)
Sure you could install a skype ap, but this opens the way to companies running a private, webapp based voip system. In much the same way as they might use Jabber now. All we need now is a decent opensource desktop voip ap to pair it with.
But all of them will pop up the permission prompt.
The vibrator motors used in phones are not that fragile and vibrate being stuck on will more likely just annoy you and drain the battery faster than usual -- that is, until you get annoyed enough to pull it out.
(Maybe annoy you, as a quick search shows plenty of people who want their phone to vibrate continuously... for whatever reason.)
The only way this could be workable is if there were something like an HTML meta tag for requesting vibrate support for scripts running from your domain, and that would prompt a one-time dialog to white-list that domain for vibrate support in JS.
However they don't have much to do with the introduction of the vibrate API. What this assumes is that the phone vibration is something the user should or could generally rely on to distinguish between genuine system functions and fakes. That's just not true for many reasons.
That's the limitation I noticed anyway when I had a quick go at an audio web app a year ago. I couldn't get sounds to play on load without first a tap from user - this was on iOS Safari anyway, I didn't test on other browsers.
But, that said, there's nothing to stop you adding an onClick() event to any part of your page which will then play the audio.
It's a limitation that makes it quite annoying to build HTML5 audio apps, which is what my startup does. I have several hacks in my code to accomodate iOS's crippled HTML5 audio implementation.
Often these forgotten platforms have the most issues with attackers/exploiters. There was just an article on here the other day about the wave of Windows XP exploits we are bound to see now that it no longer gets patched.
[However we get less annoying ads because safari don't play flash. Advertisers are obviously moving to different kind of ads adapted to mobile. Anyway it's reasonable to dread for the time that they'll catch up with the desktop ones.]
I don't know how exact those motors are, but I could imagine it is possible that even 2-3s of vibration could easily transmit a password.
oh wait...