1549139 - Never automatically disable extensions (addons) without explicit user's permission

Status: RESOLVED INVALID

(Toolkit :: Add-ons Manager, defect)

Description

[vleet]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

Use stable up to date Firefox. That's enough for issue to step in.

Yesterday's fail (#1548973) showed that disabling addons on the run with loaded pages/tabs and WITHOUT explicit user's permission was a terrible idea. Especially on the run, for already loaded pages.

One of the biggest security fails of all times for Firefox.

A lot of addons are security-related, and they all were turned off on the run leaving users unprotected, destroying the whole principle of security of Mozilla Firefox. Turned off without any heads up, like that.

It's better to allow user to disable cert-check than to fail big time like that and ruin advanced user's Security MUCH MORE.

It's like if NASA were making a space suit that can instantly disappear without any request from the man (e.g. because the suit is 3 seconds expired) and leave him in outer space with no protection.
Ridiculous, it's it?
But now Firefox works exactly this way!

Actual results:

Extensions (including security-related) were suddenly turned off without any questions to using in RUNNING instances of Firefox and tabs because of bug #1548973

Expected results:

Firefox must keep users secure and allow them to work with their addons at least before users are explicitly agree to disable addon (does not matter what the reasoning of disabling is).

Comment 1

[Robert Longson [:longsonr]]

What if we happen to discover an addon is actually malware and is stealing your bank details? That's why signing was introduced in the first place and does seem to have been effective in solving that problem (something that happened daily back then).

Comment 2

[vleet]

