Title: Final remarks on the JSR project
Date: 2022-05-10 18:00
Series: JShelter background

The [JavaScript Restrictor](https://nlnet.nl/project/JSRestrictor/) ([JSR](/support/)) project (supported by [NGI0 PET
Fund](https://nlnet.nl/PET), a fund established by [NLnet](https://nlnet.nl/) with financial support
from the European Commission's [Next Generation Internet](https://ngi.eu/) programme, under the
aegis of DG Communications Networks, Content and Technology under grant agreement No 825310) is
heading towards its end, and we summarize what the project gave JShelter and reiterate the chosen
approaches.

### 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](https://nlnet.nl/project/JShelter/)). Let us go
through the list in more detail:

We reviewed literature focusing on the fingerprinting scripts and studied APIs [declined by
Apple](https://github.com/polcak/jsrestrictor/issues/66). During the project, we added or improved wrappers to JavaScript Shield for:

* All API calls providing timestamps,
* `window.name`,
* `MediaDevices.prototype.enumerateDevices`
* Beacon API,
* Canvas API and Web GL API,
* Audio API,
* `Navigator.prototype.hardwareConcurrency`
* `Navigator.prototype.deviceMemory`
* `Navigator.prototype.getGamepads`
* `Navigator.prototype.activeVRDisplays`
* `Navigator.prototype.plugins`
* Sensor API: Magnetometer, Accelerometer, LinearAccelerationSensor, GravitySensor, Gyroscope,
* AbsoluteOrientationSensor, RelativeOrientationSensor, and AmbientLightSensor
* BigInt typed arrays
* `Navigator.prototype.requestMediaKeySystemAccess`
* `MediaCapabilities.prototype.encodingInfo`
* `MediaCapabilities.prototype.decodingInfo`
* `HTMLMediaElement.prototype.canPlayType`
* Network Information API
* Web NFC API
* Cooperative Scheduling of Background Tasks API
* User idle detection

Note that JShelter modifies APIs depending on the selected JavaScript Shield level and the tweaks for the visited domain.

Previous literature modifies outputs of some APIs differently during repeated
calls. JShelter [adopted the model of Brave](/farbling/). 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](https://github.com/plaperdr/fprandom)  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.

JShelter provides [Fingerprint Detector](/fpdetection/) (FPD), a module that heuristically detects fingerprinting and
notifies users with an option to block future communications. This anti-fingerprinting mechanism is
orthogonal to the little lies anti-fingerprinting mechanisms in JavaScript Shield, and we advise using both mechanisms.
Little lies help if the fingerprinting scripts upload some readings before FPD detects the attempt
or the user deactivates FPD for a website. FPD provides an additional safety net for fingerprinters
trying to nullify the little lies. FPD also provides a report page that can educate users about the
APIs misused for fingerprinting. We developed code for crawling websites and detecting APIs often blocked
by uBlock Origin with the goal of gradually improving heuristics. We do not have an automatic
generation of heuristics, and manual oversight is needed.

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](https://github.com/hackademix/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.

### Issues

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](https://codeberg.org/JShelter/webextension/issues?q=&type=all&sort=relevance&state=closed&labels=&milestone=75282&project=0&assignee=0&poster=0) and [13 issues on Github](https://github.com/polcak/jsrestrictor/issues?q=is%3Aissue+label%3A%22NLNet+project+evaluation+phase%22+is%3Aclosed).

5 investigated issues remain open on [Github](https://github.com/polcak/jsrestrictor/issues?q=is%3Aissue+label%3A%22NLNet+project+evaluation+phase%22+is%3Aopen). 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](https://codeberg.org/JShelter/webextension/issues?q=&type=all&sort=relevance&state=open&labels=&milestone=75282&project=0&assignee=0&poster=0&archived=false) that cover possible enhancement of the JShelter, future directions, and possible ideas for future projects. We have additional [5 opened issues on Pagure](https://pagure.io/JShelter/webextension/issues?status=Open&milestone=NLNet+evaluation&close_status=) that we investigated during the evaluation phase. [One](https://codeberg.org/JShelter/webextension/issues/55) is a duplicate of the issue opened at Github, [another](https://codeberg.org/JShelter/webextension/issues/37) is almost closed. We are working on all 5 issues outside the JSR project.

### Conclusion

JShelter is not perfect, but we believe that we are heading in the right direction. We want to
continue to work on this project. However, be patient with some issues that need time and a lot of
work to be solved. The JSR project and the [parallel NGI0 PET Fund project](https://nlnet.nl/project/JShelter/) transformed the original JavaScript Restrictor extension to JShelter, suitable for everyday protection.

If you have not noticed yet, we created a [FAQ section](/faq/) and the page describing [JShelter
threat model](/threatmodel/) during the final stages of the JSR project.
