As a user who prefers to do "weird" stuff with my machine with full knowledge that it means any issues I run into are my own to deal with, how can I (and others who feel the same) reach out and let whoever is behind this know that I support your position in not messing with my configurations without my explicit concent?

There aren't any official channels. I'd rather not get into the business of directing an angry mob anywhere; on the contrary, I think the less time Mozilla has to spend supporting our weird use-cases, the more likely they'll be to continue to support them. Perhaps giving this issue a thumbs up might help? I guess that could be misconstrued...

The policy on blocking is here - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/AMO/Blocking_Process - and makes it clear that it's totally at Mozilla's discretion. I posted this issue mostly as a courtesy to our users as it didn't seem right to keep this deadline a secret.

I also wanted some feedback on whether people found the idea of changing files without consent as icky as I did.

I agree changing user.js without user interaction sounds like something to avoid.

As an anecdote, before v1.0.0, qutebrowser used to have a qutebrowser.conf file which got edited automatically in some scenarios (when using :set, but also on upgrades, etc.). This is why the split configuration files approach was introduced: An autoconfig.yml which is adjusted automatically (:set/:bind commands, settings UI, migrations on upgrades, etc.) and an optional config.py file which users can hand-write and qutebrowser never touches unless the user runs specific commands like :config-write-py.

A user.js file sounds like something to be written by hand (and the wiki page you linked confirms that) - so having a :setpref command to change it semi-automatically seems kinda okay, but automatically messing with it definitely does not, IMHO...

I think icky is better than blocked :D
will be annoying for those who really wanted these settings in user.js, but can reapply manually after tridactyl reverts it.
Probably people storing stuff in user.js are advanced users anyway.
Just need to put up warning, on the new tab page, about how the file was changed IMHO

I'm also of the opinion that icky is better than blocked. The suggested prominent note on the new-tab page could help people get the behavior they used to have back, while appeasing the Mozilla security team and keeping tridactyl around.

There doesn't seem to be a solution which keeps the user.js file untouched, and also keep tridactyl in AMO. So I'd rather keep tridactyl in AMO and edit user.js by hand after whatever update makes this change.

I do appreciate that sentiment - one of the core developers is also of that opinion. However, there is another snag: it quite clearly falls foul of the computer misuse act in the UK.

Perhaps if I mention that to the reviewers they will be more willing to find another solution.

I don't like that they are (ab-)using their monopoly position on plugin distribution to try to strongarm you here. That's exactly why a lot of the community disliked the lockdown of the plugin ecosystem. Everything you did was in good faith, and you immediately reacted to their complaint. No reason to start threatening you, especially with such a short deadline.

Regarding a solution: Maybe an active prompt ("Mozilla asked us to remove the fixamo option for security reasons. We noticed that the option xyz is set in your config.js, though we can not confirm that it was set by tridactyl. The mozilla team recommends to remove that option. Would you like to remove it? [Y/n]") would work as a compromise?

Although this is a shitty situation with no perfect solution, I agree on the sentiment that an icky Tridactyl is better than a blocked one. Good luck on your thesis and thanks for doing this outstanding work!

I would say silently changing user.js is very bad. But in the end the users will notice and activate again.

Better alternative would be a big visible red box/banner, on new tab, after the next update. With a shortcut to unfixamo.
Otherwise, saying that the user.js changed automatically With a link to the explanation. And a wiki page to enable it again manually, with the proper "security risks" noted.

Is it possible to backup user.js before resetting it? If so, than it's possible to notify user where his backup file is and what is the recommended change to it. At least this way users won't loose their files. As far as I can see, it also complies with Mozilla demands. Yes users will be a little annoyed by that but it's a lot better than have tridactyl blocked completely.

Regarding a solution: Maybe an active prompt ("Mozilla asked us to remove the fixamo option for security reasons. We noticed that the option xyz is set in your config.js, though we can not confirm that it was set by tridactyl. The mozilla team recommends to remove that option. Would you like to remove it? [Y/n]") would work as a compromise?

