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!
Like Pocket or Hello?
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.
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.
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.
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.
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.
Nobody knows what it checks for or how it works.
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.
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
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.
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.
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!)