8 ms·

I have a bunch of privacy-enhancing addons installed, which have now all been disabled. If I hadn't read HN this morning, I wouldn't even have known why. Until

I have a bunch of privacy-enhancing addons installed, which have now all been disabled. If I hadn't read HN this morning, I wouldn't even have known why. Until now, I had no idea that it was even possible to remotely disable my addons. And now Mozilla are saying that the "fix" is to allow them to install & run "studies" on my machine? What are they smoking? I'm having a hard time trusting a company that randomly & remotely disabled all my addons, regardless of the cause.

zamadatix 7y ago
Not initiated by user != remotely initiated. And agreed no the fix side, they should have posted how to do it yourself as well.
sgift 7y ago
No one remotely disabled anything. There's a certificate deployed with Firefox. The certificate Firefox used to check addons was only valid till yesterday. So, when the browser started next time it couldn't validate the addons and disabled them. That all happened locally.
- overgard 7y ago
  You could say it was remotely disabled by design. What other piece of software randomly just breaks because of the calendar date? I can boot up almost any 20 year old piece of Windows software and it'll work fine, it might not make sense in the current world but it won't go "2019? Fuck off!"
  - Xylakant 7y ago
    And the reason you can install 20 year old windows software without caring about code signing certs is that 20 years ago nobody bothered to sign code.
    - overgard 7y ago
      Not every piece of code needs to be signed. Should my ancient copy of Doom 2 stop working because it's not with the times? Or a level editor for it? Or an old turboC compiler? Some software lives a LONG time and it's fine, and it's up to the user whether that software is still useful to them or not. Seriously how many posts do we see on hacker news about like "We rebuilt this ancient machine from the 1970s to learn about it." People care about computing history. Not everyone, but there's no reason to force your software to break because the calendar rolls over. Remember Y2K? Things often live a LONG time. People are still actively writing Fortran and COBOL. The short-sightedness of this is amazing, as is the condescending "we know what's best for you" security argument.
      - dwaite 7y ago
        Typically software signatures are not just pass/fail, but used to give audited entitlements for API. So a secure system would let you run Doom, but could forbid:' - Access to the filesystem outside the application domain due to potential for exfiltrating or destroying user data - Likewise, access to global system data may be limited - Access to the network due to (raw TCP/UDP) traffic not having been audited for security, and the network connectivity being usable for exfiltration - Access to run full-screen due to the ability to perform user phishing attacks by presenting fake UI. - The ability to disable system-registered keyboard sequences (on windows, such as the windows key or sticky keys) - Access to mouse events outside its window - Access to key scan data, although this likely will be emulated - Access to change display color modes to e.g. 256 color indexed, although this will likely be emulated as well
        overgard 7y ago
        Right but that's why we have sandboxes and virtual machines. There's no need to use a calendar date to enforce security.
  - eh78ssxv2f 7y ago
    > I can boot up almost any 20 year old piece of Windows software and it'll work fine, it might not make sense in the current world but it won't go "2019? Fuck off!" Is that really true? Would it connect to 802.11m WiFi router? Would you consider it secure enough to open your banking website on it? The bar is not just booting up the machine. The bar is whether the machine is usable (secure).
    - overgard 7y ago
      > Would it connect to 802.11m WiFi router? Sure. It's using OS networking APIs. Or running in a virtual machine. > Would you consider it secure enough to open your banking website on it? If I'm running 20 year old software, it's probably to interact with a legacy system. There are still businesses that run on like 486's with Windows 3.1. This is more common than you think! > The bar is whether the machine is usable (secure). The bar is whatever I WANT it to be, it's my machine, and it's pretentious of a software developer to assume they know what I'm using the software for and what my best interests are. For all they know I'm using the software in a museum, 20 years from now, about this era of computing.
      - eh78ssxv2f 7y ago
        > The bar is whatever I WANT it to be, it's my machine, and it's pretentious of a software developer to assume they know what I'm using the software for and what my best interests are. For all they know I'm using the software in a museum, 20 years from now, about this era of computing. I think that's a reasonable point of view. However, for such users, it's best not to use software that's largely developed for masses who just expect the software to work. It might be best to just checkout the source code, and build your own binary. Sorry for being rude :(
      - Faark 7y ago
        > For all they know I'm using the software in a museum, 20 years from now, about this era of computing. And then you'll simulate a time appropriate for the device/software. As a date before 2038 to not have unix time overflow. Or 2000. Or any other time specific bug. Or how often did you have to "fix the internet" for one of your relatives because their damn CMOS battery died? Yeah, time seems to be quite relevant for trust. And I don't even like mozilla enforcing signatures for addons that strongly, but people can go overboard.