It's a good idea, but I'd be worried about how long it would take to implement that. Using window.confirm() would speed it up quite a bit but comes with lots of its own issues (mostly that it would look really really dodgy).

Keeping a backup would be easy but wouldn't make it any less illegal.

You might want to take the angle with the AMO reviewer that the security impacts of fixamo are made obvious to anyone who was actually able to change their user.js through it, because in order to actually do it, people had to install the native client which has the sole and clear purpose of getting around all the restrictions imposed on extensions for security.

Because I don't think the reviewer quite gets this.

Anyway, if they do remove it, seems like someone could just "fork" (wink wink) Tridactyl (is "Petradactyl" taken yet?) with an explicit stated goal and description of being like Tridactyl, but with all features that Mozilla considers security-weakening either removed or behind clear warnings.

It's a good idea, but I'd be worried about how long it would take to implement that. Using window.confirm() would speed it up quite a bit but comes with lots of its own issues (mostly that it would look really really dodgy).

What about: Opening a new tab (like many extensions do on upgrades to show changelogs/project news) and:

• Request the user to choose either option. Maybe even making the config removal button huge, green and focused by default and the "skip" option small and grey with a huge warning (if that makes AMO happier) and require an answer before Tridactyl is enabled.

or

• Tell the user that AMO is requiring Tridactyl devs. to remove such and such settings from user.js. And that to continue using Tridactyl you need to accept its removal and list the changes (about to be) made so the user can revert them back manually?

Both ways would need explicit action from the user, so it would not be illegal anymore.

I repled to the reviewer just now:

Dear reviewer,

How do you feel about the following compromise?

1. Tridactyl 1.17 scans user.js for the fixamo lines if the native messenger is installed
2. If the fixamo lines are there, we immediately open a tab with a large message that explains the issue and has two buttons (large, green and default: "Disable/Comment these lines in user.js and prefs.js", smaller and red: "I understand the risks and do not wish to remove these lines"). Exact text for explanation and buttons can be provided by you.
3. If the user clicks the green button we comment out the old lines and add new code that will set the default values and prompt them to restart. On restart we can confirm that the right values are in prefs.js and remove our lines setting the default values from user.js.
4. If the user clicks the red button we don't scan or ask again.
5. If the user makes no selection we keep prompting them every time they restart the browser (or, if you feel it is very serious, we pick the green button for them after N notifications).

If you are unwilling or unable to disclose why fixamo is so dangerous (for point 2) because of undisclosed bugs, please say so and link those bugs to us when they are disclosed because we are curious :)

We are concerned that altering what is clearly external user configuration without explicit consent (as we believe you have asked us to do) may be a breach of the UK Computer Misuse Act 1990 (Section 3, link below). Our interpretation is that by changing prefs.js and user.js, we will be "impairing the operation" of Tridactyl, Firefox and potentially other add-ons. Additionally, by modifying the files unexpectedly we "impair the reliability of data".

