7 ms·
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
by bhauer 7y ago
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?
- 0xffff2 7y agoI believe it's set up this way specifically to allow revocation for addons that are initially approved but later found to be malicious.
- pbhjpbhj 7y agoIf 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.
- usecontainers 7y agoexcept 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.
- pbhjpbhj 7y agoWhen 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.
- lugg 7y agoHow do you know if it has not been changed?
- gpm 7y agoSigning 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.
- firethief 7y agoWhen 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.
- pbhjpbhj 7y agoBut 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.
- deleted 7y ago[deleted]
- firethief 7y agoThe 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.
- megous 7y agoThere'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.
- the8472 7y ago> 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.
- pbhjpbhj 7y agoThey 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.