Feature #974


Consider implementing user modifications of the JavaScript on a website

Added by up wards over 1 year ago. Updated over 1 year ago.

Start date:
Due date:
% Done:


Estimated time:


Userscript support to extend browser's abilities.

Actions #1

Updated by Soren Stoutner over 1 year ago

  • Assignee set to Soren Stoutner

I am fundamentally opposed to any sort of plugin architecture, because it expands the attack surface of the browser to an unacceptable level.

It might be possible to implement some sort of user-based JavaScript modification that would be compatible with the above, but I am not certain it would be wise to add these types of JavaScript injection controls to Privacy Browser.

Note that when #270 is implemented (requires Privacy WebView in the 4.x series), Privacy Browser will get most of the benefits without all of the downsides.

Actions #2

Updated by up wards over 1 year ago

Then, I suggest to add a warning when that feature is activated for the first time.

The reason I ask for Userscript support is to compensate the gap between Privacy Browser and other web browsers that have a big enough userbase and popularity propaganda to motivate people to develop extensions for themselves.

Assuming a disillusioned person is experiencing Privacy Browser for the first time, and he used to use an extension called Privacy-Redirect, he might want that extension ported to Privacy Browser, yet by porting more features, Privacy Browser might be:

  • Too complicated.
  • Unstable.

This is where Userscript support is useful, once Privacy Browser has support for Userscripts, the aforementioned disillusioned person can refer to

Concerning to security: I remember the days of USO (, now archived at, and I remember that a Userscript has exploited my web browser to fix a homepage. I believe it was a Userscript that made that shenanigan, yet this is what makes Userscripts so great because thhey are easy to publish and maintain and are not subjected to censorship and other corporate shenanigans that are even worse.

Solution: Adopt a permission mechanism such of Tampermonkey which asks user to confirm access to a foreign URL.

Actions #3

Updated by Soren Stoutner over 1 year ago

  • Subject changed from Userscript to Consider implementing something similar to Userscript
  • Priority changed from 3.x to 4.x

I have already written in several places about how Privacy Browser will never support a plugin system for both privacy and security reasons. I do not imagine that I will ever change my mind on that issue. However, I intend to implement many of the features of good extensions directly into Privacy Browser. For example, people who like ideas like FREEdirector will be interested in #502.

There is a very small chance I might change my mind about implementing something like Userscript, but I think it is highly unlikely that I would do so. One of the central premises of Privacy Browser is that JavaScript should be disabled by default and only enabled for websites where you have a high degree of trust. One of my goals with Privacy Browser is to get big enough that I can change the expectation of web developers, who will adjust their websites to work well with JavaScript disabled because they will come to expect that a large number of their visitors will visit their websites without having JavaScript enabled. Hence, the usefulness of modifying a website's JavaScript will become less than it currently is, while the negative security and privacy potentials of increasing Privacy Browser's attack surface by shipping code that makes it easy to inject JavaScript would not diminish.

However, I will leave this feature request open as a place where people can attempt to change my mind.

Actions #4

Updated by up wards over 1 year ago

I'm using Userscripts with Javascript disabled. It is rare for me to enable Javascript.

Most of the Userscripts work without Javascript, unless they rely on events that occur only with Javascript.

Actions #5

Updated by up wards over 1 year ago

Please also consider this:

With Userscript support you can enable Feed Previewer (XML to HTML) which works with Falkon web browser, Jumanji, Midori, Otter Browser and SmarkCookieWeb. See

This should work with the red lizard, orange fox and blue marble but they have blocked XSLT specifically for feeds, and they did it (in fact) to prevent progress or data delivery because XSLT allows having a uniform design per user for all pages of all types by constructing XML using XSLT, but that's not helping them and their associates that want to have more Javascript to exploite more users and data.

You can apply Userscript and have a dedicated addon page of tusted/featured/recommended Usescripts.

Actions #6

Updated by Soren Stoutner over 1 year ago

  • Subject changed from Consider implementing something similar to Userscript to Consider implementing user modifications of the JavaScript on a website

I understand better now what you are asking. In that case, I will never implement a plugin system where users can add something like Userscript. However, it is possible I might directly add some of the features of Userscript to Privacy Browser in ways that I can guarantee the privacy and security of the feature better than with a general plugin system. I have retitled this feature request to be about a user's ability to modify the JavaScript of a website, which I am unlikely to ever implement, but could possibly happen if I am presented with an argument in its favor that is better than any I have seen so far. As noted above, there are already existing planned features that will implement some of the other functionality that can be accomplished by Userscript. Each type of functionality should be handled by a separate feature request so its merits can be independently discussed.

Actions #7

Updated by Soren Stoutner over 1 year ago

For a little bit of context, Userscript engines like Greasemonkey use JavaScript to modify the contents of websites. Even if JavaScript is disabled for the website itself, a JavaScript engine has to be running to interpret the Userscripts, which are written in JavaScript.

Privacy Browser, by contract, completely disables JavaScript when it is turned off. Lowering the security of Privacy Browser so that turning off JavaScript only disables some JavaScript (and trying to make sure there is no loophole where a website could sneak in some JavaScript to the allowed list through some sort of exploit) is not the type of thing I would ever do to Privacy Browser. Rather, every single desired feature will be implemented directly into the source code of Privacy Browser (Kotlin in the case of Android). This security by fundamental design is one of the things that sets Privacy Browser apart from most other browsers.


Also available in: Atom PDF