We would also appreciate a response on whether automatically redirecting users who opt-in from e.g. addons.mozilla.org/* to addons.mozilla.org./*is acceptable to you.

Both Oliver and I are very busy. We would appreciate your prompt response on both counts if you would like us to write the code to do this.

Computer Misuse Act: http://www.legislation.gov.uk/ukpga/1990/18/section/3

Sincerely,
Colin

We also hit the front page of hacker news, which is unfortunate. https://news.ycombinator.com/item?id=20716963

I made the following summarising comment there:

I am one of the developers of Tridactyl.

This dispute is because Tridactyl used to provide a function that users could choose to run that would change two of Firefox's settings (the kind you find in about:config). Changing these settings allows addons to run on e.g. addons.mozilla.org and accounts.firefox.org where they otherwise cannot. The change we made is the same change that several blogs had already talked about and suggested.

Here is a relevant bugzilla thread that motivated the creation of the blacklist that we turned off, so you can see what Mozilla thinks: https://bugzilla.mozilla.org/show_bug.cgi?id=1415644

A mozilla employee informally asked us to remove this function for security reasons (and we did). Later, an AMO reviewer asked us to change users' Firefox config automatically to remove these settings. We would rather this were made an explicit choice for Tridactyl users and we're trying to negotiate a compromise with the reviewer.

This is the only plausible route to exploitation of this situation that I know of, assuming a user acting before we removed the fixamo command:

1. You manually install Tridactyl
2. You manually install our native messenger
3. You manually run a command called fixamo or you manually find and install our exemplar RC file that explicitly says at the top that you should read and customise it because it does things you might not like; and then you don't read or edit it
4. You also manually install a malicious addon
5. That malicious addon doesn't have permissions for <all_urls> (otherwise it can steal your banking credentials without tridactyl's help) but does have permission for accounts.firefox.org
6. That addon can then steal your firefox account credentials and use them to e.g. mess with your synced settings and e.g. download your passwords database (if you don't have a master password set).

My view is that you're pretty much fucked if you install a malicious addon with <all_urls> anyway (and many addons request that permission), so this slight extra capability you get if you successfully phish someone in this pool of <1000 people isn't a big deal.

---

Some people have opined that our documentation for the command was not explicit enough. My opinion is that it's good enough and about on par with other resources that talked about the same settings. It would be better if it was more explicit about the security risks, but we provided fairly complete information about what we were doing and a link to the source code.

This is the documentation we provided:

In the "Webextension caveats" section:

"To make Tridactyl work on addons.mozilla.org and some other Mozilla domains, you need to open about:config, run fixamo or add a new boolean privacy.resistFingerprinting.block_mozAddonManager with the value true, and remove the above domains from extensions.webextensions.restrictedDomains."

In the docstring for fixamo, partially displayed if you type fixamo in the commandline and also included in the help pages we encourage users to use with e.g. :h fixamo:

"Simply sets

"privacy.resistFingerprinting.block_mozAddonManager":true "extensions.webextensions.restrictedDomains":""

in about:config via user.js so that Tridactyl (and other extensions!) can be used on addons.mozilla.org and other sites."

You can find these messages in src/excmds.ts at commit 92e1b00

We also included a variant of the fixamo command in the exemplar .tridactylrc file (not used unless you have also installed the native messenger and also explicitly found, downloaded and installed the exemplar). This file includes this text at the top:

"Provided only as an example.

Do not install/run without reading through as you may be surprised by some of the settings."

And this text right above the fixamo line:

"Make Tridactyl work on more sites at the expense of some security"

Somebody linked this bugzilla bug in the HN thread too, which is the most complete description of the potential issues arising from disabling restrictedDomains that I know of. https://bugzilla.mozilla.org/show_bug.cgi?id=1415644

We've just had a reply from the reviewer to cmcaine's "forced choice" suggestion mentioned above. I'll quote the reply in full:

This approach is not acceptable for us. The revert needs to happen automatically.

What if someone did not use fixamo to introduce the changes? Should Tridactyl refuse to work within browser configured as so? Because I don't see you working as a remote armed police enforcing specific settings. If Mozilla doesn't like these settings – why do they even exist in the first place?

Anyway – for another solution, convoluted, I know. But maybe Tridactyl could check if the offending settings are present (and there's no Tridactyl OK setting set too – see below), and refuse to work unless:

1. the user manually edits the user.js file to remove the offending settings;
2. Tridactyl on the next start sees that the profile is good to go and sets it's own setting marking the profile as OK to run on (this setting should be of course set on profiles not having the offending settings and just continue working there normally);
3. the user can then manually add these settings on their own, if they choose to do so.

That puts a lot of work in users' hands, but we are power-users and I think we can manage doing it, for the sake of having Tridactyl still running on our browsers. I believe that the userbase having the settings present is not 100% and doing nothing will punish the whole userbase, not only these ones who have this offensive stuff set on.

Based on their latest response, it seems that the only real option that keeps tridactyl in the AMO is to automatically remove the lines from the user.js file, as the Firefox security team is requesting.

As a user of tridactyl, I'd much rather keep tridactyl in the AMO and hand-roll my user.js file over having it taken out of the AMO and then doing...who knows what. I am really happy that tridactyl exists and that I get to use firefox with it, so doing a little manual editing of a file to get advanced functionality is far preferable to not having tridactyl at all.

I defer to the devs, though, for what they are comfortable doing, and have time for.

What does "blocking affected versions of your add-on" mean? The current version does not add anything to user.js, so it seems there would be no grounds for blocking it, only old versions that had the fixamo command. There is no argument that installing the current version of Tridactyl poses any security risk.

What about removing/resetting the setting from the file unless there is a comment in the file matching a specific magic string, like /* tridactyl: I understand and do not want the change Mozilla is coercing you to make to this file */?

