Live data from Hacker News

Firefox 42 will not allow unsigned extensions

wiki.mozilla.org

81–90 of 315 posts

Re: Firefox 42 will not allow unsigned extensions

#81
post #61

At this point I don't think I'll ever return to using firefox after the mountain of stupid shit mozilla has pulled in the last ~2 years.

The nice thing is that they're doing for "security", although they're absolutely fine pulling insane amounts of crap into their browser to improve the "web experience" and incidentally increasing the attack surface [which is how you get most of the malware actually].

Re: Firefox 42 will not allow unsigned extensions

#82
post #56
post #51

Earlier quoted context omitted.

I can't think of many OSS projects that aren't being manipulated by a strong community of liberals.

Is that the US definition of 'liberal'? i.e. the one that would apply to most center-right parties in the rest of the world?

There is no equivalent of a European left in mainstream US politics. You see bits and pieces in some small-time candidates like Bernie Sanders, but nothing serious. The red scare did its job.

Re: Firefox 42 will not allow unsigned extensions

#84
post #6

What is the point of this? Shouldn't users be allowed to make their own decisions no matter how stupid or dangerous?

Users still can, they can download one of the provided builds that do not have this restriction. The issue is that most users don't understand software on a deep level, and just click "yes" on dialog boxes, etc. It does make sense to keep the defaults where it prevents most users from harm.

But it doesn't! As long as downloading anything is allowed, signing requirements on extensions will not prevent anything.

And by experience supporting users, this is not how bad extensions get installed on the system: they're pulled in by malware which gets installed by other means.

This is only going to irate legitimate extension developers, which already have to wait weeks for AMO to review even the most basic change. I've been distributing extensions separately precisely for this reason.

Re: Firefox 42 will not allow unsigned extensions

#85
post #25

What happens to all of those extensions that are on they gray area of DMCA? Who is this move benefiting? The users or the sponsors?

>>Is this a way for Mozilla to censor add-ons they don't like, enforce copyright, government demands, etc.? >No, the purpose of this is to protect users from malicious add-ons. We have clear guidelines[1] for when it is appropriate to blocklist an add-on and have refused multiple times to block for other reasons. [1] https://developer.mozilla.org/en-US/Add-ons/Add-on_guideline... Copyright, DMCA, and legal concerns a…

Today, Mozilla doesn't get demands to take down extensions because sending demands would be pointless. If EvilCorp tried to force Mozilla to take down uBlock and friends from addons.mozilla.org they would just get hosted elsewhere and EvilCorp would look like assholes. It's all downside, no upside, so EvilCorp don't even bother to ask.

If tomorrow Mozilla can shut down any extension, the calculus changes. Forcing Mozilla to kill ad blockers still makes EvilCorp look like assholes, but it might be successful. There's a big upside now, so much more reason to try and force Mozilla's hand.

Re: Firefox 42 will not allow unsigned extensions

#86

So much for beta-testing your extension prior to release. It's already hard to get users involved, now they just can't. Or using any other channel to get your extension. !Thanks Mozilla, really.

If your extension has been fully reviewed by AMO, you can upload beta versions that only have to pass the automated signing review to be posted to AMO.

Re: Firefox 42 will not allow unsigned extensions

#87

I wonder if this will mean that all the extension version numbers will stop ending in -signed. I'm used to having any build number with -label in its name denote it's a pre-release and isn't stable [0]. I was recently searching for user agent switcher add-ons as part of a blog post [1] and almost all have -signed in the name. To some people it could look like the un-signed ones are more stable and better. [0] http://…

The -signed label was a one time effect to update existing extensions to signed versions (since AMO didn't want to arbitrarily bump the version numbers of all its hosted extensions). Future updates do not have this label.

Re: Firefox 42 will not allow unsigned extensions

#88
post #31
post #28

It should still possible to fork Firefox and remove this requirement, right ?

In theory, but that will be very difficult.

Difficult how? Even though Mozilla is going to providing builds of just such a fork themselves? Is it particularly hard to build firefox?

Re: Firefox 42 will not allow unsigned extensions

#89
post #4

It's important to note that the Developers Editions (and the Nightlys) will have a setting for disabling the requirement. The assumption being that developers need to test as they develop. And are a more informed user.

Did they say why beta wouldn't have this setting? If anything beta is closer to release and developer would target that. Developer edition is still nightly if I'm not correct?

I think they want to encourage wider adoption of the Beta version, so they treat it similarly to the Release. The logic seems pretty questionable to me though. If you can install a Beta version of Firefox, you should be able to avoid consenting to allow malware to run on your computer (this change is primarily targeted at extensions installed by some user action -- like something silently side-loaded by an application installer).

Re: Firefox 42 will not allow unsigned extensions

#90
post #28

It should still possible to fork Firefox and remove this requirement, right ?

Mozilla has said that this requirement is set by one flag at build time, so building a version without this requirement should not be any more difficult than just compiling Firefox I have never done that, but I think it's slightly non-trivial. The hardest part though would be distributing the fork though, so a Linux distribution like Debian mentioned this change as others have mentioned would be one way to build a popular fork without this requirement.
Post reply on HN