Live data from Hacker News

Update Regarding Add-Ons in Firefox

blog.mozilla.org

101–110 of 504 posts

Re: Update Regarding Add-Ons in Firefox

#101
post #87

Earlier quoted context omitted.

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 n…

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.

What's the difference to the user between "to check revocations too, sure" and what happened?

Re: Update Regarding Add-Ons in Firefox

#102
post #74

I'm interested in the general writeup what went wrong that they missed this certificate expiring. That's a structural problem. Also why it took 6 hrs to assign P1 to the bug

I'm also interested in why existing adds-ons are failing to run due to this problem. (There was a similar question in another thread about the issue here at HN.) I understand why an add-on update or new installation would be prevented from succeeding by a certificate expiration. But why would a certificate expiration prevent an already-installed from running? Any already-installed add-ons were previously validated at…

When a certificate is no longer valid, the authority it represents expires too. Grandfathering trust in various places would make cert management even more difficult to get right, because there'd be no hard deadline when a certificate is no longer in force.

Re: Update Regarding Add-Ons in Firefox

#103
post #93

Earlier quoted context omitted.

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.

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.

So you are saying there should be no way for an installed addon to fail an integrity check?

Re: Update Regarding Add-Ons in Firefox

#104
post #67

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 & re…

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 n…

This is bad design. Installed software shouldn't just stop working because the clock ticked.

(And yes, I know browsers should stay up to date etc. etc., but come on, no software should just stop functioning because of a calendar)

And to the downvoters: doesn't this entire fiasco ENTIRELY PROVE MY POINT?

Re: Update Regarding Add-Ons in Firefox

#105

Earlier quoted context omitted.

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 n…

This is bad design. Installed software shouldn't just stop working because the clock ticked. (And yes, I know browsers should stay up to date etc. etc., but come on, no software should just stop functioning because of a calendar) And to the downvoters: doesn't this entire fiasco ENTIRELY PROVE MY POINT?

No, I totally agree with that (I just edited to expand on this point). It was a bad user experience.

Re: Update Regarding Add-Ons in Firefox

#106
post #77

Earlier quoted context omitted.

This is one of the things about this whole episode that I find baffling. Stuff like adjusting bug priorities and arranging for someone to tweet an announcement is the work of a good engineering manager. This is the right person to run interference and handle comms and deal with things outside of the critical path, like bugzilla updates.

The priority field just plays no practical role here since the bug was immediately escalated.

If people can see it externally it definitely has an effect, "oh moz aren't taking this browser breaking bug seriously". Which is probably why the parent said it's a management issue rather than a directly technical one, per se.

Re: Update Regarding Add-Ons in Firefox

#107
post #78
post #67

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 & re…

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.

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!"

Re: Update Regarding Add-Ons in Firefox

#108
post #21

Earlier quoted context omitted.

I'm not sure I would call it "pointless", they've merged and are merging a lot of the code they used servo to experiment with into firefox. Of everything mozilla has done recently, Servo is one of the things I'm most positive about.

I'm sure your parent comment was being sarcastic. The quotes were missing.

You're probably right, oops.

Re: Update Regarding Add-Ons in Firefox

#109
Granted I'm using Nightly (and previously disabled extension signing in about:config), but now all my themes are disabled, even the default one apparently, though that is what it is using. Cannot be re-enabled. When do I get my dark theme back?

Also...my default search engine is now Amazon.com?? WTF is going on.

EDIT: Also my only search engine. Heck of a job Mozilla.

Re: Update Regarding Add-Ons in Firefox

#110
post #93

Earlier quoted context omitted.

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.

So you are saying there should be no way for an installed addon to fail an integrity check?

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?

Post reply on HN