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.

No.

All it proves is that certificates expire (which is a Good Thing (tm)). If you depend on online certificates to verify content, something like this can theoretically happen.

Hypothetically, lets say they took the opposite approach, and only checked the certificate date on installation. What would have happened? There would have been a brief period of time where people couldn't install extensions, it would have been fixed in a few hours, and this story would probably have like 20 upvotes and fallen off the front page in like 10 minutes, if it ever got there in the first place.

Now let's briefly look at what's actually taking place: a bunch of people's browsers broke. It broke in scary ways for some people that were using extensions for privacy; IE, their security might have been compromised by this decision by Mozilla. Mozilla is probably going to lose users over this. Their reputation is damaged. Not only that, but now people are evaluating other decisions that Mozilla has made separately from this in an unfavorable light (Studies and Normandy, specifically). The computing industry loses out on this too: we're all better off for chrome having a viable open source competitor. We should want Mozilla to do well, whether you use their browser or not.

Which outcome do you think Mozilla engineers would be preferring today?

Sounds like a good thing. Probably sounds like a good thing to some of the engineers at Mozilla.

The computing industry loses out on this too: we're all better off for chrome having a viable open source competitor.

I want a free competitor, not an open source one. And this is the most prominent example of that somewhat subtle distinction: Firefox is open source, but with all these backdoors it's no longer free, neither in spirit nor in practice.

P.S. On the other hand, it's probably indeed better to have at least two serious competing browsers, even if they are both non-free.

Instead of disabling this historically working feature which normally works great against hostile attacks such as MITM and malware this problem would've been avoided by a simple cron script which runs daily, and checks for expired certificates used within the infrastructure (both interaly used and externally used).

The main competitor you mention, Google Chrome, is a terrible privacy hazard. This situation does not change that.

As to your argument about security: doing the check on install instead of all the time, as I suggest is preferable, still protects against MITM and malware. The only argument for expiring software based on a calendar is that it might be a security risk if it's out of date. But first off, that is highly dependent on what the extension actually does. Also clearly we can see it's also a security risk to turn off privacy extensions without warning based on an arbitrary signing certificate.

> > I'm not putting words in your mouth [..]

Yes, you did:

> "So you think [..]"

I also did a bunch of sketchy registry hacks to fix that. (I keep up to date, but I don't need microsoft restarting my system at random hours)

If users don't want to stay up to date, that may be unwise, but that's there call.

If you're worried about a cert being compromised long after expiration and used to back-date a signature, you can show a warning, add a second signature with a local key at time of installation, use a blockchain to prove age, have a timestamping service generate its own signature at time of generation, etc.

You cannot rely on check at extension install. That would assume that all malicious extensions are installed via FF proper. Oracles crapware bundling in the Java installer taught us that’s now how things go. You cannot remember the trust flag when an extension is installed via FF as a crapware installer could just set the trust flag, too. After all, that storage would be accessible, too. You cannot sign or encrypt that trust storage as the key material would have to be kept locally and would be accessible to the crapware installer.

And I most definitely don’t want my browser to fail into an unsafe configuration.

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.

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.

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.

"A certificate chain has expired, do you want to disable all add-ons?"

How hard is that?

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.

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.

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.

“I wish it would do that.” is a much more charitable way to phrase your complaint.

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).

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).

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.

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.

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 :(

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.

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

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?

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?

It's a classic and ongoing debate of "who knows best?" -- the vendor, or the end user?

This doesn't need to be done through a dead man's switch (expiring certificate) that someone will forget to renew.

Eorum est humanum.