Freedom and privacy on the web: Our interview with the JShelter team

In order to catch up with development on the browser extension JShelter, which limits the degree to which JavaScript can control your browser, Greg from the FSF campaigns team (GF) conducted an interview with lead developers Libor Polčák (LP) and Giorgio Maone (GM).

1. GF: How would you describe JShelter?

GM: To me, JShelter is an excellent exercise in trying to enumerate, analyze, and mitigate the almost countless ways modern web APIs available to JavaScript can be abused to collect fine-grained data about users' hardware and software configuration. This data, in turn, is collected to reliably fingerprint, identify, and track users across websites. NoScript takes the blunt approach of disabling JavaScript and other active content by default, and allows users to enable specific, trusted scripts and sites one-by-one. This approach reduces the attack surface -- not just for privacy, but for security in particular (e.g. to defend against zero-day remote code execution attacks). JShelter, on the other hand, assumes all JavaScript is enabled by default, but focuses on counteracting scripts' ability to spy on users by creating a "fake" execution environment, different each session, where user/device-specific information is randomized, quantized, or obfuscated, therefore preventing global privacy-violating correlations.

JShelter's goal of fighting back JavaScript-based fingerprinting is similar to Tor Browser's, the other project I work on, but the two approaches are radically different: while the Tor Browser tries to equalize the observable features as much as possible, in order to make users indistinguishable by having large groups sharing the same fingerprint, JShelter, on the contrary, tries to change the fingerprint exposed by the same user every time, making it worthless for tracking purposes. Both of these approaches have a good complement in NoScript when it comes to security, because no matter how you fake or hide the data normally exposed to "legitimate" web APIs, running JavaScript indiscriminately on sites you don't trust can still facilitate attacks to effectively exploit browser and/or system vulnerabilities.

1. GF: How did the project start?

LP: The project started in 2017 at Brno University of Technology, when Zbyněk Červinka asked me to work on a diploma thesis that would aim at creating a privacy-improving WebExtension. At that time, we did not know what exactly we would like to create.

In 2020, we had a WebExtension, a couple of users, and a lot of ideas about what would need to be done before JShelter could be used daily. We applied for a grant from the NGI0 PET Fund, a fund established by NLnet. Interestingly, the FSF had very similar ideas and applied for the same grant. NLnet introduced us, and we have worked together since. What started as "JavaScript Restrictor" has transformed into JShelter, now with a new UI, nice web pages, improved reliability, and improved protections.

1. GF: Can you give some examples of what malicious JavaScript on the web can do? How does JShelter circumvent it?

GM: We tend to forget that every web page we visit is potentially a full-fledged application written in JavaScript, and, nowadays, the capabilities available to these are comparable to native applications. The main difference between the two is that we typically choose to install a native application with intention, and we can usually vet its usefulness and trustworthiness in advance, while, in the case of web apps, we may just "stumble upon" malicious web pages at random.

Now, very nefarious things can happen if an evil web page exploits a browser vulnerability to escape and access your system, trying, for example, to install a rootkit or to exfiltrate local data. These attacks are considered to be relatively rare and targeted. More commonly, "regular" web APIs are abused, without need for specific unpatched vulnerabilities, either to "parasite" your computational resources (e.g. by cryptominers) or to spy on your online behavior, possibly to sell your profile to data brokers. The latter is the specific threat which JShelter addresses as its priority.

1. GF: Is JShelter only for technical users?

LP: No. When we developed the new UI, we also focused on implementing simple options. We also try to explain all the options in the UI. However, technical and advanced users are currently at an advantage because they will know how to reconfigure the settings when faced with a broken web page, of which we are aware of several. Here we are faced with a dilemma: do we provide a default configuration that doesn't protect as we promise but works on pages that less advanced users may not be able to fix themselves, or do we go for the options that protect users completely but need some tweaks here and there?

During the last year, we improved FAQs, the UI, and other information. We see that the number of our users is increasing, so hopefully this means that JShelter is more usable for less advanced users. Nevertheless, there is still room for improvements.

1. GF: In your opinion, what does the "perfect world" in terms of the web look like? For example, would you put specific limits on what JavaScript can or can't access?

GM: The web was originally envisioned as a mere collection of hypertexts: just static interconnected text documents. But today's web is a chaotic execution environment, almost an OS of its own, with very loosely defined boundaries across applications and little or no user awareness of its power and potential for abuse.

Of course there's no coming back from the web as an application platform, which also has benefits, such as its openness and democratic access. But we need to provide users with more control on the trusted entities allowed to run code on their systems (for instance by creating and enforcing a code-signing mechanism) and on the permissions granted to those applications, which is something we (browser vendors and standardization bodies) started to do only recently with the most powerful and privacy-sensitive APIs, e.g. geo-location or microphone/camera access.

1. GF: On the other hand, what's the worst-case scenario in terms of abusive JavaScript? Are we living it now?

LP: It could be worse, like if JavaScript were allowed to access local drives, or if JavaScript had easy access to memory of other programs and other web pages a person visited. All of this reminds me of the fact that Chrome Zero was developed by the same people who discovered Meltdown and the original Spectre. I read a blog post where they described a script that read a memory of other processes, and they were able to retrieve private stuff inside that other process. But luckily, that does not happen on normal pages. The hardware bugs get workarounds or are fixed by microcode. In the "worst-case scenario," however, Technologies like Content Security Policy, same-origin policy, cache partitioning and many others would not be available.

1. GF: Can you give us some details on the changes you're making to JShelter for ManifestV3?

GM: ManifestV3 removes or limits many APIs that constitute the backbone of privacy- and security-oriented WebExtensions, such as NoScript or JShelter.

Fortunately, most of the changes affecting JShelter are encapsulated in its usage of the NoScript Commons Library, the collection of reusable WebExtensions building blocks, which I refactored some time ago from NoScript in order to help myself and other privacy/security extensions developers. This work helped us to better organize and share a work like this.

Therefore, I'm currently adapting the NoScript Commons Library to support NoScript's own transition to ManifestV3, by basically trying to leverage the new browser.scripting API as much as possible, and by replacing the webRequest API with the new Declarative Net Request API in places where it makes sense and where the compatibility benefits to JShelter should be more or less automatic. Of course, this process may introduce some new bugs or regressions which need to be fixed, but that's to be expected in big migration efforts such as this. One feature we're pretty sure can't survive -- at least not on Chrome, which is much more restrictive than Firefox when it comes to ManifestV3 -- is the Network Boundary Shield. This feature heavily relies on the blocking part of webRequest, an API which is doomed in Chromium-based browsers. But this specific loss is relatively acceptable because the protection against attacks on LAN resources provided by this feature will be at least partially standardized across browsers by the time we are forced to complete the migration.

1. GF: How can someone get involved with the JShelter project?

LP: Using JShelter and reporting any problems in our issue tracker is a huge help. If someone wants to contribute to the project itself, the best way is to post the ideas on the issue tracker or mail them to us. For simple changes, creating a pull request might be enough. We are also looking for a research partner.

GF: Thank you both for the interview!