This isn't a "random plug-in" playing with your security settings. It's a well designed extension which tries its hardest to allow power users to do what they want : control their browser the way they best see fit, without restrictions. If you want to stay safe, just don't enable those settings : they're not necessary to get a good out-of-the-box experience, but they allow some very powerful fine-tuning to turn your browser into your browser, with your commands.
They are not claiming that the problem is being forced to strengthen the security model without explicitly asking. They are claiming that the problem is specifically being forced to modify user.js without explicitly asking.
We have never modified firefox settings without a user explicitly opting in.
All the documentation for the `fixamo` function named the two firefox settings (as viewable in about:config) that `fixamo` would change.
`fixamo` was an opt-in feature that users were only going to find by reading our help files or asking us on our support channel.
Disclaimer: I am one of the authors of tridactyl.
"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."
And
"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 92e1b005c47995e3d24f61a7d4c3935df8437f1a
The only way this hurts you as a user is if all of the following occurs:
1. You manually install Tridactyl
2. You manually install our native messenger
3. You manually fun a command called `fixamo` or you manually find and install our exemplar RC file that explicitly says at the top that you should read 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.
They both get in the way as often as they help. Mirrors my experience with vim-mode plugins for non-vim IDEs/editors too.
But on the Vim-emulation for IDEs front I would like to send a shout-out to JetBrains for the IdeaVim plugin. IdeaVim combined with the CLion IDE, also by JetBrains, and language specific plugins, help me so massively much when I work on any project that spans more than a handful of files.
In several cases there are projects that I work on with ease in CLion that I could not imagine trying to do with plain old Vim, and there is no other IDE that I have enjoyed using as much as CLion, not even by a long shot.
I have nothing but good things to say about CLion and of JetBrains. Unless they do something drastically weird to CLion they likely have a customer for life in me.
IdeaVim is not a complete emulation of Vim, but it is a complete emulation of the parts of Vim that I use and expect, so I am very satisfied with it.
The documentation was this: https://github.com/tridactyl/tridactyl/blob/32ac11fe9d432190...
A fragment of that documentation would have been displayed in our tab completions as fixamo was typed.
As many other replies have mentioned, it was only ever run if users installed our native executable, and ran `fixamo` themselves.
It's sad how Mozilla killed Vimperator with the transition to WebExtensions. And how many of its features still cannot be replicated in Tridactyl, which I otherwise love, despite all your efforts.
Due to the new addon model, addons don't get the chance to run till the page finishes loading. So e.g. a 404 or a slow page force you to revert to standard keybindings which ruins the immersive Vim user experience.
Mozilla should perhaps create an API for privileged extensions. I know the userbase is small. But it's a very important userbase to keep the platform healthy.
I'd love to see Mozilla helping a bit by enabling APIs that are necessary to make Tridactyl as immersive as Vimperator was.
In fact, I did it manually to enable umatrix and tridactyl on AMO as I hate not being able to use my regular keybindings everywhere.
I'm doubly pissed at Mozilla here. I'm tired of being baby-sitted. Quantum killed half of what I was using before. And trydactyl still cannot do half of what previous extensions could do.
We don't complain about walled gardens.
The very next sentences are:
"I am happy to be corrected on this. If you have any specific explanations you would like me to provide to our users, I would be happy to pass them on."
We also supported Mozilla's choice to move away from the XUL API.
I and most of the other core contributors are in favour of of capabilities-based security with explicit permission granting, not just in Firefox, but in general.
We believe that it should also be possible for users to have their software do what they want it to do. Part of that is letting people make their own decisions about what level of risk they are willing to accept.
We are reasonable people. We have been told in non-specific terms that something is unsafe that we think is useful and reasonably safe. So we have asked Mozilla (several times) to explain how it is unsafe so that we can update our beliefs if necessary.
We are asking because we know from experience that Mozilla employees generally have a lower tolerance for risk than us (the developers of tridactyl) or many of our users. Fundamentally, that is OK, but here Mozilla is asking us to do a bunch of work and change our code in ways we don't really want to do so that it more closely matches their risk tolerance than ours.
They can choose to manage their ecosystem how they like, but we in the ecosystem rightly also get a small say.
So we are asking them to say why and trying to negotiate a compromise that will be acceptable to all of us.
It's a quote from your own devs in your own thread, and there are other similar ones. I don't know what your exact argument is but what's there sounds adversarial and reads more or less like telling Mozilla, Morrie Kessler-style, that they're being an unconscionable ballbreaker. There's probably some better, clearer way to present whatever it is you have in mind. Morrie didn't win the argument either.
None of the dev team believe that Mozilla are acting unconscionably. We believe roughly what I put in the post above.
E: and sure, it is a quote, but the immediate context matters.
But it's overriding a fairly useful setting, one that we use internally: By preventing webextensions from running on "sensitive domains", which includes AMO by default (since that could allow an addon to install more addons and bypass or hide the user prompts, I gather), but it would also include any other domains you've marked as sensitive.
I don't use Firefox at work unfortunately (because of https://bugzilla.mozilla.org/show_bug.cgi?id=963354), but we generally want to allow users to install addons on non-sensitive sites.
Internal domains that are much higher risk, and may have regulatory requirements around who can receive data on them (eg, because of GDPR). So we'd use a setting like this (or the equivalent in Chrome) to restrict addons on those very sensitive sites. Having addons like Tridactyl that undermines that is a big red flag.
I admit I don't fully understand all the nuances here, but it seems like Mozilla's stance closely aligns with what I'd expect here.
We did actually set another firefox setting that means that webextensions cannot access the privileged JS environment on AMO (to my knowledge).
We have invited Mozilla several times to provide some text for us to share with our users explaining what the issue is and they have demurred.
I think for 99% of users, if a webextension can run on all pages (which many do) it can hurt them a lot more by stealing credentials (which is quite easy) than by installing other addons (which is hard).
Sure, we could have included some more warnings but 1. we did document clearly what we were doing if anyone wanted to check up (we were just automating the advice given in several blogs); 2. I think I talked to some mozillian's about it at the time, and they were unconcerned, but maybe not, could have been a similar other issue; 3. last time I looked there was no good explanation of why this is actually dangerous anywhere.
For reference, the exact messages provided to users were:
"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."
And
"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 92e1b005c47995e3d24f61a7d4c3935df8437f1a
So on one hand the reviewer is saying modifying the users.js setting without explicitly saying what it does, even though it required a separate process, was a bad thing to do. And their way of rectifying that is to do the same thing, only this time without any user interaction.
I don't think anyone who uses Tridactyl is worried about its security, it has a permissions list 15+ lines long.
The developers are now whining about being asked to revert that change, on the grounds that touching the file is a breach of trust (which, they've already done)