What are the steps that JShelter takes to protect users?
During the NGI0 PET Fund JSR project, we investigated fingerprinting scripts and prepared wrappers, developed Fingerprint Detector, ported anti-fingerprinting mechanisms from Brave, and improved the reliability of the code-injection mechanisms (the credit for the relaible injection goes to the parallel NGI0 PET project). Let us go through the list in more detail:
- All API calls providing timestamps,
- Beacon API,
- Canvas API and Web GL API,
- Audio API,
- Sensor API: Magnetometer, Accelerometer, LinearAccelerationSensor, GravitySensor, Gyroscope,
- AbsoluteOrientationSensor, RelativeOrientationSensor, and AmbientLightSensor
- BigInt typed arrays
- Network Information API
- Web NFC API
- Cooperative Scheduling of Background Tasks API
- User idle detection
Previous literature modifies outputs of some APIs differently during repeated calls. JShelter adopted the model of Brave. Hence, different origins read different values from the same APIs. One origin reads the same values for each repeated reading in the same browser session. Therefore, a fingerprint computed from these values is different for each origin and session, making cross-site correlation harder. Note that some identifiers like an IP address are outside of JShelter reach. JShelter provides different readings to the same origin in a new browser session.
FP-Random modifies data inserted into the canvas. For example, if the page wants to draw with orange colour, FP-Random draws with a different shade of orange. We do not think that this is a good strategy for JShelter:
- JShelter currently does not modify what users see in canvases (i.e. the browser does not modify the visual representation). JShelter only modifies read data - so each script sees different values than users. In other words, while FP-Random breaks both visual representation and export functions, JShelter breaks only export functions.
- Web GL offers visual effects produced by lighting, textures and other techniques. Identifying all mechanisms that need to be wrapped and modified seem to be too complex and out of the reach of this project.
The badge icon does not show level ID anymore. It shows the number of wrapping groups accessed by the current page as a number; the colour informs the user about the likelihood that the current page tries to fingerprint the user. The user can see more details about the activated wrappers and FPD findings in the popup window.
JShelter depends on NSCL (developed outside JSR project) that provides reliable cross-browser support to inject scripts before page scripts can access original APIs. That solved several long-standing bugs and allowed the extension to be used with confidence. However, NSCL does not implement reliable code injections into WebWorkers, so we apply Strict WebWorker protection by default. The protection disables WebWorkers and replaces them with a polyfill.
During the final stages of the NGI0 PET Fund project JSR project, we investigated the consistency of the mechanisms and their real-world deployment. We closed 6 issues on Pagure and 13 issues on Github.
5 investigated issues remain open on Github. For three we need more details or cannot reproduce the issue, two refer to bugs that we are trying to fix (the issues were delegated to other JShelter developer outside the JSR project).
We opened 8 issues that cover possible enhancement of the JShelter, future directions, and possible ideas for future projects. We have additional 5 opened issues on Pagure that we investigated during the evaluation phase. One is a duplicate of the issue opened at Github, another is almost closed. We are working on all 5 issues outside the JSR project.