5 ms·

I would've liked to see some reflection or even just acknowledgment about the fact that they intentionally disabled the "xpinstall.signatures.required" setting

I would've liked to see some reflection or even just acknowledgment about the fact that they intentionally disabled the "xpinstall.signatures.required" setting on Windows and OSX. I hope it's at least in the formal postmortem.

callahad 7y ago
That's covered at https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/ https://blog.mozilla.org/addons/2015/04/15/the-case-for-exte..., which is linked from ekr's post. I encourage you to read the rationale as a whole, but the specific question you're asking is addressed here: > Many developers have asked why we can’t make this a runtime option or preference. There is nowhere we could store that choice on the user’s machine that these greyware apps couldn’t change and plausibly claim they were acting on behalf of the user’s “choice” not to opt-out of the light grey checkbox on page 43 of their EULA. This is not a concern about hypotheticals, we have many documented cases of add-ons disabling the mechanisms through which we inform users and give them control over their add-ons. By baking the signing requirement into the executable these programs will either have to submit to our review process or take the blatant malware step of replacing or altering Firefox. We are sure some will take that step, but it won’t be an attractive option for a Fortune 500 plugin vendor, popular download sites, or the laptop vendor involved in distributing Superfish. For the ones who do, we hope that modifying another program’s executable code is blatant enough that security software vendors will take action and stop letting these programs hide behind terms buried in their user-hostile EULAs.
- Wowfunhappy 7y ago
  Does Windows et al really not provide a mechinism for saving privileged settings in a tamper-resistant way? I frankly find that hard to believe. How does other software solve this problem? There are of course always workarounds on an open platform like Windows/Mac/Linux, but the threshold isn’t “impossible”, it’s just “as difficult as injecting into the browser’s code.” Edit: For example, what if the config file contained a checksum of the file's contents + the user's hardware? If the setting is changed by the user within Firefox, the checksum is updated and everything works—if the checksum is invalid, settings are reset to the default. Video games will occasionally do this type of thing with their config files. Modders often figure out the formula—but again, the idea here isn't to make editing the file impossible, it's to make it as difficult as injecting into the Firefox executable.
  - kccqzy 7y ago
    I frankly find that easy to believe. After all, operating systems give desktop apps a lot of trust because they trust these desktop apps to respect the users' trust. It is very recent that we now have desktop apps running potentially untrusted code that can subvert the trusted desktop app. Of course, there are ways but just none are convenient. Generally the well established security boundaries are between the operating system and the user, and then between different users. Almost all the ways I can think of involves Firefox temporarily elevating privileges, which is undesirable.
  - djsumdog 7y ago
    I mean, the Windows UAC and the MacOS password prompt that elevate user access, but people often click through those. I can see their argument here.
    - TeMPOraL 7y ago
      No amount of security measures can stop users from being tricked by social engineering attack into self-pwnig themselves. At some point we need to stop taking control away from users, because this road ultimately leads to turning computers into cable TV.
  - TazeTSchnitzel 7y ago
    macOS's System Integrity Protection, aka rootless, means that, yes, macOS has a way to store settings that even root can't normally touch, though I suspect only Apple can make proper use of that right now. But Windows? A sadder story, I think.
  - temac 7y ago
    Windows starts to have something but it is only available in last versions of Windows 10, probably not enabled by default, and the model might not be exactly what is needed anyway. I don't even remember what it is supposed to protect against precisely -- and MS does not do a lot of communication about it. They maybe don't officially consider it a security boundary (same as UAC). Mozilla seems to be concerned about attackers having admin privileges (but that are still shy of just plainly hacking the Firefox binary or something crazy like that): quite hard to defend against that... and if you can, that means the user actually has lost some control over its own computer, which is a situation which has its own issues.
