Live data from Hacker News

Mozilla Firefox Add-On Signing Update

blog.mozilla.org

51–60 of 68 posts

Re: Mozilla Firefox Add-On Signing Update

#52

Earlier 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.

More Firefox than Firefox.

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

#53
Add-On Signing which can be automated does provide very little added security for the user, and just serves as a big pain the butt for everyone else involved.

I'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

#54
post #51

Still stuck on Firefox 41, they broke too many extensions after that.

I switched to ESR channel (38.5.2) but I don't know how I'm going to use a newer ESR when it moves to a broken release. Too many extensions stop working and XUL extensions are the essence of Firefox. Tried using Chrome but so much of the ux is different or incomplete to a Firefox user that it's impossible to feel at home.

Re: Mozilla Firefox Add-On Signing Update

#55
They 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.

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

#56
post #5

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 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…

Easy: 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).

Re: Mozilla Firefox Add-On Signing Update

#57

Earlier 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?

On the Google sync servers, that's the trick.

Re: Mozilla Firefox Add-On Signing Update

#58

They 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…

> so why can't they just offer a build with unsigned extensions allowed in a similar way?

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

#59
post #36

Earlier 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.

Here's the thing, though. They work. It's far easier for a low to mid-tier bundleware company to build a basic browser extension that inserts ads or takes over the homepage/search engine using basic off-the-shelf components than it is for them to install a system-level networking component that intercepts and changes browser networking calls without breaking things. Google Chrome took a dual pronged approach to disallow all extensions except those in their online store an disallow third party changes to browser settings. So, bundleware can't easily install into Chrome. It can easily install into Firefox because you or anyone else on the PC can install whatever you want.

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

#60
post #57

Earlier quoted context omitted.

Pretty fascinating. How do they store the hash?

On the Google sync servers, that's the trick.

It'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.

Post reply on HN