Xylakant 7y ago
Your addons have not been remotely disabled. They were marked as trustworthy by a certificate that expired and thus are no longer considered trustworthy. The effect is similar, the mechanism is different. You could also enable loading of unsigned extensions, that would “fix” the issue, too.
- Karunamon 7y ago
  >You could also enable loading of unsigned extensions, that would “fix” the issue, too. Which is impossible unless you're either running Linux or running Nightly or Developer Edition. That setting is willfully ignored in normal Mac/Windows/Android builds most people are on.
- pbhjpbhj 7y ago
  They were effectively remotely disabled, there was a hidden dead-mans handle that's been triggered in order to effect the result; but it's logically equivalent from an end user perspective -- an external agency caused my add-ons to be disabled without my authorisation. "A certificate chain has expired, do you want to disable all add-ons?" How hard is that?
  - Xylakant 7y ago
    > How hard is that? If you think that’s trivial, I challenge you to go build it. It might seem warranted in hindsight, but thinking about all failure cases ahead of time is hard. If it weren’t, we’d not have bugs.
    - pbhjpbhj 7y ago
      Cool, yeah, noone can complain unless they can personally do it all better. Do you think that's workable? I don't think it's trivial. The critical element here appears to be "who gets the final say" and not "this is to hard to code". They manage to disable the "Enable" button for addons, and managed to consider this situation enough to provide a justification that (paraphrasing) "we do this when we don't want the add-on installed", which is harder to do, they've added extra tests, added complexities and done all the consideration. They've just chosen to remove the final say from the user and give it to themselves. It seems consistent with their recent behaviour.
jeromegv 7y ago
They have not remotely disabled addons. The certificate expired and the addons did the correct thing when connection couldn’t be established. Nobody triggered a switch to disable addons.
- Tharkun 7y ago
  If you can disable all my addons by having a certificate expire, you can effectively remotely disable all my addons. And that's exactly what happened. The fact that this was (presumably?) not intentional is irrelevant. The switch may not be an actual switch, but it's there nevertheless. And it shouldn't be.
  - SiempreViernes 7y ago
    So you are saying there should be no way for an installed addon to fail an integrity check?
    - wool_gather 7y ago
      I think Tharkun is saying that there should be a (reasonably accessible) way for a user to choose to override the check's failure. Which is not that far-fetched as a proposal. It's a classic and ongoing debate of "who knows best?" -- the vendor, or the end user?
    - LifeLiverTransp 7y ago
      Yes.. the choice should be taken to the user- and the users choice should trump them all.
      - sgift 7y ago
        If you want full user choice about this you can use nightly or use a community packaged version with the option to disable the checks enabled or compile it yourself and enable the flag. It's not impossible to do that.
    - yawaramin 7y ago
wool_gather 7y ago
This is not entirely accurate. Nothing was done remotely to disable the add-ons. It happened locally. A certificate that's on your machine as part of the Firefox install expired. When that happened, add-ons that were signed via a cert chain that included the expired one started appearing to be invalidly signed. And that's why it requires an update to completely fix. That part is remote, because they need to push a new valid certificate to you to replace the old one. I do think that the UX should ideally be a bit more graceful; one of my add-ons is Multi-account Containers and its being disabled suddenly caused the window I was actively browsing in to just close, among other side effects. But that kind of UX polish for what should be an exceptional case is obviously not going to be super-high priority, unfortunately.
- rauhl 7y ago
  Clearly, downstream distributors need to create a patch which causes their distributes Firefox builds to only check certificates on add-on installation (and to check revocations too, sure): it should never be possible for a browser to fail into an unsafe configuration.
  - wool_gather 7y ago
    What's the difference to the user between "to check revocations too, sure" and what happened?
    - the8472 7y ago
      checking revocations lists != certificate expiry
      - wool_gather 7y ago
        At a the technical level of cert handling, yes. To the user? Not so sure.
      - dwaite 7y ago
        Revocation lists are often tied to certificate expiry, purging entries that are no longer valid due to expiry.
