6 ms·

Oof, looks like Tridactyls "fixamo" disabled the URL checking for addon installation in firefox, by writing into the user.js prefs: user_pref("extensions.w

Oof, looks like Tridactyls "fixamo" disabled the URL checking for addon installation in firefox, by writing into the user.js prefs: user_pref("extensions.webextensions.restrictedDomains", ""); I can see why they'd get yanked over that. I would definitely not expect installing a random addon that makes my browser have vim controls to change a relatively sensitive setting like that. 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)

cp9 7y ago
and it wouldn't. You explicitly have to install the native messenger and run fixamo, which in the rc file for tridactyl explictly mentions what it's about to do
miloignis 7y ago
It looks like you had to run the command explicitly to do that though, and that it wasn't done by default, so it seems pretty kosher to me if they had appropriate warnings (and I think the issue says they did...)
- mcpherrinm 7y ago
  As far as I can tell from a brief check, it just says it "fix tridactyl on addons.mozilla.org". 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 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.
  - jhall1468 7y ago
    Fundamentally, Firefox is forcing the addon vendor to overwrite the users.js file without the users permission. What's more, these users only got this overwrite by explicitly allowing it. 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.
  - Mathnerd314 7y ago
    IIRC the reason AMO is sensitive is because the browser injects a "control the browser" object into the page. The first pref Tridactyl sets is to remove this privilege escalation, the second (in top comment) is to remove the restriction on addons accessing AMO. Perusing the original bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1415644 https://bugzilla.mozilla.org/show_bug.cgi?id=1415644) the main concern overall seems to be stealing browser history through Firefox Accounts. But as the reviewer says, "I'm not really clear what we're protecting here, feels like a bug in search of a problem."
  - cmcaine 7y ago
    Disclaimer: I am one of the authors of Tridactyl. 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
Ambroisie 7y ago
The thing is, users that ran this command know what it did. Maybe not in all its detail (I certainly didn't know exactly what it did, although I could have looked for it). That's because for this command to be of any use to the user, they first have to enable the "native client" to enable reading Tridactyl's RC file, which is explicitly stated to weaken the security model Mozilla tries to enforce on extensions. 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.
- shawnz 7y ago
  It's explicitly stated that it will weaken the security model, but it's not explicitly stated that it will modify user.js. Now the author is claiming that reversing the change would be improper because it involves modifying user.js without explicitly saying so, but that's literally exactly what they did already. 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.
  - cmcaine 7y ago
    > it involves modifying user.js without explicitly saying so, but that's literally exactly what they did already. 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.
  - feanaro 7y ago
    I've certainly read somewhere that running `fixamo` would modify my user.js. I was fully aware of this fact prior to running the command.
bsdubernerd 7y ago
This was never done automatically. 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.
- Causality1 7y ago
  Indeed. Mozilla's progress towards walled-gardening us ignorant vulnerable babies marches ever onward.
  - tptacek 7y ago
    If that's the best argument Tridactyl can marshal, there isn't much controversy here: Tridactyl will lose, and be blocked by Firefox.
    - cmcaine 7y ago
      The arguments made by tridactyl developers to Mozilla are published in the linked thread. There is no need to speculate. We don't complain about walled gardens.
      - pvg 7y ago
        In that thread there's stuff like 'Add-ons before WebExtensions could access the AMO fine and the sky did not fall in' and similar sentiments expressed in the issue post itself. It also seems like a thoroughly unwinnable argument, you're basically saying Mozilla's security policies are pointless because things were just fine as they were. They obviously disagree profoundly and aren't going to be convinced by this.
        cmcaine 7y ago
        This is a misrepresentation of our argument. 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.
bovine3dom 7y ago
Whining developer here. The documentation was this: https://github.com/tridactyl/tridactyl/blob/32ac11fe9d4321905fe1b412d5780f8952f55363/src/excmds.ts#L512 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.
- nextos 7y ago
  Thanks for developing Tridactyl. 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.
  - bovine3dom 7y ago
    There is some prior for this in that they actually already have a "God mode" permission [1] that they grant to some of their own extensions such as the screenshot tool (which might not be an extension any more). I don't think they'd let us have it, though. It would be really nice to work on PDFs again! [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1456485 https://bugzilla.mozilla.org/show_bug.cgi?id=1456485
  - bovine3dom 7y ago
    I should probably also point you to this comment - https://news.ycombinator.com/item?id=20719678 https://news.ycombinator.com/item?id=20719678 - some interaction before pages load would be possible if that keyboard-api was brought up-to-date and merged into Firefox.
    - Dylan16807 7y ago
mechnesium 7y ago
The fact that third-party addons can even touch sensitive settings in the user.js prefs is a massive security flaw in Mozilla's implementation of the WebExtensions API. Addons should be sandboxed/containerized or require privilege escalation before touching files on the disk.
- gruez 7y ago
  This. The whole point of this security feature is to prevent extensions from interfering with Mozilla pages. What's the point of this when addons can bypass turn it off themselves?
  - cmcaine 7y ago
    Only extensions that have a native messenger can do this (which requires users to accept a scary sounding permission and install a separate application on their computer)
- Mathnerd314 7y ago
  It uses native messaging with a Python script: https://github.com/tridactyl/tridactyl/blob/master/native/native_main.py#L406 https://github.com/tridactyl/tridactyl/blob/master/native/na... I don't think anyone who uses Tridactyl is worried about its security, it has a permissions list 15+ lines long.

cp9 7y ago

and it wouldn't. You explicitly have to install the native messenger and run fixamo, which in the rc file for tridactyl explictly mentions what it's about to do

miloignis 7y ago

It looks like you had to run the command explicitly to do that though, and that it wasn't done by default, so it seems pretty kosher to me if they had appropriate warnings (and I think the issue says they did...)

mcpherrinm 7y ago
As far as I can tell from a brief check, it just says it "fix tridactyl on addons.mozilla.org". 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 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.
- jhall1468 7y ago
  Fundamentally, Firefox is forcing the addon vendor to overwrite the users.js file without the users permission. What's more, these users only got this overwrite by explicitly allowing it. 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.
- Mathnerd314 7y ago
  IIRC the reason AMO is sensitive is because the browser injects a "control the browser" object into the page. The first pref Tridactyl sets is to remove this privilege escalation, the second (in top comment) is to remove the restriction on addons accessing AMO. Perusing the original bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1415644 https://bugzilla.mozilla.org/show_bug.cgi?id=1415644) the main concern overall seems to be stealing browser history through Firefox Accounts. But as the reviewer says, "I'm not really clear what we're protecting here, feels like a bug in search of a problem."
- cmcaine 7y ago
  Disclaimer: I am one of the authors of Tridactyl. 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

Ambroisie 7y ago

The thing is, users that ran this command know what it did. Maybe not in all its detail (I certainly didn't know exactly what it did, although I could have looked for it). That's because for this command to be of any use to the user, they first have to enable the "native client" to enable reading Tridactyl's RC file, which is explicitly stated to weaken the security model Mozilla tries to enforce on extensions. 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.

shawnz 7y ago
It's explicitly stated that it will weaken the security model, but it's not explicitly stated that it will modify user.js. Now the author is claiming that reversing the change would be improper because it involves modifying user.js without explicitly saying so, but that's literally exactly what they did already. 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.
- cmcaine 7y ago
  > it involves modifying user.js without explicitly saying so, but that's literally exactly what they did already. 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.
- feanaro 7y ago
  I've certainly read somewhere that running `fixamo` would modify my user.js. I was fully aware of this fact prior to running the command.

bsdubernerd 7y ago

This was never done automatically. 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.

Causality1 7y ago
Indeed. Mozilla's progress towards walled-gardening us ignorant vulnerable babies marches ever onward.
- tptacek 7y ago
  If that's the best argument Tridactyl can marshal, there isn't much controversy here: Tridactyl will lose, and be blocked by Firefox.
  - cmcaine 7y ago
    The arguments made by tridactyl developers to Mozilla are published in the linked thread. There is no need to speculate. We don't complain about walled gardens.
    - pvg 7y ago
      In that thread there's stuff like 'Add-ons before WebExtensions could access the AMO fine and the sky did not fall in' and similar sentiments expressed in the issue post itself. It also seems like a thoroughly unwinnable argument, you're basically saying Mozilla's security policies are pointless because things were just fine as they were. They obviously disagree profoundly and aren't going to be convinced by this.
      - cmcaine 7y ago
        This is a misrepresentation of our argument. 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.

bovine3dom 7y ago

Whining developer here. The documentation was this: https://github.com/tridactyl/tridactyl/blob/32ac11fe9d4321905fe1b412d5780f8952f55363/src/excmds.ts#L512 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.

nextos 7y ago
Thanks for developing Tridactyl. 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.
- bovine3dom 7y ago
  There is some prior for this in that they actually already have a "God mode" permission [1] that they grant to some of their own extensions such as the screenshot tool (which might not be an extension any more). I don't think they'd let us have it, though. It would be really nice to work on PDFs again! [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1456485 https://bugzilla.mozilla.org/show_bug.cgi?id=1456485
- bovine3dom 7y ago
  I should probably also point you to this comment - https://news.ycombinator.com/item?id=20719678 https://news.ycombinator.com/item?id=20719678 - some interaction before pages load would be possible if that keyboard-api was brought up-to-date and merged into Firefox.
  - Dylan16807 7y ago

mechnesium 7y ago

The fact that third-party addons can even touch sensitive settings in the user.js prefs is a massive security flaw in Mozilla's implementation of the WebExtensions API. Addons should be sandboxed/containerized or require privilege escalation before touching files on the disk.

gruez 7y ago
This. The whole point of this security feature is to prevent extensions from interfering with Mozilla pages. What's the point of this when addons can bypass turn it off themselves?
- cmcaine 7y ago
  Only extensions that have a native messenger can do this (which requires users to accept a scary sounding permission and install a separate application on their computer)
Mathnerd314 7y ago
It uses native messaging with a Python script: https://github.com/tridactyl/tridactyl/blob/master/native/native_main.py#L406 https://github.com/tridactyl/tridactyl/blob/master/native/na... I don't think anyone who uses Tridactyl is worried about its security, it has a permissions list 15+ lines long.