3 ms·

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 appropria

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

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