FC: support arkenfoxes override file and updater script

[boredsquirrel]

This should be a small adaption, otherwise Arkenfoxes tooling could be used.

Currently the user.js blocks EVERYTHING, even informational messages, donation appeals etc.

This is very strict and I would also like to include a few example overrides for

• re-enabling crash reports
• re-enabling the usage of your actual language (it is a mail client and this will break lot of use cases)
• re-enabling the addon installer
• re-enabling donation appeals and maybe more

[HorlogeSkynet]

Hello, thanks for your batch of issues.

You're right, the template is pretty strict and one may want to relax some settings.

We could just vendor upstream scripts (there is Windows to support too...). Due to the time-consuming aspect of maintaining code as well as the whole configuration script, I'd like to note that if we do so, I will reject/forward to upstream any bug reports of feature requests addressing them (either to keep back-porting changes straightforward and keep this project focused on Thunderbird), unless someone is motivated enough to assume the burden here.

GitHub issue templates/PR will need to be updated to mention this.

A PR will be welcome, as always 🙂

(Also see #1, #10, #29 and #35)

[boredsquirrel]

okay very true, this issue is old.

I think it should be a priority though, and didnt fully read everything yet. Why did none of the proposed solutions get implemented?

to #44 I do think having modules (and adding upstream changes simply to one of these categories) would make it way easier for users to grasp its purpose.

Arkenfox / this modification are a mess. Its a mix between hardening, privacy optimizations and plain "I dont want to get any messages". There are even some major problems, like overriding that no version update infos are ever shown, which makes no sense but it cannot be changed through an override.js as you can only set a fix value and not simply remove this line.

I do criticise arkenfox for that, and many security people think similarly I suppose.

How do you or others keep track of the changes? are they just git diffs? In the end they are manually selected and added to the end of the script, arent they?

I dont see how this would increase maintenance a lot. I would like to help and I think the override script is a big overcomplication for this exact idea. I am honest I didnt find a normal way to load another javascript file in a javascript file, would it just be

. ./block-messages.js
. ./privacy-hard.js
. ./medium-hardening.js
. ./anonymity-settings.js

? This would allow users to simply comment one line out, instead of using an overcomplicated (and OS-specific) updater script.

[HorlogeSkynet]

I think it should be a priority though, and didnt fully read everything yet. Why did none of the proposed solutions get implemented?

More or less because of what I keep bothering you with : maintainability and work-bandwidth.

to #44 I do think having modules (and adding upstream changes simply to one of these categories) would make it way easier for users to grasp its purpose.

This brings the question about those projects audience. And as of now, I guess it is oriented toward infosec community. You can hope/wish upstream is reworked to increase accessibility, but I think it will never be the case (but one is free to fork as needed).

Arkenfox / this modification are a mess. Its a mix between hardening, privacy optimizations and plain "I dont want to get any messages". There are even some major problems, like overriding that no version update infos are ever shown, which makes no sense but it cannot be changed through an override.js as you can only set a fix value and not simply remove this line.

I do criticise arkenfox for that, and many security people think similarly I suppose.

How do you or others keep track of the changes? are they just git diffs? In the end they are manually selected and added to the end of the script, arent they?

I am no expert when it comes to what people think about upstream (from my PoV it fulfills its purposes, and I think it has been two years now since release notes are intelligible).
About applying changes, I guess you're right 😅

I dont see how this would increase maintenance a lot. I would like to help and I think the override script is a big overcomplication for this exact idea. I am honest I didnt find a normal way to load another javascript file in a javascript file, would it just be

. ./block-messages.js
. ./privacy-hard.js
. ./medium-hardening.js
. ./anonymity-settings.js

? This would allow users to simply comment one line out, instead of using an overcomplicated (and OS-specific) updater script.

The fact that user.js could not be puzzled across different modules (JavaScript is not loaded as is, it is actually a Rust parser consuming only known tokens) indeed increases complexity. Those .js files have not been thought for this purpose at all.
Although the idea of hardening/tweaking "profiles" is interesting. I wonder how we could propose this without drastically increasing the number of lines of code/configuration (if we vendor upstream scripts, for instance).

[HorlogeSkynet]

(I plan to adapt upstream scripts for this project when applying future migration for next ESR, stay tuned)

[HorlogeSkynet]

Closing here are scripts are on their way (see #55). Looking for proper testing though 🙂