Vibrating devices are a familiar thing. From the era of flip-phones, to vibrations induced by mobile apps. Or websites.

[Edit 15/11/19: Firefox is limiting access to Vibration API]

Vibration API

The mechanism allowing websites to utilize device's vibration motor is called Vibration API. The mechanism allows a device to be vibrated in particular patterns. The argument to the vibration() function is a list called a pattern. The list’s odd indices cause a vibration for a specific length of time, and even values are the still periods. For example, a web designer can make the device to vibrate for a specific duration, say 50 ms and follow that with a still period of 100 ms using the following call:

navigator.vibration([50,100])

In certain circumstances this can create several interesting potential privacy risks. Let’s look at the Vibration API from a privacy point of view. I will consider a number of scenarios on various technical levels.

Privacy analysis of Vibration API

When making Web standards, multiple scenarios possibly affecting privacy are considered. This includes even the very potential ones; and this is a good thing. It's best to predict the creative use and abuse of web features, before they go wild.

Toy de-anonymisation scenario

One potential risk is the identification of a particular person in real life. Imagine several people in the same room placing their devices on a table. At some point, one person’s device vibrates in specific patterns. This individual might then become marked to a potential observer.

How could such a script be delivered? One possibility is though web advertising infrastructures. These offer capabilities of targeting individuals with a considerable accuracy (with respect to their location).

Generally speaking, causing a device to vibrate only offers a capability of writing: communicating out. Privacy-invasive techniques often require capabilities to read: communicating in and interpreting messages.

Communication channel

The ability to cause vibration patterns may be used to create an out-of-band communication channel, not necessarily limited to the web – accessible also in the outside world. This can be as simple as causing the device to vibrate in a way resembling Morse code, while making another device listen to external audio signals and pick up messages. Such a technique could even allow the creation of a cross-device link – potentially tracking the user across devices. Such a technique is actually being used – although exploiting ultrasound , rather than vibration, for efficiency reasons.

Vibration API abuse in wild

Interestingly, it appears that the creativity of online ads or malicious popups trying to trick the users to do something unwise resulted in some of the web ads actually abusing vibrations and irritating users.
This is one of the reasons there are some restrictions on the use of the API.

Vibration and fingerprinting

Mobile devices can be fingerprinted and analyzed using various sensors, typically motion sensors such as accelerometers or gyroscopes. In many cases, causing the device to vibrate helps in fingerprinting. So far, most of the related privacy research used external vibrating motors for demonstration purposes. While this makes the analysis in a controlled (laboratory) environment easier, the actual threat in the real world might be unclear. In this sense, the Vibration API could possibly be used as a viable tool to “excite” some components and allow a fingerprint to be measured.

Privacy analysis of Vibration API

Now let's consider Vibration API from a very strict privacy engineering perspective. I will use the W3C standard directly.

Among the interesting aspects of Vibration API are the following parameters

• max length, the size of pattern list - argument to vibration method - is limited. On modern browsers this is set to 128. One of the rationales behind this limitation is to avoid a potential user inconvenience caused by a malicious script making a perpetual vibration pattern and degrading the user's browsing experience
• max duration, This parameter limits the maximum vibration period. On modern browsers, this is set to 10 seconds (10,000 ms).

This means that navigator.vibration([20000]) will make the device to vibrate for only 10 seconds, and if the pattern contains more than 128 items, only 128 will be actually used. This knowledge can be used in interesting ways, knowing that modern browsers have the capability to detect when a vibration takes place.

Recovering max length

One privacy attack is the recovery of max length setting. It can be done simply by listening to DeviceOrientation events, creating lists of patterns of increasing sizes and analyzing the resulting vibrations.

An example algorithm monitors DeviceOrientation events and causes a single vibration, increasing the duration while tracking the time when device is vibrating. At some point, the time would stop increasing, indicating the platform's max duration.

This is mostly hypothetical, because both max length and max duration do not vary between the current implementations of the API (Chrome, Firefox). Abuse is therefore unlikely, unless the user changes them to a custom value. But this can have significance if, for some reason, browsers or Internet of Things devices start to use different values of those parameters, for whatever reason.

Max duration recovery demo

I have set up an example page demonstrating the basic idea of max duration parameter recovery.

The demonstration is a proof of principle and it has some limitations. For example, it shows approximate values; it works best with a device placed on a flat surface; it was tested only under Chrome (mobile) browser, etc. The example simple demonstration yields approximate values but could be easily optimized, for example by inspecting the nature of vibrations and mobile browser.

The plot below shows an example measurement of vibrating for a simulated length max duration set to 500 ms, in the testing environment. First, the length of a vibration is far from the actual setting. After some time, the actual readout stabilizes. In a similar fashion, it could be possible to measure any max duration length

Summary

Even such supposedly innocuous mechanisms like vibration can bring unexpected consequences to web privacy.
Making web standards correct from a privacy perspective is important. It is my privilege to be able to directly contribute to this effort when working on sensor privacy.

Implementers, be that of browsers or Internet of Things devices, may want to keep in mind that vibration is a potential privacy risk.