yborg 7y ago
I enjoy a nice cup of outrage in the morning just like the next guy, but this one is really weak and lacks that fresh taste of evil conspiracy that I really crave. You use a browser that has remote update capability, which allows them to install and run new software on your machine all the time. There is a whole separate section of the Preferences that says "Privacy" in large print that has a section that clearly identifies the Studies feature and lets you turn it off. And you use a browser that lets you install privacy-enhancing add-ons in the first place, and in fact which invented the whole concept of add-ons. When the browser discovered that it couldn't verify the add-on integrity with a valid cert, it did what it's supposed to do, it disabled them to protect you from someone backdooring these add-ons. Someone at Mozilla fucked up, and they're trying in good faith to fix it. I don't know what else people are expecting them to do, putting on sackcloth and ashes won't resolve the problem.
- LifeLiverTransp 7y ago
  There is a whole section of buttons that in effect do nothing and are ignored like the windows buttons, but you as a user get the ilusion of choice and power and can busy yourself with this Fun Time Pop Up Farmyard Friends of Privacy. All your entitlement to control your own machine is melting away.
- overgard 7y ago
  Here's the thing, though: yes, we most certainly are giving them a lot of trust by allowing them to install software on our machines. Which means outrage when they screw up is totally justified, because they broke that trust. Here's a metaphor: Let's say you let someone seemingly trustworthy watch your kid. (In this metaphor you have a kid). And they let your kid get a broken arm through gross negligence (let's say they passed out drinking beer), and then someone said "well, obviously, you should have never trusted that person, after all, they can do anything with your kid while you're gone, so why are you outraged?" You probably would still be pretty outraged right? You would certainly question your decision to trust them, but at the end of the day you have to trust someone, you'd be a complete shut-in if you could never hire a baby-sitter.
- philipwhiuk 7y ago
lpcvoid 7y ago
Due to them easily being able to push code without much hastle using Studies, I think this is an elegant-ish solution to a problem that shouldn't even have happened (expired certs are something that's entirely avoidable), but errors happen. Eorum est humanum.
eh78ssxv2f 7y ago
> And now Mozilla are saying that the "fix" is to allow them to install & run "studies" on my machine? What are they smoking? Can you elaborate what's your concern with "studies"? By installing Firefox that updates automatically, the user is already giving control of the software and letting Mozilla decide what's the best. How is modifying software logic using studies different than modifying logic by updating the binary?
- yawaramin 7y ago
  Studies are installed and their data sent to Mozilla without my knowledge or consent. Updates are installed with my consent. Pretty big difference.
  - eh78ssxv2f 7y ago
    Oh, I did not know that. Are you sure that enabling studies also means that user's data is sent to Mozilla without consent? Are you sure about this? I'm asking because there I can imagine that there is a benefit for Mozilla to develop a feature that enables studies without sending data. It could be used to fix a broken feature or a broken logic (as in the case of expired certificates here). So, I'm not convinced that enabling studies always means that your data gets uploaded without the consent. Can you point me to privacy whitepaper / source code to backup that statement?
    - yawaramin 7y ago
      Yes, I am 100% sure. See https://wiki.mozilla.org/Firefox/Shield/Shield_Studies#What_data_do_Shield_Studies_normally_collect.3F https://wiki.mozilla.org/Firefox/Shield/Shield_Studies#What_...
