Mozilla Firefox Add-On Signing Update
51–60 of 68 posts
Re: Mozilla Firefox Add-On Signing Update
#52Earlier quoted context omitted.
You'd drop Firefox and go to, what, Chrome? The browser that by default sends all your history to Google?
Nope. I use Pale Moon. It's an actively developed full fork of Firefox. All my extensions work in it. It's more Firefox than Firefox these days.
I have used it more or less exclusively for a couple of months and it works nicely everywhere except for some pages with JS developers who manage to write "your browser is not supported" for anything but Chrome.
Re: Mozilla Firefox Add-On Signing Update
#53I'm routinely questioned to do support for users, and I find malware extensions regularly installed in Chrome which has even stricter requirements. The other day I found a laptop with one extension that redirected google.com to a scraper. Chrome did EVEN include a drop-down warning just below the URL bar that the homepage was being currently redirected by an add-on. Did the user notice? Not a bit.
In fact, Chrome adding a WARNING for it made me feel even more sad: they know this is going on. Is FF going to do the same? If I was an user with an extension that did that for whatever reason I wanted, I would be furious as hell to see an added warning which I need to disable (IF possible), and that will be ignored by most users anyway.
Malware developers will just get by faster, so Mozilla will not be able to keep up with the list of addons to blacklist. At the same time, initial approvals for legitimate addons will get slower. Reporting issues with Addons is clearly insufficient as Chrome Store demonstrates. In fact, I'm also NOT ok with the idea that extensions can be blacklisted at all, in spite of that "added security" aura around it. By the same logic, if extensions are required to be signed, then blacklisting (and blacklisting updates) shouldn't be allowed to be disabled.
And, let's remind ourselves, that most of the extensions I've seen installed were side-loaded with other software (with "extras") that was installed in the system with the same privileges of the browsers. So really, I do expect malware to simply patch the FF binary to either disable the check or change the public key, or change it entirely with a patched version.
I do not support walled gardens of any kind. Use a fork.
Re: Mozilla Firefox Add-On Signing Update
#54Still stuck on Firefox 41, they broke too many extensions after that.
Re: Mozilla Firefox Add-On Signing Update
#55Yes it gets messy but they are making it so. I don't want to use a non-release (i.e. possibly buggy) version just so I can sideload an unsigned extension.
Just offer a non-front-page build in the same way they do for EME and let's move on to more important things.
Seriously Mozilla waste so much time and energy discussing all this stuff when it is patently obvious what the right thing to do is.
Re: Mozilla Firefox Add-On Signing Update
#56TLDR: 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 b…
I 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 pre…
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).
Re: Mozilla Firefox Add-On Signing Update
#57Earlier quoted context omitted.
Because 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 reset…
Pretty fascinating. How do they store the hash?
Re: Mozilla Firefox Add-On Signing Update
#58They have the EME build for people who don't want the DRM stuff so why can't they just offer a build with unsigned extensions allowed in a similar way? Yes it gets messy but they are making it so. I don't want to use a non-release (i.e. possibly buggy) version just so I can sideload an unsigned extension. Just offer a non-front-page build in the same way they do for EME and let's move on to more important things. Ser…
From the article that you are commenting on
> at which point unbranded builds based on [...] release will be provided for testing.
The article was 3 paragraphs long.
Re: Mozilla Firefox Add-On Signing Update
#59Earlier quoted context omitted.
Because 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 reset…
The 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.
Just because this practice doesn't apply to or benefit you doesn't mean it doesn't apply to and benefit the majority of browser users. Remember, the majority of Firefox users don't even use extensions at all. Closing this hole would increase their security browser-wise.
Ironic Note: Google Chrome, while attempting to block bundleware from interfering with its own operation, is one of the most widely distributed bundleware apps. Installers that use dark patterns (tricking users to not notice they're installing a new default browser) from Oracle's Java to Adobe Flash to Avast to Antivir all are used to install Chrome onto systems (hopefully) without the user noticing.
Re: Mozilla Firefox Add-On Signing Update
#60Earlier quoted context omitted.
Pretty fascinating. How do they store the hash?
On the Google sync servers, that's the trick.
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.