When we browse the Web, any Web site can tap into our pointing or typing device by specific JavaScript calls (such as setting of document.onmousemove, or including a specific listener). During the session, JS code provides information about any change (e.g. slight mouse move), with the current pixel position of a pointer. This information can be used to enhance the look and feel of the site, but it is also increasingly used to monitor the activity of Web users.

HTML5 included a large number of APIs, e.g. for query of geolocation data, webcam and microphones. Browser vendors acknowledged the obvious sensitive nature of these sources. Browsers now include a permission model which can guard access to those APIs. Whenever a Web site tries to use a guarded API, the user is asked for a permission. While the current permission model has some drawbacks, it generally protects the users from unauthorized access to the sources while visiting a Web site. The risks with geolocation, audio and video data are easy to imagine.

Moreover, the new HTML5 functionality is well integrated with browsers. Namely, the browser privacy user interface (privacy UI) of some browsers (such as Chrome, Firefox quickly catching up) allows the user to always be aware if a sensitive API such as geolocation or webcam is in use.

That said, the permissions model introduced a puzzling dichotomy.

After introducing the permissions, a mixed model of protections exists, where certain sensors are protected, while others are not. For example, keypress and mouse movements APIs are not protected by this API. Any Web site can access this data to collect, store, and retrieve keytyping or mouse movements. Moreover, no browser indicates that Web tracking takes place. The inconsistency in both browser permissions model and browser privacy UI is easy to observe.

However, are there any risks related to mouse movements tracking? Turns out this is the case.

Mouse tracking introduces several not-so-obvious privacy problems. The information on it is largely scattered, but we provide examples of systematized knowledge here.

• Tracking users. In the recent years, there has been a tremendous improvement in mouse-based biometric systems. A biometric system extracts features of the user's mouse movement patterns and then it is able to recognize this user via these traits. One example of a system with high accuracy is this one (~1% error rate). It will thus likely be possible to fingerprint the users - and track them - using mouse data.
• Mouse movements leak the user's age. There is a body of scientific data which proves that mouse movements reveal the age of its user. Example here, demonstration covered here. Age is a direct private information.
• Eye tracking. Mouse tracking can allow the tracking of eyes (link). It can reveal in which page regions the users are interested in. It can therefore infer the user preferences

The risks are therefore of a complex nature. However, the browsers do not attempt to take any precautions. The one problem we are facing is that this problem may grow with time. The main objective of our work is to start a discussion in the community about the possible future threats of mouse movement tracking risks. We propose to take this risk seriously and respond before it happens, rather than wait. We are well aware of the notorious CSS history leak (link1, link2), specifically that it required more than 10 years to have it fixed.

We purposefully draw a direct parallel here.

Does mouse tracking happen on the Web? Yes! Recently, infrastructures for cross-site mouse tracking were introduced by the so called mouse analytics. Those are systems enabling the tracking of mouse movements to later allow the study the Web site use patterns by site owners, with an aim of potentially improving the site's layout. In our work we analyzed these entities, and while we did not encounter any proofs of taking advantage of the mouse movements potential described in the previous paragraph (for example, fingerprinting), the infrastructures for mouse movements collections are in place. Moreover, many existing 3rd-party JavaScript scripts could introduce this functionality in the future. For example, Facebook might start to be interested in mouse movements.

The fix of this problem seems straight-forward: guard the old-style sensors using the already-present permission system. Moreover, clearly show to the user when such tracking is taking place. This will not only fix the rather obvious inconsistency in the browser permission model, but also improve the transparency

We acknowledge that blocking the JavaScript mouse API will still enable Web sites to discover the user mouse movements using different techniques. This, however, will be with much worser performance, likely curbing down the invadive nature.