jammygit 7y ago
The problem is that Firefox does not have sufficient built in privacy settings by default. Users shouldn't have to crawl the internet for lists of recommended addons, then have to trust such a variety of authors, to have basic privacy. Like I said elsewhere, I'm using Brave because of this.
- brigandish 7y ago
  I'm also using Brave now, though I did have a quick yearning to dust off Lynx…

zamadatix 7y ago

Not initiated by user != remotely initiated. And agreed no the fix side, they should have posted how to do it yourself as well.

sgift 7y ago

No one remotely disabled anything. There's a certificate deployed with Firefox. The certificate Firefox used to check addons was only valid till yesterday. So, when the browser started next time it couldn't validate the addons and disabled them. That all happened locally.

overgard 7y ago
You could say it was remotely disabled by design. What other piece of software randomly just breaks because of the calendar date? I can boot up almost any 20 year old piece of Windows software and it'll work fine, it might not make sense in the current world but it won't go "2019? Fuck off!"
- Xylakant 7y ago
  And the reason you can install 20 year old windows software without caring about code signing certs is that 20 years ago nobody bothered to sign code.
  - overgard 7y ago
    Not every piece of code needs to be signed. Should my ancient copy of Doom 2 stop working because it's not with the times? Or a level editor for it? Or an old turboC compiler? Some software lives a LONG time and it's fine, and it's up to the user whether that software is still useful to them or not. Seriously how many posts do we see on hacker news about like "We rebuilt this ancient machine from the 1970s to learn about it." People care about computing history. Not everyone, but there's no reason to force your software to break because the calendar rolls over. Remember Y2K? Things often live a LONG time. People are still actively writing Fortran and COBOL. The short-sightedness of this is amazing, as is the condescending "we know what's best for you" security argument.
    - dwaite 7y ago
      Typically software signatures are not just pass/fail, but used to give audited entitlements for API. So a secure system would let you run Doom, but could forbid:' - Access to the filesystem outside the application domain due to potential for exfiltrating or destroying user data - Likewise, access to global system data may be limited - Access to the network due to (raw TCP/UDP) traffic not having been audited for security, and the network connectivity being usable for exfiltration - Access to run full-screen due to the ability to perform user phishing attacks by presenting fake UI. - The ability to disable system-registered keyboard sequences (on windows, such as the windows key or sticky keys) - Access to mouse events outside its window - Access to key scan data, although this likely will be emulated - Access to change display color modes to e.g. 256 color indexed, although this will likely be emulated as well
      - overgard 7y ago
        Right but that's why we have sandboxes and virtual machines. There's no need to use a calendar date to enforce security.
- eh78ssxv2f 7y ago
  > I can boot up almost any 20 year old piece of Windows software and it'll work fine, it might not make sense in the current world but it won't go "2019? Fuck off!" Is that really true? Would it connect to 802.11m WiFi router? Would you consider it secure enough to open your banking website on it? The bar is not just booting up the machine. The bar is whether the machine is usable (secure).
  - overgard 7y ago
    > Would it connect to 802.11m WiFi router? Sure. It's using OS networking APIs. Or running in a virtual machine. > Would you consider it secure enough to open your banking website on it? If I'm running 20 year old software, it's probably to interact with a legacy system. There are still businesses that run on like 486's with Windows 3.1. This is more common than you think! > The bar is whether the machine is usable (secure). The bar is whatever I WANT it to be, it's my machine, and it's pretentious of a software developer to assume they know what I'm using the software for and what my best interests are. For all they know I'm using the software in a museum, 20 years from now, about this era of computing.
    - eh78ssxv2f 7y ago
      > The bar is whatever I WANT it to be, it's my machine, and it's pretentious of a software developer to assume they know what I'm using the software for and what my best interests are. For all they know I'm using the software in a museum, 20 years from now, about this era of computing. I think that's a reasonable point of view. However, for such users, it's best not to use software that's largely developed for masses who just expect the software to work. It might be best to just checkout the source code, and build your own binary. Sorry for being rude :(
    - Faark 7y ago
      > For all they know I'm using the software in a museum, 20 years from now, about this era of computing. And then you'll simulate a time appropriate for the device/software. As a date before 2038 to not have unix time overflow. Or 2000. Or any other time specific bug. Or how often did you have to "fix the internet" for one of your relatives because their damn CMOS battery died? Yeah, time seems to be quite relevant for trust. And I don't even like mozilla enforcing signatures for addons that strongly, but people can go overboard.