If they disable Tridactyl, there's a good possibility I'll be reverting to pre-Quantum and using Vimperator. I feel like Mozilla forcing me to do that is causing a much bigger security vulnerability than fixamo ever could have.

Unsigned extensions can be installed in a variety of ways which we'll be sure to enumerate if it comes to it.

I’m sorry that you are having so much trouble with the mozilla guys.
This is so much bullshit and making me quite angry / disappointed. If they think that “Users should not ever do this”, then why do these settings even exist? This is clearly their responsibility and not tridactyl’s, especially as it was opt-in only.

Tridactyl is honestly the best part about firefox and I wouldn’t be using firefox without it.

If there is anything we can do to help, please let us know.

I found this issue because Firefox wanted to update and my first reaction was, "I wonder how they're breaking Tridactyl this time."

Edit: ...was Tridactyl disabled or broken? So far I'm putting off updating.

Tridactyl may be delisted at the end of Friday this week. Probably central european time.

If Tridactyl is delisted you will notice because it will be disabled (but not uninstalled) in about:addons.

As an existing user you will probably just need to re-enable it.

They might completely blacklist my AMO key from Firefox, in which case you will need to tell Firefox to accept unsigned addons to keep using Tridactyl (there's a shell script that does this by extracting omni.ja and modifying a line or you can use dev or nightly) or wait for a Mozilla-acceptable fork or revision to emerge on AMO.

Updating Tridactyl should be safe whenever. Mozilla will block it by pushing a new blocklist to your browser, which is a different thing to addon updates.

Ah, thanks.

(It was Firefox that I was afraid of updating, not Tridactyl.)

you will need to tell Firefox to accept unsigned addons to keep using Tridactyl (there's a shell script that does this by extracting omni.ja and modifying a line or you can use dev or nightly)

Accepting unsigned addons through use of somebody's sketchy shell script -- what a wonderful security practice Mozilla is driving me towards! (◔_◔)

Thanks again for the update, as well as for the addon, even if it is so very dangerous for all the tech-illiterate elderly folk who habitually install vim emulators for their browsers.

I'm new to Tridacityl, so forgive my ignorance.

I don't really get the rc file part. Is/was that file automatically executed? Did it automatically call fixamo? What was the fixamo even used for? To enable hjkl keys and the rest of the extension on addons.mozilla.org? And in the mean time it enabled any extension to do what it wants. The severity of the security implication is debatable, but I guess it is >0 (i.e. it does introduce some insecurity), and if that is the case, I really don't see why you have/had the fixamo function - or am I the only person who uses addons.mozilla.org 1 every 100 years?

As I said, forgive my ignorance, but as a new user I don't feel I understand the situation 100%.

Also, isn't accepting the address bar popup of installing an addon beyond the control of any addon?

Is/was that [rc] file automatically executed?

Only if you installed Tridactyl's native messenger (an external executable you can install with :installnative) and copied said rc file to either $HOME/.tridactylrc or $XDG_CONFIG_HOME/tridactyl/tridactylrc.

Did it automatically call fixamo?

No, you had to manually add a call to the :fixamo command to your rc file for it to run :fixamo.

What was the fixamo even used for? To enable hjkl keys and the rest of the extension on addons.mozilla.org?

To enable running Tridactyl and any other extension you might have installed on Mozilla's websites. Some of these websites are listed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1445663

I really don't see why you have/had the fixamo function - or am I the only person who uses addons.mozilla.org 1 every 100 years?

Different people, different needs, different security requirements.

Also, isn't accepting the address bar popup of installing an addon beyond the control of any addon?

I think so yeah.

1.17.0 containing code to fiddle with user.js without user interaction as Mozillians wished has been submitted to AMO for review. Thanks to glacambre and cmcaine for arranging it - it couldn't have happened without them.

1.17.0 also removes set csp, another of Mozilla's demands. We'll add our own web request helper so users can recreate that and much more as soon as possible, probably within the month.

Thank you for moving forward.

how long do you expect it to take for the extension to return to AMO? it still doesn't show up in the search...

We didn't pass the first review. I'm waiting for a reply to a query - it appears they want us to remove the resistFingerprinting setting too and I wanted to make sure they were aware of any security implications of that. From past experience that will take a couple of days.

Then it'll be another few working days before we are reviewed again. In total, probably a week or two from now if all goes well.

You are able to install the AMO version of Tridactyl outside of the AMO if you so desire in the meantime - just look back up in this thread.

it appears they want us to remove the resistFingerprinting setting too

I think you meant restrictedDomains because unfixamo currently reverts resistFingerprinting but not restrictedDomains.

@depressed-pho what makes you say that?

@bovine3dom Oh... I think I saw an old diff. Sorry for the confusion.

Hmm still not on amo yet sadly.

Welp... guess I'm going back to Chrome (ick!) which at least has half-baked add-ons that can do some of Vimperator's functionality. Mozilla forced me to leave Firefox when they broke Vimperator and now Tridactyl is gone... so thanks for stepping on users and developers, Mozilla.

Took me a bit but I figured out how to install the tridactyl beta. Firefox and Mozilla drive me insane.

Unfixamo2 blew away some manual changes I'd made to users.js. It's pretty clear your hands are tied on this one, but it would be nice to offer a backup option.

Edit: I'm on the beta, which is why this ran a second time for me; ironic, in that I was running the beta to avoid this issue.

I am really sorry about that. Mozilla repeatedly said that we weren't allowed to provide any options that left the settings intact. I'm not sure commenting them out would have satisfied them.

Could you confirm that it was just block_mozAddonManager and restrictedDomains? Anything else is a serious bug.

Beta was always going to have to have had Unfixamo running: Mozilla would block it from Firefox if we didn't. We could have ignored their demands for the Arch unsigned build but I didn't want yet another permutation of Tridactyl to maintain. I suppose in future we could use AMO signing as a switch to provide Mozilla-compliant code.

@bovine3dom I'm reasonably sure it was just those settings, and if it wasn't, they weren't memorable enough that I'm super concerned. Just wanted to give you a heads-up that the previously-set "I've Already Run Unfixamo" setting was getting overridden, which I presume is already known.

It's finally been added back 🎉
https://addons.mozilla.org/en-US/firefox/addon/tridactyl-vim/

Yep! I submitted a new version late last week. It was accepted this afternoon.

Most of the delay was our fault. The manual reviews from the AMO reviewers only take 2-3 working days.

The update blew away some manually edited things for me too. Mozilla seems to have forgotten what motivated me to use Firefox in the first place: being in control of my own browser.

This information in the README is outdated:

I'm reading this years after the fact after coming up on it in the documentation, and I already like Tridactyl even more for having read this. Have used Qutebrowser on and off as a secondary browser for a few years now and can't believe I just discovered Tridactyl. Your accountability is very, very refreshing...firefox, not so much. Still never sure how to feel about Mozilla...but it's the lesser of two evils currently...

@hrfried Well put, extremely well put. Firefox is the lesser of two evils. Tridactyl is the only way to experience the web. Been using it for years, and it continually gets better. I cannot imagine life without it. Well... intelligent life anyway.