When making web standards, multiple scenarios possibly affecting privacy are considered. This includes even extreme ones; and this is a good thing. It’s best to predict the creative use and abuse of web features, before they are exploited.
Vibration API
The mechanism allowing websites to utilize a device’s vibration motor is called the 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.
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 the 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 advertisers trying to trick the users to do something unwise resulted in some web advertisements 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 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 the Vibration API from a very strict privacy engineering perspective. I will use the W3C standard directly.
Among the interesting aspects of the Vibration API are the following parameters
- max length
- The size of the pattern argument to the 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 the max length parameter. 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 concept 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 the Chrome browser, etc. The 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 max duration set to 500 ms, in a testing environment. Initially, the length of a vibration is far from the actual setting. After some time, the actual readout stabilizes. In a similar fashion, it may 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.
This post originally appeared on Security, Privacy & Tech Inquiries, the blog of Lukasz Olejnik.