- pbhjpbhj 7y ago
  So that means going forward if Mozilla don't want you to have an add-on then you won't be able to enable it?
  - nocman 7y ago
    Unless you run an unbranded builds ( https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded_Builds https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded... ), or the Developer Edition ( https://www.mozilla.org/en-US/firefox/developer/ https://www.mozilla.org/en-US/firefox/developer/ ), where setting xpinstall.signatures.required to false still works, then yes, Mozilla can prevent you from using an add-on. More than "going forward", this has been the case for a while now. It's been long enough ago that they disabled that setting in stock Firefox that I don't remember exactly when it happened.
    - AnaniasAnanas 7y ago
      Sadly the unbranded builds do not have updates enabled and the developer edition is basically beta.
      - Wowfunhappy 7y ago
        Wait, why the heck don't the unbranded builds auto-update? To what purpose?
  - callahad 7y ago
    We do not take an editorial stance on add-on content with regard to signing, but we do have the ability to block add-ons that are malicious or which violate user privacy and security. We hope those choices will be few and far between, and that our users will agree with them. Our Add-on Policy is discussed further at https://blog.mozilla.org/addons/2019/05/02/add-on-policy-and-process-updates/ https://blog.mozilla.org/addons/2019/05/02/add-on-policy-and...
    - Silhouette 7y ago
      FWIW, I was genuinely shocked that this could happen, and it has severely damaged my trust in Firefox. I am extremely wary, having been bitten more than once, about software that automatically updates itself or is otherwise subject to remote interference. I don't run Windows 10. I don't use Chrome for anything important. I avoid subscription-based or activation-required software as much as possible. And in Firefox, I specifically chose to be prompted to install updates (which I usually do immediately, but it's my choice and I can do a quick search first in case there ever is a problem being widely reported). I find the argument that it's impossible to make this configurable because malware could then circumvent it very weak. If we're talking about that level of interference, anyone with access to the Firefox executable could in theory replace it, and given the open source nature of the Firefox codebase this wouldn't be particularly difficult technically for anyone willing to go to such lengths in the first place. In any case, even if the argument about hard-coding protection into the executable did stand up to scrutiny, there are alternatives possible instead of retrospectively disabling addons with no possible workaround. Perhaps most obviously, you could show a warning message and require explicit user approval at startup before activating the addon, for example, as is already done with various other useful features that are also potentially open to abuse. As things stand, far from protecting our privacy and security from malicious addons, the current system in fact deactivated all of our privacy- and security-protecting addons, without warning, right in the middle of browsing sessions. One of these seems to be very much worse than the other in terms of the risks created, and I urge you to consider that when deciding how addons are treated in the future.
- greendestiny_re 7y ago
  >or take the blatant malware step of replacing or altering Firefox Firefox is still considered open source, correct? From what I know, open source software is meant to be altered.
  - Wowfunhappy 7y ago
    They mean altering the compiled executable without the users knowledge.

callahad 7y ago

That's covered at https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/ https://blog.mozilla.org/addons/2015/04/15/the-case-for-exte..., which is linked from ekr's post. I encourage you to read the rationale as a whole, but the specific question you're asking is addressed here: > Many developers have asked why we can’t make this a runtime option or preference. There is nowhere we could store that choice on the user’s machine that these greyware apps couldn’t change and plausibly claim they were acting on behalf of the user’s “choice” not to opt-out of the light grey checkbox on page 43 of their EULA. This is not a concern about hypotheticals, we have many documented cases of add-ons disabling the mechanisms through which we inform users and give them control over their add-ons. By baking the signing requirement into the executable these programs will either have to submit to our review process or take the blatant malware step of replacing or altering Firefox. We are sure some will take that step, but it won’t be an attractive option for a Fortune 500 plugin vendor, popular download sites, or the laptop vendor involved in distributing Superfish. For the ones who do, we hope that modifying another program’s executable code is blatant enough that security software vendors will take action and stop letting these programs hide behind terms buried in their user-hostile EULAs.

Wowfunhappy 7y ago
Does Windows et al really not provide a mechinism for saving privileged settings in a tamper-resistant way? I frankly find that hard to believe. How does other software solve this problem? There are of course always workarounds on an open platform like Windows/Mac/Linux, but the threshold isn’t “impossible”, it’s just “as difficult as injecting into the browser’s code.” Edit: For example, what if the config file contained a checksum of the file's contents + the user's hardware? If the setting is changed by the user within Firefox, the checksum is updated and everything works—if the checksum is invalid, settings are reset to the default. Video games will occasionally do this type of thing with their config files. Modders often figure out the formula—but again, the idea here isn't to make editing the file impossible, it's to make it as difficult as injecting into the Firefox executable.
- kccqzy 7y ago
  I frankly find that easy to believe. After all, operating systems give desktop apps a lot of trust because they trust these desktop apps to respect the users' trust. It is very recent that we now have desktop apps running potentially untrusted code that can subvert the trusted desktop app. Of course, there are ways but just none are convenient. Generally the well established security boundaries are between the operating system and the user, and then between different users. Almost all the ways I can think of involves Firefox temporarily elevating privileges, which is undesirable.
- djsumdog 7y ago
  I mean, the Windows UAC and the MacOS password prompt that elevate user access, but people often click through those. I can see their argument here.
  - TeMPOraL 7y ago
    No amount of security measures can stop users from being tricked by social engineering attack into self-pwnig themselves. At some point we need to stop taking control away from users, because this road ultimately leads to turning computers into cable TV.
- TazeTSchnitzel 7y ago
  macOS's System Integrity Protection, aka rootless, means that, yes, macOS has a way to store settings that even root can't normally touch, though I suspect only Apple can make proper use of that right now. But Windows? A sadder story, I think.
- temac 7y ago
  Windows starts to have something but it is only available in last versions of Windows 10, probably not enabled by default, and the model might not be exactly what is needed anyway. I don't even remember what it is supposed to protect against precisely -- and MS does not do a lot of communication about it. They maybe don't officially consider it a security boundary (same as UAC). Mozilla seems to be concerned about attackers having admin privileges (but that are still shy of just plainly hacking the Firefox binary or something crazy like that): quite hard to defend against that... and if you can, that means the user actually has lost some control over its own computer, which is a situation which has its own issues.
pbhjpbhj 7y ago
So that means going forward if Mozilla don't want you to have an add-on then you won't be able to enable it?
- nocman 7y ago
  Unless you run an unbranded builds ( https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded_Builds https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded... ), or the Developer Edition ( https://www.mozilla.org/en-US/firefox/developer/ https://www.mozilla.org/en-US/firefox/developer/ ), where setting xpinstall.signatures.required to false still works, then yes, Mozilla can prevent you from using an add-on. More than "going forward", this has been the case for a while now. It's been long enough ago that they disabled that setting in stock Firefox that I don't remember exactly when it happened.
  - AnaniasAnanas 7y ago
    Sadly the unbranded builds do not have updates enabled and the developer edition is basically beta.
    - Wowfunhappy 7y ago
      Wait, why the heck don't the unbranded builds auto-update? To what purpose?
- callahad 7y ago
  We do not take an editorial stance on add-on content with regard to signing, but we do have the ability to block add-ons that are malicious or which violate user privacy and security. We hope those choices will be few and far between, and that our users will agree with them. Our Add-on Policy is discussed further at https://blog.mozilla.org/addons/2019/05/02/add-on-policy-and-process-updates/ https://blog.mozilla.org/addons/2019/05/02/add-on-policy-and...
  - Silhouette 7y ago
    FWIW, I was genuinely shocked that this could happen, and it has severely damaged my trust in Firefox. I am extremely wary, having been bitten more than once, about software that automatically updates itself or is otherwise subject to remote interference. I don't run Windows 10. I don't use Chrome for anything important. I avoid subscription-based or activation-required software as much as possible. And in Firefox, I specifically chose to be prompted to install updates (which I usually do immediately, but it's my choice and I can do a quick search first in case there ever is a problem being widely reported). I find the argument that it's impossible to make this configurable because malware could then circumvent it very weak. If we're talking about that level of interference, anyone with access to the Firefox executable could in theory replace it, and given the open source nature of the Firefox codebase this wouldn't be particularly difficult technically for anyone willing to go to such lengths in the first place. In any case, even if the argument about hard-coding protection into the executable did stand up to scrutiny, there are alternatives possible instead of retrospectively disabling addons with no possible workaround. Perhaps most obviously, you could show a warning message and require explicit user approval at startup before activating the addon, for example, as is already done with various other useful features that are also potentially open to abuse. As things stand, far from protecting our privacy and security from malicious addons, the current system in fact deactivated all of our privacy- and security-protecting addons, without warning, right in the middle of browsing sessions. One of these seems to be very much worse than the other in terms of the risks created, and I urge you to consider that when deciding how addons are treated in the future.
greendestiny_re 7y ago
>or take the blatant malware step of replacing or altering Firefox Firefox is still considered open source, correct? From what I know, open source software is meant to be altered.
- Wowfunhappy 7y ago
  They mean altering the compiled executable without the users knowledge.