(In reply to Robert Longson [:longsonr] from comment #1)

What if we happen to discover an addon is actually malware and is stealing your bank details? That's why signing was introduced in the first place and does seem to have been effective in solving that problem (something that happened daily back then).

Thank Robert for fast response.

There should be a revoke procedure - the message with huge warning should be shown to user that will push him to agree to disable it or take responsibility (actually share it, because he installed it from Mozilla as a non-malware one).

Also expired cert is super-minor issue when you compare it to the revoke of malware extension.
But disabling addons without user's permission (as happen yesterday for millions of users) is NO GO.

A lot of Reddit users also think that current procedure of automatic addon disabling without user approval is unexceptable and back-fired big time yesterday, especially from the Security point of view.
Disabling addons without user approval on the run can be a way bigger Security flaw than e.g. cert being expired.

P.S. I personally think expired valid certs should be possible to ignore completely by advanced user, because user can have old version of Firefox on OFFLINE computer or more possibly offline VM, e.g. to open MAFF-files that are not supported by Quantum as you know, and there is no reason to break his Firefox setup at some date.

Comment 3

[vleet]

Opinion of gHacks on this matter to build up my point further:

by Martin Brinkmann on May 05, 2019
What Mozilla needs to do now (after cert add-on disabling disaster) - gHacks Tech News
https://www.ghacks.net/2019/05/05/what-mozilla-needs-to-do-now-after-cert-add-on-disabling-disaster/

...
Going forward, Mozilla needs to change the system to make sure that something like this never happens again.
...
Better, in my opinion, is an updated system that never blocks or disables extensions installed by the user
unless they are blacklisted by Mozilla. In other words: a certificate issue, especially one where the error
is caused on Mozilla's side of things, should never lead to users losing access to their extensions.
...

I think, the point is clear - the current approach with disabling addons on the run is unacceptable on many levels.

Comment 4

[vleet]

Why is it still "UNCONFIRMED"? What confirmation do you need?

The huge addon-fail happened and EVERYSON using release version was left without their addons including SECURITY addons.
So, whom exactly do you expect to confirm that extensions were automatically disabled without user's approval, including SECURITY ones?

This kind of security debacle must not ever happen again, are there any other opinions?

Guys, make Firefox even better! Trust users and community more.

Comment 5

[Andrew Swan [:aswan]]

There's nothing actionable in this report. The signing issues were bugs, so this report amounts to "don't ever ship code that contains bugs". We're working on many follow-ups to prevent this paritcular issue from recurring as well as applying more general lessons. Providing an option to disable signing altogether has been discussed at length elsewhere. If you have other specific suggestions, you're welcome to bring them up but generalized ranting isn't helpful.

Comment 6

[Ryan Hendrickson [rhendric on GitLab, GitHub]]

Hey Andrew, is there a list yet of the follow-ups being worked on that you mention, or a Bugzilla tag or something?

There's one approach in particular which I think would merit some consideration, if it isn't already being looked into. That would be switching to a model where each Firefox release ships with a fixed set of non-expiring keys that it uses to validate add-ons, with those keys being incrementally replaced over a period of years instead of making keys expire after some number of years. There's a short discussion of this on Discourse here, if you can ignore the initial ranting and just focus on the constructive proposal.

I'm hesitant to push hard for this right now given how Moz is probably being swamped dealing with the problem, the post-mortem, and no doubt the large numbers of people piling on the various issue trackers to rant unconstructively, but is there a best option to engage in constructive discussion of possible changes to the signing policy like the above that aren't just rolling the whole thing back? Or is the most helpful thing I can do to wait a few weeks and then make such proposals?

Comment 7

[Tomislav Jovanovic :zombie]

Something similar to what you're describing is already how it works, except there is no such thing as a "non-expiring key" in standard practice.

Bug 1549018 is one of the places where this will be hashed out.

Comment 8

[Andrew Swan [:aswan]]

(In reply to Ryan Hendrickson [rhendric on GitLab, GitHub] from comment #6)

Hey Andrew, is there a list yet of the follow-ups being worked on that you mention, or a Bugzilla tag or something?

You can search bugzilla for bugs with the string "cert2019" in the whiteboard filed. Given how fresh this all is and how quickly bugs are still being filed/categorized/duped/etc its probably not practical to get a complete up-to-the-minute list but that should be pretty close.

There's one approach in particular which I think would merit some consideration, if it isn't already being looked into. That would be switching to a model where each Firefox release ships with a fixed set of non-expiring keys that it uses to validate add-ons, with those keys being incrementally replaced over a period of years instead of making keys expire after some number of years. There's a short discussion of this on Discourse here, if you can ignore the initial ranting and just focus on the constructive proposal.

I'm far from an expert in this area but I'm not sure how it would work in practice. Suppose we ship a new key in Firefox 68 but it also still has one or more old keys. When do we start signing addons with that new key? Because once we do, nobody still using Firefox 67 or older will be able to install that addon. That's not necessarily a deal-breaker, we don't make any commitment to support older versions indefinitely, but there are still many people out there using very old versions anyway.

I'm hesitant to push hard for this right now given how Moz is probably being swamped dealing with the problem, the post-mortem, and no doubt the large numbers of people piling on the various issue trackers to rant unconstructively, but is there a best option to engage in constructive discussion of possible changes to the signing policy like the above that aren't just rolling the whole thing back? Or is the most helpful thing I can do to wait a few weeks and then make such proposals?

That's a great question. Bugzilla is obviously not the right place, and discourse is more focused on end-user support. As old-school as they are, I think our dev-* mailing lists are as good a place as any to discuss larger design/architectural issues (such as the overall model for signature verification). The addons development list is https://mail.mozilla.org/listinfo/dev-addons

Comment 9

[vleet]

(In reply to Andrew Swan [:aswan] from comment #5)

There's nothing actionable in this report. The signing issues were bugs, so this report amounts to "don't ever ship code that contains bugs".

You are not right. Where do I tell that problem is in some kind of bug?

The problem is that extensions were turned off ON RUN, when user was on loaded pages leaving him insecure to malware, spytrackers and other stuff.
It's not a bug, it's how Firefox acts now in case of cert getting outdated or invalid for any reason.
This can be easily prevented in future. Mozilla always stood for Security, so in this case I hope it will again.

Do you use at least several security addons yourself?
If not, maybe that's why you do not understand the real problem (not talking about cert bug) and being biased to block this issue unresolved? Be objective, it's important.

(In reply to Andrew Swan [:aswan] from comment #5)

If you have other specific suggestions, you're welcome to bring them up but generalized ranting isn't helpful.

Can you please re-read the original 1-3 messages instead of being aggressive?
The information how to make security better is described there - expired addons should never me be automatically disabled ON RUN without explicit user's permission, because it has much higher SECURITY consequences than the whole addon signing.

I hope you will re-read the bug report and remove RESOLVED INVALID flag, otherwise it will be step in wrong direction. Thanks.

=============
Once more, this issue is not about certs and signing, it's about browser behavior with loaded addons on run, during work and surfing.