Live data from Hacker News

Update Regarding Add-Ons in Firefox

blog.mozilla.org

181–190 of 504 posts

Re: Update Regarding Add-Ons in Firefox

#181

Earlier quoted context omitted.

But that represents how people consider trust when choosing addons. It's trusting the code and company at the time of install, not at an arbitrary later time. Sure, if the cert expires and there's an update then the user wants to know.

The main trust check is at installation time, but it's possible for problems to be discovered later, and Mozilla needs to be able to do something about it. Certificate non-renewal is the only robust avenue of revocation.

They should absolutely have asked extra permission to implement a system where they could choose to alter my browser install, in an unexpected way, at their behest without seeking further authorisation, not even a modal???

It's exceedingly poor ethics.

Re: Update Regarding Add-Ons in Firefox

#182
Certificate expirations show up on causes of outage lists so frequently, yet little has been done to address the underlying issues of how PKI works to address it. The core issue of time limits on trust and no specs and requirements on how to handle the most common case of saying “yes, this is still trusted” is oddly absent.

Could we have for example a publicly verifiable ledger that can be used to verify a cert chain with not only a defined workflow to answer if a cert is still trusted but also a requirement for the workflow to be fully implemented? Seems quite doable, vs sort of hacks of auto-renew which are hit and miss depending on the CA.

In other words, when do we fix the sport rather than the players here?

Re: Update Regarding Add-Ons in Firefox

#183
post #87

Earlier quoted context omitted.

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?

revocation != expiry

Re: Update Regarding Add-Ons in Firefox

#184
post #145

Earlier quoted context omitted.

> And to the downvoters: doesn't this entire fiasco ENTIRELY PROVE MY POINT? 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.

So you think Mozilla is enjoying this right now? And that this is going to help the perception and market share of Firefox? 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…

You are putting words in my mouth, please stop that.

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.

Re: Update Regarding Add-Ons in Firefox

#185
post #158

I'm not gonna bother with 'studies' or manual workaround - I'm just going to wait for an update. In the meantime I'm enjoying trying out Vivaldi[1] - really reminds me of opera 3/4, that I loved. 1: https://vivaldi.com

Will Vivaldi let me put the tabs on bottom where they belong?

What? Tabs belong on the side. In a tree. ;-)

Re: Update Regarding Add-Ons in Firefox

#186
post #12

Mozilla has been on the downward spiral over the last several years. They took something (i.e. Firefox) that wasn't broken and "fixed" it until it was, first by killing off XPCOM and then suffering through the misadventures of such bastard products as Firefox OS. The folks at Mozilla should really stick to what their good at and focus on an all around open source browser that people will actually WANT to use.

Mozilla killed XPCOM because it was actively preventing improving Firefox. In particular, Firefox could finally go multiprocess, and other improvements of the Quantum project are slowly being incorporated.

A lot of people don't view that (or other changes) as improvement. I personally hate multi-process browsers because they eat RAM like nothing else. In my browser of choice I normally run 200-500 active tabs and I stay under ~3 GB of ram usage. With a multi-process browser that'd be impossible.

Re: Update Regarding Add-Ons in Firefox

#187

Earlier quoted context omitted.

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

checking revocations lists != certificate expiry

At a the technical level of cert handling, yes. To the user? Not so sure.

Re: Update Regarding Add-Ons in Firefox

#188

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

Looking at the changeset [1], I'm curious why the explicit check for expiry (line 644/646) didn't work. Unfortunately the mentioned bug is rather light on details; presumably they were collaborating on IRC or something instead.

[1] GitHub mirror to not stress their infra: https://github.com/mozilla/gecko-dev/commit/1d1260c7615f1d9a...

Re: Update Regarding Add-Ons in Firefox

#189
Assuming I understand it correctly the reason the addons stopped working is because an intermediate certificate they were signed with expired, question is - when and why are already installed and running addons are being revalidated every time (and when exactly ?), does this serve any user-aligned purpose or is just means for mozilla to exercise control over addon publishers ?

Re: Update Regarding Add-Ons in Firefox

#190

Earlier quoted context omitted.

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?

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

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.

Post reply on HN