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!)
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!
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.
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].
> 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.
> 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).
> 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.
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.
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.
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.
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.
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.)
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?
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
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!)