5 ms·
TLDR: People complained so we're back-pedaling. There are good technical reasons for requiring signed add-ons. Well, maybe not so much "good" but necessary bec
by whoopdedo 11y ago
TLDR: People complained so we're back-pedaling.
There are good technical reasons for requiring signed add-ons. Well, maybe not so much "good" but necessary because of other bad things in Firefox that prevent a less extreme requirement from being implemented.
But the signing requirement isn't what upsets anyone. It's that add-ons must be signed _only by Mozilla_. The whole mess could have been avoided from the start by saying that add-ons must be signed by a trusted certificate but the end-user gets to choose what certificates are trusted.
- comex 11y agoI don't think that would work very well. After all, the list of certificates would have to be a preference, so crapware could just stick its own certificate into the preferences file before installing its addon. Of course, baking the requirement into the binary isn't perfect either, since the crapware can just patch or replace it if it has sufficient access rights, but I'd say it 'feels' drastic in a way changing preferences doesn't (which matters if the crapware is trying to be semi-legitimate), and it requires somewhat more work to come up with a suitable binary and keep it up to date.
- tenfingers 11y agoEasy: just provide a certificate that cannot be changed within FF (must be modified by changing a file in the installation directory). No preference needed. This would allow developers to roll their own, and organizations to allow their custom policy as well (which could mean that the privileges of the user himself aren't sufficient to change the cert). There's really no reason as of why this couldn't be implemented properly. There' also no reason to not include a switch for it, really. This is all just smoke: most users have the privileges to change the FF binary, meaning that in most contextes malware has too (either through social manipulation or through exploits).
- jMyles 11y ago> good technical reasons For forcing signed add-ons? Maybe. Mayyybe. For removing the ability to opt-out of this requirement via the preference? What's the good technical reason?
- JohnTHaller 11y agoBecause a third party app on Windows can edit the Firefox preferences file to set the opt-out preference and then install its unsigned malware/spying/ad-injecting extension and it'll be loaded the next time Firefox starts up with no warning to the user. This is why Chrome hashes its settings files on Windows so that when any 3rd party app tries to mess with it, it wipes all extensions and extension settings and resets the homepage and search engine to the defaults. Unfortunately this also means that you can't move your Chrome settings to another PC as they'll all get reset. You have to sync to Google to ensure all your settings aren't wiped by a badware app or a corrupt byte in the Chrome settings file.
- currysausage 11y agoPretty fascinating. How do they store the hash?
- kuschku 11y agoOn the Google sync servers, that's the trick.
- JohnTHaller 11y agoIt's synced to the Google servers, but the hashes are within the settings file itself. I'm unsure if the code is public, though, as it is not part of Chromium. The downside is that an unaware user that prefers not to sync their stuff to Google and fastidiously backs up all their user settings in Windows is going to lose everything they have stored in Chrome except their bookmarks and passwords if their computer dies or they try to move to a new one.
- ambrop7 11y agoThe security of the browser is conditional on the security of the platform in the first place, so this does not make sense. Anything that can edit the settings of the browser without its knowledge can interfere with the browser and other software in other bad ways. It especially does not make sense for users who actually do have a reasonably secure platform, and these "security features" are then purely an annoyance.