Xylakant 7y ago

Your addons have not been remotely disabled. They were marked as trustworthy by a certificate that expired and thus are no longer considered trustworthy. The effect is similar, the mechanism is different. You could also enable loading of unsigned extensions, that would “fix” the issue, too.

Karunamon 7y ago
>You could also enable loading of unsigned extensions, that would “fix” the issue, too. Which is impossible unless you're either running Linux or running Nightly or Developer Edition. That setting is willfully ignored in normal Mac/Windows/Android builds most people are on.
pbhjpbhj 7y ago
They were effectively remotely disabled, there was a hidden dead-mans handle that's been triggered in order to effect the result; but it's logically equivalent from an end user perspective -- an external agency caused my add-ons to be disabled without my authorisation. "A certificate chain has expired, do you want to disable all add-ons?" How hard is that?
- Xylakant 7y ago
  > How hard is that? If you think that’s trivial, I challenge you to go build it. It might seem warranted in hindsight, but thinking about all failure cases ahead of time is hard. If it weren’t, we’d not have bugs.
  - pbhjpbhj 7y ago
    Cool, yeah, noone can complain unless they can personally do it all better. Do you think that's workable? I don't think it's trivial. The critical element here appears to be "who gets the final say" and not "this is to hard to code". They manage to disable the "Enable" button for addons, and managed to consider this situation enough to provide a justification that (paraphrasing) "we do this when we don't want the add-on installed", which is harder to do, they've added extra tests, added complexities and done all the consideration. They've just chosen to remove the final say from the user and give it to themselves. It seems consistent with their recent behaviour.

jeromegv 7y ago

They have not remotely disabled addons. The certificate expired and the addons did the correct thing when connection couldn’t be established. Nobody triggered a switch to disable addons.

Tharkun 7y ago
If you can disable all my addons by having a certificate expire, you can effectively remotely disable all my addons. And that's exactly what happened. The fact that this was (presumably?) not intentional is irrelevant. The switch may not be an actual switch, but it's there nevertheless. And it shouldn't be.
- SiempreViernes 7y ago
  So you are saying there should be no way for an installed addon to fail an integrity check?
  - wool_gather 7y ago
    I think Tharkun is saying that there should be a (reasonably accessible) way for a user to choose to override the check's failure. Which is not that far-fetched as a proposal. It's a classic and ongoing debate of "who knows best?" -- the vendor, or the end user?
  - LifeLiverTransp 7y ago
    Yes.. the choice should be taken to the user- and the users choice should trump them all.
    - sgift 7y ago
      If you want full user choice about this you can use nightly or use a community packaged version with the option to disable the checks enabled or compile it yourself and enable the flag. It's not impossible to do that.
  - yawaramin 7y ago

wool_gather 7y ago

This is not entirely accurate. Nothing was done remotely to disable the add-ons. It happened locally. A certificate that's on your machine as part of the Firefox install expired. When that happened, add-ons that were signed via a cert chain that included the expired one started appearing to be invalidly signed. And that's why it requires an update to completely fix. That part is remote, because they need to push a new valid certificate to you to replace the old one. I do think that the UX should ideally be a bit more graceful; one of my add-ons is Multi-account Containers and its being disabled suddenly caused the window I was actively browsing in to just close, among other side effects. But that kind of UX polish for what should be an exceptional case is obviously not going to be super-high priority, unfortunately.

