3 ms·

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 ef

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 8y 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 8y 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 8y 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 8y 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.
    - Xylakant 8y ago
      No, you can complain. I specifically object to “How hard is that?” which is an entire class in itself. Stuff often is inherently hard and when you don’t know internals of a project and don’t work on it, you may have no concept of how hard it is. Don’t pretend you do. Saying “How hard is that?” carries the notion that everyone working on that thing you don’t know is sloppy, malignant or stupid. “I wish it would do that.” is a much more charitable way to phrase your complaint.
      - pbhjpbhj 8y ago
        Are you saying you don't think that Mozilla have the capabilities; I'm not. My "how hard is that [for Mozilla]?" is specifically "I think they have the capabilities but chose differently, but if I'm mistaken and there is a technological bar to this then please correct me". That's why I didn't write "That's easy!", nor "How hard is that!", but used "how hard is that?" -- the implication is that's not hard for them to do so why did they chose to do it differently. As it happens I've just had to flip "xpinstall.signatures.required" and it's working for me. So it seems "not at all hard [for them]" was the answer. FWIW people have chipped in saying this specific issue was raised, so it's not that they hadn't conceived that such a situation could occur (indeed that's surely why the config above exists).
- human20190310 8y ago
  > there was a hidden dead-mans handle that's been triggered The add-ons were signed by a certificate with an expiration date, which means that the add-ons are trusted until that certificate expires, not that they're trusted in perpetuity. It's not a hidden dead-mans hand; expiry is and has always been part of the process. I think it's arguable that it shouldn't be part of the process, and having things like 20-year expiry satisfies the letter of the spec while being even worse than no expiry, but it's not a hidden dead-man's hand. It's how it was designed to work, and isn't considered optional.

Karunamon 8y 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 8y 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 8y 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 8y 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.
  - Xylakant 8y ago
    No, you can complain. I specifically object to “How hard is that?” which is an entire class in itself. Stuff often is inherently hard and when you don’t know internals of a project and don’t work on it, you may have no concept of how hard it is. Don’t pretend you do. Saying “How hard is that?” carries the notion that everyone working on that thing you don’t know is sloppy, malignant or stupid. “I wish it would do that.” is a much more charitable way to phrase your complaint.
    - pbhjpbhj 8y ago
      Are you saying you don't think that Mozilla have the capabilities; I'm not. My "how hard is that [for Mozilla]?" is specifically "I think they have the capabilities but chose differently, but if I'm mistaken and there is a technological bar to this then please correct me". That's why I didn't write "That's easy!", nor "How hard is that!", but used "how hard is that?" -- the implication is that's not hard for them to do so why did they chose to do it differently. As it happens I've just had to flip "xpinstall.signatures.required" and it's working for me. So it seems "not at all hard [for them]" was the answer. FWIW people have chipped in saying this specific issue was raised, so it's not that they hadn't conceived that such a situation could occur (indeed that's surely why the config above exists).
human20190310 8y ago
> there was a hidden dead-mans handle that's been triggered The add-ons were signed by a certificate with an expiration date, which means that the add-ons are trusted until that certificate expires, not that they're trusted in perpetuity. It's not a hidden dead-mans hand; expiry is and has always been part of the process. I think it's arguable that it shouldn't be part of the process, and having things like 20-year expiry satisfies the letter of the spec while being even worse than no expiry, but it's not a hidden dead-man's hand. It's how it was designed to work, and isn't considered optional.