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.
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.
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.
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