rauhl 7y ago
Clearly, downstream distributors need to create a patch which causes their distributes Firefox builds to only check certificates on add-on installation (and to check revocations too, sure): it should never be possible for a browser to fail into an unsafe configuration.
- wool_gather 7y ago
  What's the difference to the user between "to check revocations too, sure" and what happened?
  - the8472 7y ago
    checking revocations lists != certificate expiry
    - wool_gather 7y ago
      At a the technical level of cert handling, yes. To the user? Not so sure.
    - dwaite 7y ago
      Revocation lists are often tied to certificate expiry, purging entries that are no longer valid due to expiry.

yborg 7y ago

I enjoy a nice cup of outrage in the morning just like the next guy, but this one is really weak and lacks that fresh taste of evil conspiracy that I really crave. You use a browser that has remote update capability, which allows them to install and run new software on your machine all the time. There is a whole separate section of the Preferences that says "Privacy" in large print that has a section that clearly identifies the Studies feature and lets you turn it off. And you use a browser that lets you install privacy-enhancing add-ons in the first place, and in fact which invented the whole concept of add-ons. When the browser discovered that it couldn't verify the add-on integrity with a valid cert, it did what it's supposed to do, it disabled them to protect you from someone backdooring these add-ons. Someone at Mozilla fucked up, and they're trying in good faith to fix it. I don't know what else people are expecting them to do, putting on sackcloth and ashes won't resolve the problem.

LifeLiverTransp 7y ago
There is a whole section of buttons that in effect do nothing and are ignored like the windows buttons, but you as a user get the ilusion of choice and power and can busy yourself with this Fun Time Pop Up Farmyard Friends of Privacy. All your entitlement to control your own machine is melting away.
overgard 7y ago
Here's the thing, though: yes, we most certainly are giving them a lot of trust by allowing them to install software on our machines. Which means outrage when they screw up is totally justified, because they broke that trust. Here's a metaphor: Let's say you let someone seemingly trustworthy watch your kid. (In this metaphor you have a kid). And they let your kid get a broken arm through gross negligence (let's say they passed out drinking beer), and then someone said "well, obviously, you should have never trusted that person, after all, they can do anything with your kid while you're gone, so why are you outraged?" You probably would still be pretty outraged right? You would certainly question your decision to trust them, but at the end of the day you have to trust someone, you'd be a complete shut-in if you could never hire a baby-sitter.
philipwhiuk 7y ago

lpcvoid 7y ago

Due to them easily being able to push code without much hastle using Studies, I think this is an elegant-ish solution to a problem that shouldn't even have happened (expired certs are something that's entirely avoidable), but errors happen. Eorum est humanum.

eh78ssxv2f 7y ago

> And now Mozilla are saying that the "fix" is to allow them to install & run "studies" on my machine? What are they smoking? Can you elaborate what's your concern with "studies"? By installing Firefox that updates automatically, the user is already giving control of the software and letting Mozilla decide what's the best. How is modifying software logic using studies different than modifying logic by updating the binary?

yawaramin 7y ago
Studies are installed and their data sent to Mozilla without my knowledge or consent. Updates are installed with my consent. Pretty big difference.
- eh78ssxv2f 7y ago
  Oh, I did not know that. Are you sure that enabling studies also means that user's data is sent to Mozilla without consent? Are you sure about this? I'm asking because there I can imagine that there is a benefit for Mozilla to develop a feature that enables studies without sending data. It could be used to fix a broken feature or a broken logic (as in the case of expired certificates here). So, I'm not convinced that enabling studies always means that your data gets uploaded without the consent. Can you point me to privacy whitepaper / source code to backup that statement?
  - yawaramin 7y ago
    Yes, I am 100% sure. See https://wiki.mozilla.org/Firefox/Shield/Shield_Studies#What_data_do_Shield_Studies_normally_collect.3F https://wiki.mozilla.org/Firefox/Shield/Shield_Studies#What_...

jammygit 7y ago

The problem is that Firefox does not have sufficient built in privacy settings by default. Users shouldn't have to crawl the internet for lists of recommended addons, then have to trust such a variety of authors, to have basic privacy. Like I said elsewhere, I'm using Brave because of this.

brigandish 7y ago
I'm also using Brave now, though I did have a quick yearning to dust off Lynx…