Hacker News Reader

Comment by bhauer | Hacker News Reader

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 installation time and should (IMO) run as-is. It seems unnecessary to continuously check the status of an add-on's certificate if it has not been changed. Am I missing something?

View on HN

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.

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.

There's already an extension banlist.

See profile/blocklist-addons.json

Not sure how not renewing a certificate and letting everything get disabled is useful. It's only useful if cert key leaks.

> Mozilla needs to be able to do something about it.

No, they do not need to. They decided that they want to. Remember that there was a time before certificate signing.

And now the decision to be able protect those who install crapware is also harming those who never had those issues.

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.

You cannot rely on “check at install time.” An extension could be installed by a crapware installer behind FF’s back. You can’t go and remember the trust state at install time either, because that memory would need to be kept locally and could be modified by a crapware installer. So the only solution that prevents circumventing the check is to check the signature when the extension is loaded.

It's already a mess. I disabled the signing/recompiled Firefox, and all my extensions were still force disabled with no UI to enable them. So there's some memory/extension state there already.

I had to go thorugh profile/extensions.json and set appDisabled to false to make my extensions enableable again.

I believe it's set up this way specifically to allow revocation for addons that are initially approved but later found to be malicious.

If it is, without requesting user authorisation, then that's an illegal act under the UK Computer Misuse Act (and the USA's CFAA I think too) - modification of a computer without authorisation.

except you agreed and authorized when you installed the software. Take your position to the logical extreme - software can't make any changes without explicit, interactive approval; and you thought UAC was bad.

I look forward to joining your class-action lawsuit.

When the changes are unexpected, yes, further explicit authorisation is required. Just because you installed a photo-album app doesn't let the distributor delete all your photos, say.

Besides that, this sort of "but we hid something in the t&c-s so now we can shit on you" is the sort of thing I expect from over commercialised companies, not from what was once a paragon of the FOSS community.

FWIW class-actions don't exist in UK.

How do you know if it has not been changed?

Signing just verifies the .xpi file. If the addon has managed to get enough permissions to modify it's .xpi file it can bypass the signing requirement in various ways.

Revocation is, I think, the actual reason.

Reply on news.ycombinator.com