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 don't see anything about why the beta, but I did see the following in the FAQ. Maybe this will help:
"There will also be special unbranded versions of Release and Beta that will have this setting, so that add-on developers can work on their add-ons without having to sign every build."
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).
Generally, beta is supposed to be almost completely identical to the release version, to ensure that what gets shipped to release users is tested. This particular pref seems harmless, but you never know.
Developer edition is what used to be known as "Aurora", which is in between Beta and Nightly.
I was only commenting on the "trival build or not" part.
You're right that there are plans to have official "unofficial" release and beta builds without signing requirements, but only for the en-US locale (yes, language packs exist, no, not every developer on Earth speaks English)
I had to flip that setting this morning when dev edition updated and disabled the 1Password extension. It's "xpinstall.signatures.required", for reference.
The choice isn't prevented. There is just a small barrier put in place of the choice. Installing a different version of firefox is not difficult, but it makes sure the user is absolutely sure, and helps get an idea across of the ramifications.
There are way too many decisions we need to make in this world to really be informed on every one. Of course, in our world, understanding software and safety is in our scope of knowledge, so we believe everyone should have it. However, not everyone is in our world. I am sure tech people make all sorts of uninformed decisions in other realms that people in those fields would be appalled at. It is OUR job to help protect regular people who don't have the time to learn our world be safe, just as it is the job of those other fields to help keep us safe.
This. Most of the people do not care about this stuff and they do not wish to learn it. Also, like with vaccines, it is important that sufficient number of people are protected for the malware/viruses to not spread.
Heaven forbid. The unaware, uninformed user is the bread and butter that the Internet businesses survive on. Tech-savvy users are bad bad bad. Protected, gullible users is what keeps the engines running.
Idealism and duct-tape- they are holding the world-view together..
Specialisation always was this species strong point. Acceptance that the user might have his strong-point elsewhere and is so nice as to not harass you with his worldview. Imagine if you went into your local bakery, and there behind the counter stands a guy all in white:
"Good morning. Try our donuts today. You could make donuts too. Its easy. Come on ill show you. And then you will be self reliant when it comes to donuts. There are thousands of great recipes online - okay, some are broken, but you dont get to become a expert in donut making - without giving a little bit back..
Sir, Sir - you forgot your Donuts. Maybe he is diabetic and forgot - or evil cooperate donut buyer - or the one dough ring to bind them all is too much of a power.."
With great specialisation comes great loss off understanding on other parts of your life.
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.
But ths change will prevent bad extensions pulled in by malware installed by other means.... On systems that require application signing, that should do some good (otherwise I'd expect malware to just switch from sideloading extensions to sideloading a modified version of Firefox).
An important point is that the review process before signing takes seconds, according to the article. Considering the frequency of FF updates, it's an important point.
Now, let's just hope that the other side of the coin is a concern for API backward compatibility, so that people don't need nightly versions of addons and a developer edition to keep their addons in a usable state...
I created and maintain an extension that is used by visually-impaired people around the world (it has been translated by volunteers into Dutch and Chinese, for example).
Occasionally a Firefox update breaks this extension. OK, fine, that's the cost of doing business. Of course, the automated compatibility report that Firefox creates is utterly useless; it almost never catches the breakage. But that's a side rant....
There can be a decent turnaround lag (sometimes on the order of a few days) to get a new version of an extension reviewed by addons.mozilla.org. In the meantime, I have made a habit of building a new version of the extension and giving it to anyone who asks. Some people rely on it to use the web and can't wait for Mozilla to do their thing (another side rant: I once stupidly forgot to check in a key resource. I've since changed my development process to keep this from happening again. But the non-functional extension that I pushed passed Mozilla's review just fine. Makes me wonder how much value the review process is really adding.)
If I want to be able to continue this process, I will need to sign the extension myself (and who knows what histrionics Firefox will throw if a user tries to replace an extension with one that has the same UUID but a different signature!)
> There can be a decent turnaround lag (sometimes on the order of a few days)
Actually, the link says
> Files submitted for signing will go through an automated review process. If they pass this review, they are automatically signed and sent back to the developer. This process should normally take seconds
You may be thinking of a different type of review process, the signing one sounds almost instantaneous.
That's for non-public add-ons. If you submit a public add-on, even a minor update, it has to go through the AMO bureaucracy. I currently have an update that was uploaded on July 10, 2015, and is at queue position of 64 of 137. There are no code changes; it's just being updated because Mozilla changed their build system.
This seems to be part of Mozilla's effort to be more like the Apple and Google stores.
I wouldn't think Chrome Web store is full of Malware. Yes, it's not free of those, but the bad ones are quickly removed by both Chrome's policing, and users' flagging. That's how Mozilla should go forward. The problem with manual reviewing is, it depends on the 'volunteers' time availability, and a stupid Review system which is NOT FCFS. You are told you are 37th out of 150 in the queue, but you see that you either remain at that position while others are being approved, your queue position goes both up and down, and some times your add-on is instantly approved even when you are 100th in the queue. All this takes many days even if your users are waiting for a critical fix. This is the biggest turn off in uploading add-ons for Firefox.
You can sign the addons and distribute it on other channels. If you want to have it on AMO then it takes a while to review. The process is done by volunteers
This is one of the things which is frustrating about Mozilla.
I love that they stand for open protocols, free software and user privacy, but I don't love what they prioritize.
Reviewing extensions is critical to their user-experience.
If this really doesn't have an team of paid staffers, that's unfortunate.
> If I want to be able to continue this process, I will need to sign the extension myself
This seems like a good approach to me. Instead of Mozilla itself signing developers' extensions, why can't Mozilla issue certificates so developers can sign their own extensions locally? If a developer turns rogue, Mozilla can revoke their certificate.
Because bad guys can just keep getting new certs when their old ones are revoked, unless you do identity validation (which costs money as it requires actual humans, so the certs can't be cheap or free).
Super noob question: Would it make sense for FF to realize a version which an extension is approved for? You create an extension capable for 1.0, they release 1.1, any client who has 1.1 has the extension automatically disabled? Assuming this is your business and you dont mind going through the approval process, then your users would have a better experience with this process no? Being notified they simply can't use it yet?
I don't use many extensions but I'm finding I have to use more as Mozilla remove features from Firefox.
For example you can no longer set the User Agent string on a per site basis natively in Firefox preferences [0]. This would be very handy to force HTML5 video on BBC News when you don't want to install flash [1]. I only discovered this setting was deprecated by finding that bug report whilst researching the blog post.
How is having a built-in PDF viewer more secure than downloading the PDF and viewing it in Adobe Reader or Foxit? Is it just that those readers have vulnerabilities that Firefox doesn't?
Yes. The Firefox viewer sits on top of the JavaScript sandbox, which is the same sandbox that has to withstand attacks from pretty much everything on the internet and has been very hardened over the years (same for other browsers).
Ironically it had a vulnerability last week, but that's ONE and that's why it got so much attention. Adobe Reader and similar have had hundreds.
Allowing people to implement viewers for file types that run in the sandbox as plugins seems like a good idea then. Not that I mind that a PDF-viewer is already built in, but firefox can't support all file types.
I disagree. Having no PDF viewer is more secure than having a PDF viewer.
I'd have no problem with Mozilla releasing a separate PDF viewer, either as an extension, a standalone application or even a Web site. I also have no problem with Mozilla setting Firefox's default PDF application as a stub which downloads their separate viewer. But it shouldn't be built in to Firefox.
In any case, it is not the job of a Web browser to subvert the user's OS setup.
> I disagree. Having no PDF viewer is more secure than having a PDF viewer.
No, because that means you still do have a PDF viewer, but it's whichever the user has installed, most likely Acrobat, which is vulnerability-ridden.
> But it shouldn't be built in to Firefox.
Why shouldn't it? Browsers aren't limited to HTML. They also support plaintext, SVG, many image formats, XML, and so on. What's wrong with supporting PDF?
> No, because that means you still do have a PDF viewer
I didn't say "having no PDF viewer in Firefox", I said "having no PDF viewer".
> Browsers aren't limited to HTML. They also support plaintext, SVG, many image formats, XML, and so on. What's wrong with supporting PDF?
I would call that feature creep; even so, there are still a few differences:
HTML provides mechanisms for embedding images[0], so trying to support some common formats in the browser is a reasonable approach. A better approach would have the OS handle image formats, eg. like the datatype mechanism in AmigaOS[1].
The example image formats at [0] include single-page, non-interactive PDFs. Supporting such an image format might be reasonable, although I've never seen such a thing used in the wild. That's not what Firefox provides, though. Instead, it provides a whole application embedded in a tab, with a GUI for navigating around documents. The equivalent analogy for images would not the facility to decode the format; it would be the bundling of a whole image browsing GUI like Gwenview[2], which I certainly would object to. As it stands, FF treats a standalone image file as if it were a standalone img element, which is perfectly reasonable. The same goes for plain text, which FF effectively treats as if it were in a pre element. Again, it doesn't provide a special application for navigating text files.
SVG is also specifically mentioned in the HTML spec[3], hence providing browser support for SVG isn't straying too far from providing support for HTML. Again, FF doesn't provide a embedded GUI application for navigating SVGs (unless you count the Web Inspector stuff, which also has no place in the browser and should be either a separate extension or rolled into Firebug).
XML is just a syntax, which browsers need to support if they want to support XHTML[4], in the same way they need to support UTF-8 as a syntax for representing the text in HTML documents. Hence it's completely in-scope.
Opera had this feature before it became yet-another-WebKit-clone. A lot of other settings were per-site too.
It's very useful for sites that complain or even block you from visiting depending on your browser, which you'll undoubtedly find if you venture far enough on the Internet.
To note, there is a client-side workaround that allows whitelisting of ALL unsigned extensions (they might consider creating a whitelist of UUIDs or something "humans" can handle like the name of an extension). I was able to change the following and uBlock and Ghostery immediately started working in the "Aurora" build: go to about:config ; set xpinstall.signatures.required = false
Sometimes. With the new ultra-frequent release cycle, as a volunteer maintainer I don't always have the time. And sometimes it breaks in ways that are not visible to me (I run Linux, for example, so bugs that show up on OSX or Windows only are going to be caught by users. These are few and far between, but have happened.)
Hi, Mozilla developer here, speaking for only myself. I'm not sure why we don't make this clearer on the wiki page, but I think the reason there's no override is that any malware installation routine would simply activate it and continue on its merry way. (Disclaimer: I didn't work on this feature and am going by recollection and my own logic.)
We see many copies of Firefox infested with rogue add-ons the user didn't ask for or isn't even aware of. Sometimes these add-ons even ship with big-name software, with no opt out or with the opt out squirreled away in some dark corner. Typically, they do one or more of the following: (1) spy on the user, (2) add affiliate codes for money, (3) cause performance problems and crashes.
The network is a pretty hostile place these days. It's no longer 14-year-olds playing around for fun; there are moneyed interests in the game. And the sorts of people who don't frequent HN are pretty much helpless and clueless in the perpetual tug of war between various companies and mafias. As a "user agent", we have the opportunity defend users who lack the sophistication to root around and remove invasive software they didn't ask for.
Of course, if you're reading this, you're in a different category. You have a better idea which software to trust, and you know how to scour your machine if something gets past you. That's why nightlies and the Developer Edition let you do whatever you want: you aren't the ones who need hard-coded protections to shield you from pref-twiddling installers.
I hope that provides some needed context. Safe surfing, all!
It's been a few months already, and Mozilla is still 'undecided' on what will happen to Enterprise add-ons.
The only two options you are giving us are:
1) Either remain on 'ESR' branch, which is always outdated, OR,
2) Reveal private Enterprise source code to you to get it signed (it might even be illegal for employees to do that).
Both of them could be unacceptable to many organizations.
> We see many copies of Firefox infested with rogue add-ons the user didn't ask for or isn't even aware of.
GoogleUpdate?
why Firefox could not remove these extension itself? I needed to remove some files from the harddisk --I doubt john.doe will be able to remove such evils
Please excuse the rant tone, these things make me feel my intimacy raped
Mozilla does this from time to time for really egregious cases [1]. There is a high cost to staging the block. If the author is known there is a delay to try to get the author to ship a fix [2]. If it is unknown then the block can proceed rather quickly but the cost of changing the extension to avoid the block is usually cheap [3].
Why is this downvoted? These inbuilt add-ons might not be 'rogue', but are definitely the ones which many users didn't ask for, or aren't even aware of.
> I think the reason there's no override is that any malware installation routine would simply activate it and continue on its merry way.
> We see many copies of Firefox infested with rogue add-ons the user didn't ask for or isn't even aware of. Sometimes these add-ons even ship with big-name software, with no opt out or with the opt out squirreled away in some dark corner.
If malware is already executing on the user's computer, it's game over, full stop. That malware can do anything, to include using local-root vulnerabilities to patch Firefox to do anything.
Mozilla is _breaking_ Firefox for normal users, and making itself the arbiter of what users are and are not allowed to run on their own systems. That's both dangerous and foolish.
> but I think the reason there's no override is that any malware installation routine would simply activate it and continue on its merry way.
And what's stopping said malware installation routine from patching my firefox.exe or /usr/bin/firefox or whatever to bypass the signature check? Or patching the running program in-memory? How would it even access that checkbox? This concern seems a bit far-fetched to me.
The target is not illegal malware which, as you say, would do anything. But there's a vast amount of detrimental foistware doing malicious things (e.g. injecting ads, tracking) under legal cover because the user somewhere forgot to uncheck some light-grey box in an installer. Anyone tried to install something from Sourceforge lately?
Modifying the Firefox installation directory would get flagged by any anti-virus, but software using the defined extension points does not -- the user "agreed" to it.
Right, but my point is that if some bit of adware is capable of checking that box without being able to do far more nefarious things (like outright patching/replacing Firefox itself), then one particular symptom of that ability ought to be the least of users' - and Mozilla's - concerns; that indicates an ability to modify the execution state of a program during runtime, in which case probably nothing on that computer is safe.
That's a fair point. Thanks for the explanation. I think it's cool that Firefox has become mainstream enough to have so many non-tech-savvy users that Mozilla has to save them from themselves. I wish there was another approach, but I understand your viewpoint.
>>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.
Copyright, DMCA, and legal concerns are not listed. So I take that to mean nothing will be rejected from signing for those reasons. Hosting on AMO has stricter rules, so they could sign the extension for you to host, but refuse to host it themselves.
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.
Ah, feels like they're following Chrome's example, which decreed that it should be exceedingly difficult for Windows Chrome users to install extensions from somewhere other than https://chrome.google.com/webstore/ . This basically killed an internal app we had at work (a fork of a "REST client", with some added request-signing features specific to our internal APIs.) There was no strong reason to keep it secret, but there had previously been no need to put it in the store either, and there was a $5 charge to publish in the Web Store, which I didn't feel like dealing with.
Anyway, they are both measures taken to stop malware, by taking an option away from the user, that most users won't even notice, but many "power users" will be inconvenienced to varying degrees. I'm guessing Firefox's won't be as bad, since the "developer version" that will let you keep doing the old way probably won't differ from the normal version as much as Chrome's does.
This is the exact reason why I moved to Firefox from Chrome back when Google started tightening the noose around developer mode extensions. I had written a few extensions for my own personal use and had no interest in putting them up in the Chrome Web Store. This was fine and good until Google decided it was A Bad Thing and Chrome started popping up annoying warning windows on every startup and then eventually disabled my extensions entirely.
I switched to Firefox since it let me have more control over my own browsing experience (and gave me a good excuse to extract myself just a little bit from the Google hivemind). I'm extremely annoyed to see that Firefox is now going down this route too.
Well, at least they're paying lip-service to enterprise users who may have internal extensions to deal with:
What about private add-ons used in enterprise environments?
We haven't announced our plan for this case yet. Stay tuned.
In the interim, ESR will not support signing at least until
version 45, which won't come out until 2016.
I have seen several suggestions along the following lines as far back as the original blog post which announced the intention to require extension signing
Allow an extension signing certificate to be place in a directory/store which requires elevated privileges to modify (ie /etc/ or similar).
Extensions in the user's profile signed by this certificate will load as if they were signed with the Mozilla certificate.
If the user has enough privileges to add an extension signing certificate then they also most likely have the ability to modify the Firefox itself, I think this addresses any concerns that this method could be used to load malicious extensions (if the user is willing to run unknown executables with elevated privileges then extensions with apparently valid signatures are the least of their worries).
This allows enterprises to sign and distribute their own extensions, with the additional step of creating and distributing the signing certificate, and could work also work for home users.
It's not really a full fork, but I'm fairly confident that Iceweasel, the patched and no-branding Firefox that ships with Debian, will not have this problem.
(So as I Debian user I don't really care, but it worries me slightly for the future of Mozilla.)
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.
Two details: the extensions need to be signed by Mozilla, and only US English speakers will be allowed to disable this requirement.
The point of free software is that users, individually and collectively, are free to modify it as they wish, without requiring approval from third parties. (And of course to use, copy, and redistribute.) This is a sharp turn away from the free-software ethos that made Firefox possible in the first place.
I understand the issue of users being tricked into downloading and installing malicious extensions. If you let someone program, they will be able to paste malicious code. I just don’t think that taking away users’ ability to modify their own browsers is an acceptable solution to that.
If this disturbing move sticks, Mozilla will become an increasingly tempting target for whatever group wants to control what software you can install on your own computer — whether that’s Sony Pictures, the NSA, or Amazon.
The old free software movement has died. We need a new free software movement.
Perhaps they assume that to program enough to write an extension, you need to learn English. I’ve met people here in Argentina who say that. My view is that, even if that is the status quo ante (and I’m not sure it really is) it’s a status quo we must disrupt, not ossify.
Wise words, kragen. With the excuse "you need english because" a new form of imperialism is on the making. And what is worse, is that this attitude is often self-imposed.
Because there is no such a thing like “English, the lingua franca”; changing the name do not change the content.
We should stop self-deluding ourselves in believing that English exits in a geopolitical void. English is the language of the anglosphere, and speaking English is a huge favor to those economies, and that comes with a sense of cultural inferiority as well, in many peoples.
There is a such thing as "English, the lingua franca" no matter how much one tries to will it away.
Aviation is a curious industry. English is commonly spoke between flight crews and ground stations world wide (with few but notable exceptions). Circumstances where the English meaning of a word wasn't well understood by the flight crew or the wrong words were spoken have, on occasion, lead to disaster--Avianca Flight 52 [1] comes to mind, among others.
I simply cannot agree that mutual intelligibility is bad simply on the merit that it somehow creates a "sense of cultural inferiority."
It sounds like you're saying that using English as the lingua franca of aviation puts at risk the lives of flight crews for whom English is not a native language, as well as their passengers. This seems like a good example of how English-as-lingua-franca gives special worldwide advantages to native English speakers.
What I'm suggesting is that having a standard for communication is less likely to put lives at risk. I can't help but wonder if you're invoking Poe's Law by advocating from what is arguably an extremely fringe standpoint.
Otherwise, the alternative would be to require air traffic controllers to learn a dozen languages, and then you wind up with an even worse problem than having everyone settle on a single language with codified standards.
China [1] and Brazil [2] feature strongly non-English developer communities. Regardless, keying such features to a language is just painfully ignorant. On a closer look though, it appears that beside the developer edition having the setting, the unbranded version will only be released for en-us.
ESR has some bits about "Learn English if you want to code" - but politics of it aside, this isn't even about coding. This is about using a plugin that someone has not signed (like, for instance, RES for Chrome which for the longest time did not have a Store entry iirc).
This sounded super weird. But I guess what you are referring to is that the will only release en-US-localized builds of the "unbranded firefox" editions. That I can understand, the logistics of building and shipping all the i18n editions for an off-brand build is probably significant.
This requirement is ridiculous, a lot of developers can't speak English at all. And what about British English ? Is it not as good as American English for development ?
In addition to the "en-US locale only" restriction, I wonder if unbranded builds will be made available for non-desktop platforms. I would like to run my own extension, or that of the company I work for, on multiple platforms and especially without having to share proprietary source code with Mozilla et al.
I think they removed alternate signature checks from the base code (may affect other browsers), and the preference to disable Mozilla signature checks is a global switch. So they've made things even harder than they have to be for those who don't want to comply with the new model.
According to Mozilla, they have to do this because a user who has control of their OS might install malware and might grant it root/admin privileges. Such malware could not only tamper with extensions, it could tamper with the permission and preference systems and other key components and files. IOW, if Mozilla continues to pursue this policy, we may be looking at the beginning of a more comprehensive lockdown of Mozilla applications.
It might be wise to try to hold the line somewhere. In general, we aren't going to be more secure if we allow ourselves to be locked into simplified configurations that suit the mass market.
> only US English speakers will be allowed to disable this requirement
You can install any non-English locale (language-pack) on top of Firefox. I do that (because I want to be able to switch from a language to another). So it is a two-steps installation.
Mozilla have been doing odd things in recent years, almost like they are transitioning into an authoritarian movement. Want to use unsanctioned extensions? No, go away. Want to use non-secure HTTP? Sure, but we will take away your features. Want to work for them but have unapproved views? Fired. All this is from viewing them as an outsider, so you never know, but something is different.
There was a large outcry, then he resigned. His resignation can be directly traced to his views. Whether he was technically fired or "decided" to resign seems largely irrelevant.
I understand the issue of users being tricked into downloading and installing malicious extensions. If you let someone program, they will be able to paste malicious code. I just don’t think that taking away users’ ability to modify their own browsers is an acceptable solution to that.
I think it's just another battle in The War on General Purpose Computing. I like to keep this quote in mind: "Freedom is not worth having if it does not include the freedom to make mistakes."
> The old free software movement has died. We need a new free software movement.
There is nothing wrong with the free software movement just because someone does something disagreeable---that's like saying there's something wrong with your operating system because you have malware on it.
> The point of free software is that users, individually and collectively, are free to modify it as they wish, without requiring approval from third parties.
You've been on HN for over six and a half years. Surely you can't be this jaded or obtuse?
That freedom is absolutely, unequivocally preserved: The entire source to Firefox is available under OSI-approved libre licenses.
APIs change, but the freedom of the software isn't determined by its exposed APIs, but by your ability to exercise the Four Freedoms enumerated by the FSF at http://www.gnu.org/philosophy/free-sw.html. Debian exercises these freedoms with every build of the IceWeasel browser from Firefox's source.
I'm not jaded, and as to whether I'm obtuse, I have to let the other commenters judge.
I agree that, yes, in theory, you legally have that freedom. But if Mozilla thought users were practically able to exercise that freedom, there would be no way for them to impose a change like this; all the users would switch to a fork. In practice, maintaining a fork of a major active software project is a huge amount of work and easily to do poorly (think of the Debian OpenSSL hole), and nearly all the people qualified to do it work at Mozilla or are burned out. And Mozilla, if they want to make it harder to maintain a fork, has a wide variety of strategies at their disposal.
(In case it matters, I'm typing this comment in Iceweasel!)
As a side note, it seems to me rather in poor taste to attack my intelligence in the first line of your comment, and suggests that you think your arguments won't stand on their own merits.
I apologize for the disparagement; I was miffed at your statement that "only US English speakers will be allowed to disable this requirement," which completely misrepresents the situation, followed by doubt about Firefox's status as F/OSS. Instead of ascribing that to malice, I should have assumed good intent and that the communications from our end were unclear.
As to the English issue, we have absolutely no intent to restrict the signature opt-out to English speakers.
Much like with our Nightly builds, the unbranded copies of Firefox will only be pre-compiled with en-US strings. Additional locales can be added at any time through https://addons.mozilla.org/firefox/language-tools/.
For users that want to disable verification without installing a language pack, the Developer Edition and ESR builds will always allow for opting out and will continue to be released will a full complement of pre-compiled locales.
As a Debian user, I'd like to draw a parallel between these measures and the default requirement for GPG signatures on packages installed by apt, which has been the case since version 0.6 in 2003. These signatures are tools to ensure integrity and provenance, not to restrict your freedoms. Much like with the secure apt initiative, it's entirely possible for users to opt out of these protections after jumping through minimally invasive hoops.
Oh, hey, yep. Tripping over my own ignorance there.
I didn't realize that latest-mozilla-central-l10n/ subdirectory existed; I've always gone straight for latest-trunk/, which it turns out is a symlink to latest-mozilla-central/, which only contains the en-US builds. Thanks for pointing that out. I'll file a bug to get https://nightly.mozilla.org/ updated to point to the localized builds.
> As a Debian user, I'd like to draw a parallel between these measures and the default requirement for GPG signatures on packages installed by apt
Said parallel is imperfect. With APT, you can add custom signatures (say, if you run a private or organization-specific repo). AFAICT, Firefox offers no such capability.
Thank you for clarifying, but I am still very skeptical.
I would have no problem with signature verification if, as with apt, users can decide which keys to trust. (And you don't have to download a whole new copy of apt to do it!) But the intent of this announcement seems to be that Mozilla will prevent users from doing that, on the theory that they will make bad choices. Well, some of them will!
But it's far more dangerous to take those choices away from them — that guarantees that they're trusting the wrong company.
How does this policy interact with greasemonkey, an extension that allows running random JavaScript on sites with access to the extension API. You could write your malware as a greasemonkey extension, convince a user to install a signed greasemonkey release, and then convince them to install your malicious extension.
I wonder how long it will take until adware producers patch out the requirement for signed extensions in the binary when you install stuff from them on your computer.
It's little more than a year ago that Brendan Eich was ousted from Mozilla by an ugly orchestrated cabal. When I read Mitchell Baker's vapid blog post [1] on the decision, filled with polite backstabbing and politically correct buzzwordery I understood that Mozilla has been taken over by politicians and that its decline is just a matter of time.
"Liberals" in the US - democrats - are indeed center-right of the rest of the world. Look at Obama, Clinton, Biden. They are very center on some issues and quite right on others.
Probably. I've always considered both US parties to be so far right wrt the rest of the world, that anything even remotely moderate would be labeled "liberal" or "communist". Both terms used with extreme prejudice and disdain, of course.
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.
A U.S. "liberal" is very socially-progressive (pro-gay marriage, pro-choice, pro-environment, anti-racist, mostly pro-regulation and anti-corporate). I think that's the sort of people the parent poster intended to describe. In Europe "liberals" are usually pro-business and socially-conservative.
(Btw, I wouldn't say a U.S. liberal will automatically sit on the right of the European discourse, today. Traditional socialism has virtually disappeared as a political choice in Europe as well, so really there is very little disagreement today between a U.S. liberal and a European with mainstream social-democratic sensibilities -- except maybe on foreign policy.)
I have been looking at https://input.mozilla.org/ now and then for a long time, and I am still astounded at how it's typically around 90% unhappy, 10% happy.
I know that some Mozilla supporters will justify that huge difference by saying, "but unhappy people will always complain and happy people won't say anything", but I don't think that's necessarily the case. Here we have Mozilla's own stats saying that a lot of their users are extremely unhappy with Firefox.
Clearly something is very wrong for the disapproval rating to be so high, and the satisfaction rating to be so low. In other situations, such a high disapproval rating would be met with extreme concern, immediate retrospection, and panic.
Even in the case of US presidents, where people don't have an immediate alternative like they do with web browsers, and where people's emotions run rampant, it's very rare to see an approval rating under 40%. The very worst approval ratings still are around 25%.
So something is seriously wrong for Mozilla's products to consistently have an approval rating of only 10%, or even 20% if we're being generous.
Take a look at the platform statistics there. Nearly half of the feedback (46%) comes from Android users. Reading the comments, they seem like the (very uninsightful) reviews you typically see in the Google Play Store where the "unhappy people will complain" seems to be quite true.
Firefox for Android is a fundamentally different beast from the browser on Windows/Linux/MacOS. I am quite happy with the desktop version, yet I find the mobile experience quite underwhelming.
If you limit the selection by platform, on Android it will even show "100% sad, 0% happy" -- Mozilla has some work to do there. On Windows 7 you get "81% sad, 19% happy". Still bad, I agree, but don't just dismiss the inherent bias of a feedback system. And compare them to the stats for competitors, too.
Those approval ratings you speak of are usually reported as a part of representative studies. What do you think is the approval rating of Obama, if you only ask people who support Jeb Bush's campaign?
Input is anything but representative, it's not meant to be. It's there to catch things as early as possible.
I had never seen input.* before so I checked it out. I was pleasantly reminded of the variety of user-cases when I read this comment:
"I accidentally installed a prank addon/script (can't remember the name or which one, though it did come with a clear warning). Now my Facebook comments are garbled (scrambles text (makes it worse when I use punctuation-multiplies it). Please use and add some malware cleaner in some future update to get rid of this nasty prank script/addon. I use Stylish addon and I'm guessing I got it from this! Makes using Facebook defunct and troublesome!"
"I have been looking at https://input.mozilla.org/ now and then for a long time, and I am still astounded at how it's typically around 90% unhappy, 10% happy."
I've been reading Mozilla's bug system for 17 years and the bug numbers keep going up. That can't be a good sign.</sarcasm>
It's disappointing to see Mozilla's leadership respond with sarcasm and denial when faced with the fact that 80% or more of their users are not happy with recent versions of Firefox.
That should be 80% of the users who have some reason to be poking around in Firefox's Help menu and are motivated enough to click "Submit Feedback". That group does not include many people who have a perfectly good experience with Firefox.
I recently made an update my own Firefox extension, called Tab Grenade. It took them 4 months to review. 4 months. And that's for a (very) minor update.
Because of that, I was definitely considering to start releasing it on my own, instead of through Mozilla's add-on website. It looks like I will be able to do that, but I'll have to use the signed extension process.
I'll believe this system works when I see it. After my experience with add-on reviewing, I am very skeptical.
The review is mostly done by volunteers. Sorry for the delay, I feel your pain. Will check here if we can try to get more people onboard to help review stuff.
I share your sentiment, but Google Chrome is better only in terms of performance [1], it fares worse in both privacy and extensibility (no ad blockers/addons on mobile Chrome).
For people like me, who want:
* a free software browser
* android/desktop sync
* adblock and other addons
it is pretty much a binary choice between two evils.
[1]: Possibly, of course -- but that is a debate for another time.
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].
not sure yet, but as soon as there's something I'm making the switch.
Too many extensions are required to try to make firefox into something usable, mainly reverting changes or fiwing broken or missing features: ad blocking, sidebar, download manager, bringing back the add on bar, putting back the ability to disable javascript, session manager, cookie manager ability to take screenshot, mouse gestures, tab manager, …
Firefox is open source. Disabling the signature check will probably be a one-line change. Yes, it's a much larger barrier to entry (building Firefox is not trivial), but it's not like IE or Chrome where you have no choice in the matter at all.
Yeah?
You at the very least forgot to obtain the source code first somehow. What about build-dependencies, because ./mach bootstrap does not fully handle that?
Now please tell me how to do a Windows release-build with all release features enabled (except for official branding), aka. a ton of configure switches, and also please do it for my language using the official de locale, because neither the source tar.bz2 nor the hg you'd normally clone contains that. I'm starting from scratch of course.
And suddenly it is less easy and trivial..
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.
Please don't assume all extensions have a reason to be on AMO. There are plenty of extensions which are developed in-house for in-house use only.
Also, as a developer, I never cared to run the "nighties": I don't want an unstable browser, and I don't want fancy new features. I always ran the stock version, also to ensure compatibility with the user base, and never needed anything else.
Maybe Mozilla should also remove the developer tools from the stock version, because clearly it's too dangerous in the hand of people that could cut&paste code with full privileges into it, and it's only a keystroke away!
This is a giant slap in the face, frankly.
I don't see a difference between a walled garden such as google play and this.
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.
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.
There are number of things we believe the e10s project will give us:
...
2. Improved performance, especially on multi-core machines.
3. Better memory core stats."
That seems to directly contradict your concerns. However, these are stated goals and may not align with practical reality. I'd be surprised if, when these are numbers 2 and 3 on their list of priorities, the reality would be so very different.
Those 3 months can make a world of difference. I'd like to see it in action before I decide whether it is a good or a bad thing.
Also, I'd be very surprised if the numbers in this little test are more than anecdotal. Performance will depend heavily on the kind of content you're viewing and I'd wager that the IPC calls make up a very small minority of the runtime profile for a tab process. Also, not everything is so performance-critical. For instance, if response to a mouse click went from 1 to 7 milliseconds, would anybody notice it? If everything in the browser just slowed down by a factor of 2, would Mozilla really ship it?
> if response to a mouse click went from 1 to 7 milliseconds, would anybody notice it?
Considering that a frame at 60fps is ~16.7ms, YES. That's 42% of your total frame budget!
And it's not just IPC calls, either. There are many things that are less efficient when you segment things between multiple processes.
Also, you're completely ignoring / missing the point of memory use. FF (or rather, Pale Moon) is currently using >1/4 of the RAM on my laptop. And swap is (really really really really really) slow.
The exaggerated response time example was for a typical usecase. The amount of situations where there is actually 60fps rendering going on and necessary are few and far between. Most browser usage is of fairly static content. Especially in the case of a mouse click, when you expect something to change on the screen and almost everything in that change will depend on something much slower than the simple IPC call (if that even happens) of tranferring the mouse click event. Splitting things up between multiple processes can slow things down if done badly, and can also bring tremendous speedups if done right. I assume the folks at Mozilla know what they're doing.
And yes, I'm ignoring memory usage for now. Mostly because it is a horribly complex thing, especially in multi-process situations. The numbers are notoriously difficult to interpret between working set, commit charge, shared memory, memory mapped file IO. Unless you're actually debugging the code or an expert, it's basically just guesswork. Mozilla have improved Firefox's general memory footprint significantly these past few years and they're not going to throw those advancements away easily. Again, I trust them to know what they're doing.
As I said before, I'll reserve judgement on e10s until I get to experience it in daily use. All I will say in advance is that the premise and the stated goals make a lot of sense to me and it seems like a highly desirable technology.
Isnt chrome already like this? I spent 45 minutes trying to find a way to install a non extension store extension this weekend and gave up after being blocked repeatedly.
I don't think what chrome does is relevant in this discussion at least not in the context of defining what is the the correct way for mozilla to go forward.
Epic fail. Mozilla should be making the browser subsystems more secure, not saying 'Trust us, we'll ensure your add-ons are secure'.
Will the add-ons source code be reviewed by a CISSP skilled in the languages used within the add-on? Will the add-on be tested with the top 1000 add-on combinations out there? If the add-on provides an API, will it be tested using fuzzing? The list of these questions, and the others to which your answer is likely 'no', goes on. If you are not doing these things then you are providing a false sense of security. You may catch the bottom 60-80% of malware and unstable add-ons, but the most dangerous 20% will likely slip through, in my opinion.
This does not make sense from a UX perspective, as MANY others here have pointed out, so I won't go into that further. I will point out that it doesn't make sense from a business perspective either. If you are saying your add-on signing program improves security, and you let an add-on through that has malware, then you might be sued (I am not a lawyer, this does not constitute legal advice, etc.).
So to recap and summarize, with brevity, and with accuracy...
You're right about law, I know little - I am not a lawyer.
I suspect there will be someone who blames their corporate data breach on Mozilla's policy, if they can make even the flimsiest case. Mozilla might win, at the cost of money, time, and bad PR. I suspect it more likely that they'd settle out of court. I'd love to hear a lawyer weigh in.
I also love how I posted on here (I seldom do) about an issue I felt passionately about, in an area that I do know a bit about, and you responded with a personal attack.
Ask yourself this, what is it you hate so much about the world, yourself, me, or my post that compelled you to personally attack a complete stranger who was donating time and thought to the discussion? Did it make you feel better? Stronger? Isn't that the very behavior you've campaigned against, elsewhere on the web?
I use several small add-ons I wrote myself. Why should I have to get Mozilla's approval before I can install my own damn add-ons? One of them executes processes and I'm 99% sure it'll fail the automated review.
EDIT: It passed the automated review, but my point stands. If I wrote the code, then you can be damn sure I trust it.
> I use several small add-ons I wrote myself. Why should I have to get Mozilla's approval before I can install my own damn add-ons?
Mozilla has to balance the needs of several hundred million users, who are being attacked by malware every day, with the needs of people who write their own add-ons. Is it really that difficult to see it from that perspective? And it's not like you have no options now. You can either use the developer edition or the special release version where this feature is disabled.
They've always catered to the hacker perspective, too. Why take out the about:config flag? How about letting me trust my own certificate, instead of just AMO's? What about running AMO alternatives?
Did you not read the blog post? You can use the dev edition or the special release and beta version that don't have this limitation. Nobody is forcing you to live with this limitation. If this was done as an about:config flag it could easily be changed by an add-on too.
"What are my options if I want to install unsigned extensions in Firefox?
The Developer Edition and Nightly versions of Firefox will have a setting to disable signature checks. There will also be special unbranded versions of Release and Beta that will have this setting, so that add-on developers can work on their add-ons without having to sign every build."
If you want to run a custom AMO I'm assuming you're in a corporate environment or something like that where you can control what browser gets installed on people's machines.
https://addons.mozilla.org is an integral part of Firefox, if you set it up with an alternative you're effectively making your own fork.
It's not an integral part of Firefox, though. You can install add-ons without it by just clicking a link on any page that leads to an XPI, same as how AMO behaves.
And no, I'm not in a corporate environment. I'm talking about decentralization.
Dev Edition is not less customizable... its just Firefox with a new theme and more bleeding edge dev tools which you should be using to develop addons anyway.
314 comments
[ 4.8 ms ] story [ 298 ms ] threadThe assumption being that developers need to test as they develop. And are a more informed user.
"There will also be special unbranded versions of Release and Beta that will have this setting, so that add-on developers can work on their add-ons without having to sign every build."
Developer edition is what used to be known as "Aurora", which is in between Beta and Nightly.
(In addition to people always being able to recompile the browser with whatever modifications they want, of course.)
1: https://www.dashlane.com/en/cs/3bce5a89
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.
Literacy took much longer, but the benefits are clear today.
Specialisation always was this species strong point. Acceptance that the user might have his strong-point elsewhere and is so nice as to not harass you with his worldview. Imagine if you went into your local bakery, and there behind the counter stands a guy all in white:
"Good morning. Try our donuts today. You could make donuts too. Its easy. Come on ill show you. And then you will be self reliant when it comes to donuts. There are thousands of great recipes online - okay, some are broken, but you dont get to become a expert in donut making - without giving a little bit back.. Sir, Sir - you forgot your Donuts. Maybe he is diabetic and forgot - or evil cooperate donut buyer - or the one dough ring to bind them all is too much of a power.."
With great specialisation comes great loss off understanding on other parts of your life.
Wait, did we have an extension-caused apocalypse recently leading to this requirement ? Erm, I guess not. So why do we exactly need it ?
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.
Firefoxs plugin development is already a pain in the ass. They should focus on making it simpler, not giving more reasons to fork it.
Now, let's just hope that the other side of the coin is a concern for API backward compatibility, so that people don't need nightly versions of addons and a developer edition to keep their addons in a usable state...
I created and maintain an extension that is used by visually-impaired people around the world (it has been translated by volunteers into Dutch and Chinese, for example).
Occasionally a Firefox update breaks this extension. OK, fine, that's the cost of doing business. Of course, the automated compatibility report that Firefox creates is utterly useless; it almost never catches the breakage. But that's a side rant....
There can be a decent turnaround lag (sometimes on the order of a few days) to get a new version of an extension reviewed by addons.mozilla.org. In the meantime, I have made a habit of building a new version of the extension and giving it to anyone who asks. Some people rely on it to use the web and can't wait for Mozilla to do their thing (another side rant: I once stupidly forgot to check in a key resource. I've since changed my development process to keep this from happening again. But the non-functional extension that I pushed passed Mozilla's review just fine. Makes me wonder how much value the review process is really adding.)
If I want to be able to continue this process, I will need to sign the extension myself (and who knows what histrionics Firefox will throw if a user tries to replace an extension with one that has the same UUID but a different signature!)
Actually, the link says
> Files submitted for signing will go through an automated review process. If they pass this review, they are automatically signed and sent back to the developer. This process should normally take seconds
You may be thinking of a different type of review process, the signing one sounds almost instantaneous.
Nobody knows what it checks for or how it works.
This seems to be part of Mozilla's effort to be more like the Apple and Google stores.
Mozila AMO - Learn to embrace the pain.
Addons are running in the chrome context and are thus pretty powerful. It's trival to compromise the whole computer if they aren't reviewed.
Reviewing extensions is critical to their user-experience. If this really doesn't have an team of paid staffers, that's unfortunate.
This can be mitigated by having more volunteers (or paid staff (or both)) to help though.
This seems like a good approach to me. Instead of Mozilla itself signing developers' extensions, why can't Mozilla issue certificates so developers can sign their own extensions locally? If a developer turns rogue, Mozilla can revoke their certificate.
For example you can no longer set the User Agent string on a per site basis natively in Firefox preferences [0]. This would be very handy to force HTML5 video on BBC News when you don't want to install flash [1]. I only discovered this setting was deprecated by finding that bug report whilst researching the blog post.
[0] https://bugzilla.mozilla.org/show_bug.cgi?id=933959
[1] https://unop.uk/dev/how-to-watch-bbc-news-videos-on-a-deskto...
To me, that's the way Firefox should work: a fast, lightweight browser, with a powerful extension system.
I get disappointed when Mozilla add "features" to Firefox, like PDF viewers, Pocket, etc.
Ironically it had a vulnerability last week, but that's ONE and that's why it got so much attention. Adobe Reader and similar have had hundreds.
I'd have no problem with Mozilla releasing a separate PDF viewer, either as an extension, a standalone application or even a Web site. I also have no problem with Mozilla setting Firefox's default PDF application as a stub which downloads their separate viewer. But it shouldn't be built in to Firefox.
In any case, it is not the job of a Web browser to subvert the user's OS setup.
No, because that means you still do have a PDF viewer, but it's whichever the user has installed, most likely Acrobat, which is vulnerability-ridden.
> But it shouldn't be built in to Firefox.
Why shouldn't it? Browsers aren't limited to HTML. They also support plaintext, SVG, many image formats, XML, and so on. What's wrong with supporting PDF?
I didn't say "having no PDF viewer in Firefox", I said "having no PDF viewer".
> Browsers aren't limited to HTML. They also support plaintext, SVG, many image formats, XML, and so on. What's wrong with supporting PDF?
I would call that feature creep; even so, there are still a few differences:
HTML provides mechanisms for embedding images[0], so trying to support some common formats in the browser is a reasonable approach. A better approach would have the OS handle image formats, eg. like the datatype mechanism in AmigaOS[1].
The example image formats at [0] include single-page, non-interactive PDFs. Supporting such an image format might be reasonable, although I've never seen such a thing used in the wild. That's not what Firefox provides, though. Instead, it provides a whole application embedded in a tab, with a GUI for navigating around documents. The equivalent analogy for images would not the facility to decode the format; it would be the bundling of a whole image browsing GUI like Gwenview[2], which I certainly would object to. As it stands, FF treats a standalone image file as if it were a standalone img element, which is perfectly reasonable. The same goes for plain text, which FF effectively treats as if it were in a pre element. Again, it doesn't provide a special application for navigating text files.
SVG is also specifically mentioned in the HTML spec[3], hence providing browser support for SVG isn't straying too far from providing support for HTML. Again, FF doesn't provide a embedded GUI application for navigating SVGs (unless you count the Web Inspector stuff, which also has no place in the browser and should be either a separate extension or rolled into Firebug).
XML is just a syntax, which browsers need to support if they want to support XHTML[4], in the same way they need to support UTF-8 as a syntax for representing the text in HTML documents. Hence it's completely in-scope.
[0] http://www.w3.org/TR/html5/embedded-content-0.html#the-img-e... [1] http://wiki.amigaos.net/wiki/Datatypes_Library [2] https://userbase.kde.org/Gwenview [3] http://www.w3.org/TR/2010/WD-html5-20100624/the-map-element.... [4] http://www.w3.org/TR/html5/introduction.html#html-vs-xhtml
This seems like a uselessly fine-grained control. I was surprised to hear that they ever supported it.
It's very useful for sites that complain or even block you from visiting depending on your browser, which you'll undoubtedly find if you venture far enough on the Internet.
We see many copies of Firefox infested with rogue add-ons the user didn't ask for or isn't even aware of. Sometimes these add-ons even ship with big-name software, with no opt out or with the opt out squirreled away in some dark corner. Typically, they do one or more of the following: (1) spy on the user, (2) add affiliate codes for money, (3) cause performance problems and crashes.
The network is a pretty hostile place these days. It's no longer 14-year-olds playing around for fun; there are moneyed interests in the game. And the sorts of people who don't frequent HN are pretty much helpless and clueless in the perpetual tug of war between various companies and mafias. As a "user agent", we have the opportunity defend users who lack the sophistication to root around and remove invasive software they didn't ask for.
Of course, if you're reading this, you're in a different category. You have a better idea which software to trust, and you know how to scour your machine if something gets past you. That's why nightlies and the Developer Edition let you do whatever you want: you aren't the ones who need hard-coded protections to shield you from pref-twiddling installers.
I hope that provides some needed context. Safe surfing, all!
The only two options you are giving us are: 1) Either remain on 'ESR' branch, which is always outdated, OR, 2) Reveal private Enterprise source code to you to get it signed (it might even be illegal for employees to do that).
Both of them could be unacceptable to many organizations.
There is no way of doing this that both respects users freedoms and prevents malicious software.
GoogleUpdate?
why Firefox could not remove these extension itself? I needed to remove some files from the harddisk --I doubt john.doe will be able to remove such evils
Please excuse the rant tone, these things make me feel my intimacy raped
[1] https://addons.mozilla.org/en-US/firefox/blocked/ [2] https://bugzilla.mozilla.org/show_bug.cgi?id=527135 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=937405
You can still use Dev Edition or Nightly with an about:config pref set.
Like Pocket or Hello?
> We see many copies of Firefox infested with rogue add-ons the user didn't ask for or isn't even aware of. Sometimes these add-ons even ship with big-name software, with no opt out or with the opt out squirreled away in some dark corner.
If malware is already executing on the user's computer, it's game over, full stop. That malware can do anything, to include using local-root vulnerabilities to patch Firefox to do anything.
Mozilla is _breaking_ Firefox for normal users, and making itself the arbiter of what users are and are not allowed to run on their own systems. That's both dangerous and foolish.
And what's stopping said malware installation routine from patching my firefox.exe or /usr/bin/firefox or whatever to bypass the signature check? Or patching the running program in-memory? How would it even access that checkbox? This concern seems a bit far-fetched to me.
Modifying the Firefox installation directory would get flagged by any anti-virus, but software using the defined extension points does not -- the user "agreed" to it.
>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 are not listed. So I take that to mean nothing will be rejected from signing for those reasons. Hosting on AMO has stricter rules, so they could sign the extension for you to host, but refuse to host it themselves.
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.
Anyway, they are both measures taken to stop malware, by taking an option away from the user, that most users won't even notice, but many "power users" will be inconvenienced to varying degrees. I'm guessing Firefox's won't be as bad, since the "developer version" that will let you keep doing the old way probably won't differ from the normal version as much as Chrome's does.
I switched to Firefox since it let me have more control over my own browsing experience (and gave me a good excuse to extract myself just a little bit from the Google hivemind). I'm extremely annoyed to see that Firefox is now going down this route too.
Allow an extension signing certificate to be place in a directory/store which requires elevated privileges to modify (ie /etc/ or similar).
Extensions in the user's profile signed by this certificate will load as if they were signed with the Mozilla certificate.
If the user has enough privileges to add an extension signing certificate then they also most likely have the ability to modify the Firefox itself, I think this addresses any concerns that this method could be used to load malicious extensions (if the user is willing to run unknown executables with elevated privileges then extensions with apparently valid signatures are the least of their worries).
This allows enterprises to sign and distribute their own extensions, with the additional step of creating and distributing the signing certificate, and could work also work for home users.
(So as I Debian user I don't really care, but it worries me slightly for the future of Mozilla.)
[1]: https://git.exherbo.org/desktop.git/tree/packages/net-www/fi...
[2]: https://git.exherbo.org/desktop.git/tree/exlibs/mozilla.exli...
Two details: the extensions need to be signed by Mozilla, and only US English speakers will be allowed to disable this requirement.
The point of free software is that users, individually and collectively, are free to modify it as they wish, without requiring approval from third parties. (And of course to use, copy, and redistribute.) This is a sharp turn away from the free-software ethos that made Firefox possible in the first place.
I understand the issue of users being tricked into downloading and installing malicious extensions. If you let someone program, they will be able to paste malicious code. I just don’t think that taking away users’ ability to modify their own browsers is an acceptable solution to that.
If this disturbing move sticks, Mozilla will become an increasingly tempting target for whatever group wants to control what software you can install on your own computer — whether that’s Sony Pictures, the NSA, or Amazon.
The old free software movement has died. We need a new free software movement.
Do they assume that non-English speakers are just drooling baboons who cannot decide this for themselves unlike English speakers?...
Why would using the lingua franca that everyone agrees on be imperialism?
We should stop self-deluding ourselves in believing that English exits in a geopolitical void. English is the language of the anglosphere, and speaking English is a huge favor to those economies, and that comes with a sense of cultural inferiority as well, in many peoples.
Aviation is a curious industry. English is commonly spoke between flight crews and ground stations world wide (with few but notable exceptions). Circumstances where the English meaning of a word wasn't well understood by the flight crew or the wrong words were spoken have, on occasion, lead to disaster--Avianca Flight 52 [1] comes to mind, among others.
I simply cannot agree that mutual intelligibility is bad simply on the merit that it somehow creates a "sense of cultural inferiority."
[1] https://en.wikipedia.org/wiki/Avianca_Flight_52
What I'm suggesting is that having a standard for communication is less likely to put lives at risk. I can't help but wonder if you're invoking Poe's Law by advocating from what is arguably an extremely fringe standpoint.
Otherwise, the alternative would be to require air traffic controllers to learn a dozen languages, and then you wind up with an even worse problem than having everyone settle on a single language with codified standards.
Didn't the Browser Wars teach you anything? :)
ESR has some bits about "Learn English if you want to code" - but politics of it aside, this isn't even about coding. This is about using a plugin that someone has not signed (like, for instance, RES for Chrome which for the longest time did not have a Store entry iirc).
1. http://segmentfault.com/
2. http://pt.stackoverflow.com/
https://wiki.debian.org/Iceweasel
I think they removed alternate signature checks from the base code (may affect other browsers), and the preference to disable Mozilla signature checks is a global switch. So they've made things even harder than they have to be for those who don't want to comply with the new model.
According to Mozilla, they have to do this because a user who has control of their OS might install malware and might grant it root/admin privileges. Such malware could not only tamper with extensions, it could tamper with the permission and preference systems and other key components and files. IOW, if Mozilla continues to pursue this policy, we may be looking at the beginning of a more comprehensive lockdown of Mozilla applications.
It might be wise to try to hold the line somewhere. In general, we aren't going to be more secure if we allow ourselves to be locked into simplified configurations that suit the mass market.
Might? This happens very frequently.
> might grant it root/admin privileges
They don't need to, if you have the browser you have all the good stuff.
And caring about users' security is to be commended.
I think it's just another battle in The War on General Purpose Computing. I like to keep this quote in mind: "Freedom is not worth having if it does not include the freedom to make mistakes."
Yay more botnets.
There is nothing wrong with the free software movement just because someone does something disagreeable---that's like saying there's something wrong with your operating system because you have malware on it.
> Two details: the extensions need to be signed by Mozilla, and only US English speakers will be allowed to disable this requirement.
This is not what is written there. The addons need to be signed by mozilla. The process is automated.
The unbranded version of Firefox is distributed with the English locale. You can install other language packs.
Firefox Stable and Beta can't disable the signing requirement. Firefox DevEdition, Nightly and Unbranded can.
You've been on HN for over six and a half years. Surely you can't be this jaded or obtuse?
That freedom is absolutely, unequivocally preserved: The entire source to Firefox is available under OSI-approved libre licenses.
APIs change, but the freedom of the software isn't determined by its exposed APIs, but by your ability to exercise the Four Freedoms enumerated by the FSF at http://www.gnu.org/philosophy/free-sw.html. Debian exercises these freedoms with every build of the IceWeasel browser from Firefox's source.
I agree that, yes, in theory, you legally have that freedom. But if Mozilla thought users were practically able to exercise that freedom, there would be no way for them to impose a change like this; all the users would switch to a fork. In practice, maintaining a fork of a major active software project is a huge amount of work and easily to do poorly (think of the Debian OpenSSL hole), and nearly all the people qualified to do it work at Mozilla or are burned out. And Mozilla, if they want to make it harder to maintain a fork, has a wide variety of strategies at their disposal.
(In case it matters, I'm typing this comment in Iceweasel!)
As a side note, it seems to me rather in poor taste to attack my intelligence in the first line of your comment, and suggests that you think your arguments won't stand on their own merits.
As to the English issue, we have absolutely no intent to restrict the signature opt-out to English speakers.
Much like with our Nightly builds, the unbranded copies of Firefox will only be pre-compiled with en-US strings. Additional locales can be added at any time through https://addons.mozilla.org/firefox/language-tools/.
For users that want to disable verification without installing a language pack, the Developer Edition and ESR builds will always allow for opting out and will continue to be released will a full complement of pre-compiled locales.
As a Debian user, I'd like to draw a parallel between these measures and the default requirement for GPG signatures on packages installed by apt, which has been the case since version 0.6 in 2003. These signatures are tools to ensure integrity and provenance, not to restrict your freedoms. Much like with the secure apt initiative, it's entirely possible for users to opt out of these protections after jumping through minimally invasive hoops.
I have been using localized builds from https://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-c... for several years - are they not part of the Nightly builds?
I didn't realize that latest-mozilla-central-l10n/ subdirectory existed; I've always gone straight for latest-trunk/, which it turns out is a symlink to latest-mozilla-central/, which only contains the en-US builds. Thanks for pointing that out. I'll file a bug to get https://nightly.mozilla.org/ updated to point to the localized builds.
Said parallel is imperfect. With APT, you can add custom signatures (say, if you run a private or organization-specific repo). AFAICT, Firefox offers no such capability.
I would have no problem with signature verification if, as with apt, users can decide which keys to trust. (And you don't have to download a whole new copy of apt to do it!) But the intent of this announcement seems to be that Mozilla will prevent users from doing that, on the theory that they will make bad choices. Well, some of them will!
But it's far more dangerous to take those choices away from them — that guarantees that they're trusting the wrong company.
[1] https://blog.mozilla.org/blog/2014/04/03/brendan-eich-steps-...
(Btw, I wouldn't say a U.S. liberal will automatically sit on the right of the European discourse, today. Traditional socialism has virtually disappeared as a political choice in Europe as well, so really there is very little disagreement today between a U.S. liberal and a European with mainstream social-democratic sensibilities -- except maybe on foreign policy.)
I know that some Mozilla supporters will justify that huge difference by saying, "but unhappy people will always complain and happy people won't say anything", but I don't think that's necessarily the case. Here we have Mozilla's own stats saying that a lot of their users are extremely unhappy with Firefox.
Clearly something is very wrong for the disapproval rating to be so high, and the satisfaction rating to be so low. In other situations, such a high disapproval rating would be met with extreme concern, immediate retrospection, and panic.
Even in the case of US presidents, where people don't have an immediate alternative like they do with web browsers, and where people's emotions run rampant, it's very rare to see an approval rating under 40%. The very worst approval ratings still are around 25%.
So something is seriously wrong for Mozilla's products to consistently have an approval rating of only 10%, or even 20% if we're being generous.
Firefox for Android is a fundamentally different beast from the browser on Windows/Linux/MacOS. I am quite happy with the desktop version, yet I find the mobile experience quite underwhelming.
If you limit the selection by platform, on Android it will even show "100% sad, 0% happy" -- Mozilla has some work to do there. On Windows 7 you get "81% sad, 19% happy". Still bad, I agree, but don't just dismiss the inherent bias of a feedback system. And compare them to the stats for competitors, too.
Input is anything but representative, it's not meant to be. It's there to catch things as early as possible.
"I accidentally installed a prank addon/script (can't remember the name or which one, though it did come with a clear warning). Now my Facebook comments are garbled (scrambles text (makes it worse when I use punctuation-multiplies it). Please use and add some malware cleaner in some future update to get rid of this nasty prank script/addon. I use Stylish addon and I'm guessing I got it from this! Makes using Facebook defunct and troublesome!"
Mozilla Heartbeat is constantly asking for ratings from a random sample of Firefox users.
The Heartbeat rating for Firefox Desktop is currently about 4.3/5- or 86%.
P.s. Despite the amount of negative feedback in Input, the portion of feedback which is positive is about twice what it was in May.
I've been reading Mozilla's bug system for 17 years and the bug numbers keep going up. That can't be a good sign.</sarcasm>
Because of that, I was definitely considering to start releasing it on my own, instead of through Mozilla's add-on website. It looks like I will be able to do that, but I'll have to use the signed extension process.
I'll believe this system works when I see it. After my experience with add-on reviewing, I am very skeptical.
For people like me, who want:
* a free software browser
* android/desktop sync
* adblock and other addons
it is pretty much a binary choice between two evils.
[1]: Possibly, of course -- but that is a debate for another time.
Too many extensions are required to try to make firefox into something usable, mainly reverting changes or fiwing broken or missing features: ad blocking, sidebar, download manager, bringing back the add on bar, putting back the ability to disable javascript, session manager, cookie manager ability to take screenshot, mouse gestures, tab manager, …
./mach bootstrap
./mach build
Now please tell me how to do a Windows release-build with all release features enabled (except for official branding), aka. a ton of configure switches, and also please do it for my language using the official de locale, because neither the source tar.bz2 nor the hg you'd normally clone contains that. I'm starting from scratch of course. And suddenly it is less easy and trivial..
Or using any other channel to get your extension.
!Thanks Mozilla, really.
Also, as a developer, I never cared to run the "nighties": I don't want an unstable browser, and I don't want fancy new features. I always ran the stock version, also to ensure compatibility with the user base, and never needed anything else.
Maybe Mozilla should also remove the developer tools from the stock version, because clearly it's too dangerous in the hand of people that could cut&paste code with full privileges into it, and it's only a keystroke away!
This is a giant slap in the face, frankly.
I don't see a difference between a walled garden such as google play and this.
I wonder if I can have a refund? I'm very disappointed in how Firefox has aged.
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://semver.org
[1] https://unop.uk/dev/how-to-watch-bbc-news-videos-on-a-deskto...
I hope 41 is an ESR
update, nope: only 38 and 45 are ESR
https://mozorg.cdn.mozilla.net/media/img/firefox/organizatio...
There are advantages, but it is not without its disadvantages.
"Goals
There are number of things we believe the e10s project will give us:
...
2. Improved performance, especially on multi-core machines.
3. Better memory core stats."
That seems to directly contradict your concerns. However, these are stated goals and may not align with practical reality. I'd be surprised if, when these are numbers 2 and 3 on their list of priorities, the reality would be so very different.
Now, mind you, that was nearly 3 months ago. But the concerns there are still very relevant.
Also, I'd be very surprised if the numbers in this little test are more than anecdotal. Performance will depend heavily on the kind of content you're viewing and I'd wager that the IPC calls make up a very small minority of the runtime profile for a tab process. Also, not everything is so performance-critical. For instance, if response to a mouse click went from 1 to 7 milliseconds, would anybody notice it? If everything in the browser just slowed down by a factor of 2, would Mozilla really ship it?
Considering that a frame at 60fps is ~16.7ms, YES. That's 42% of your total frame budget!
And it's not just IPC calls, either. There are many things that are less efficient when you segment things between multiple processes.
Also, you're completely ignoring / missing the point of memory use. FF (or rather, Pale Moon) is currently using >1/4 of the RAM on my laptop. And swap is (really really really really really) slow.
And yes, I'm ignoring memory usage for now. Mostly because it is a horribly complex thing, especially in multi-process situations. The numbers are notoriously difficult to interpret between working set, commit charge, shared memory, memory mapped file IO. Unless you're actually debugging the code or an expert, it's basically just guesswork. Mozilla have improved Firefox's general memory footprint significantly these past few years and they're not going to throw those advancements away easily. Again, I trust them to know what they're doing.
As I said before, I'll reserve judgement on e10s until I get to experience it in daily use. All I will say in advance is that the premise and the stated goals make a lot of sense to me and it seems like a highly desirable technology.
https://developer.chrome.com/extensions/getstarted#unpacked
Will the add-ons source code be reviewed by a CISSP skilled in the languages used within the add-on? Will the add-on be tested with the top 1000 add-on combinations out there? If the add-on provides an API, will it be tested using fuzzing? The list of these questions, and the others to which your answer is likely 'no', goes on. If you are not doing these things then you are providing a false sense of security. You may catch the bottom 60-80% of malware and unstable add-ons, but the most dangerous 20% will likely slip through, in my opinion.
This does not make sense from a UX perspective, as MANY others here have pointed out, so I won't go into that further. I will point out that it doesn't make sense from a business perspective either. If you are saying your add-on signing program improves security, and you let an add-on through that has malware, then you might be sued (I am not a lawyer, this does not constitute legal advice, etc.).
So to recap and summarize, with brevity, and with accuracy...
EPIC FAIL
You're right about law, I know little - I am not a lawyer.
I suspect there will be someone who blames their corporate data breach on Mozilla's policy, if they can make even the flimsiest case. Mozilla might win, at the cost of money, time, and bad PR. I suspect it more likely that they'd settle out of court. I'd love to hear a lawyer weigh in.
I also love how I posted on here (I seldom do) about an issue I felt passionately about, in an area that I do know a bit about, and you responded with a personal attack.
Ask yourself this, what is it you hate so much about the world, yourself, me, or my post that compelled you to personally attack a complete stranger who was donating time and thought to the discussion? Did it make you feel better? Stronger? Isn't that the very behavior you've campaigned against, elsewhere on the web?
EDIT: It passed the automated review, but my point stands. If I wrote the code, then you can be damn sure I trust it.
Mozilla has to balance the needs of several hundred million users, who are being attacked by malware every day, with the needs of people who write their own add-ons. Is it really that difficult to see it from that perspective? And it's not like you have no options now. You can either use the developer edition or the special release version where this feature is disabled.
"What are my options if I want to install unsigned extensions in Firefox?
The Developer Edition and Nightly versions of Firefox will have a setting to disable signature checks. There will also be special unbranded versions of Release and Beta that will have this setting, so that add-on developers can work on their add-ons without having to sign every build."
- Special version of the software
- Can't run my own version of AMO
You can, AMO is open source: https://github.com/mozilla/olympia
Run your own instance and make your own builds of Firefox that point to it and you're good.
Yeah, let me just get all of the potential users of my AMO alternative to compile a custom version of Firefox for it
https://addons.mozilla.org is an integral part of Firefox, if you set it up with an alternative you're effectively making your own fork.
And no, I'm not in a corporate environment. I'm talking about decentralization.