Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox 42 will not allow unsigned extensions

wiki.mozilla.org

Post reply on HN
Print view View original

301–310 of 315 posts

Re: Firefox 42 will not allow unsigned extensions

#301

Post by dogma1138 »

An automated review which takes seconds? What will it be looking for exactly? Seems to be something that will either break every extension out there or will be so easy to bypass that it won't do much.

"This is not the same process that currently applies to AMO add-ons, which has been typically slower."

Also the fact that you can't seem to be able to disable it even with some "debug/developer" mode in FF seems to be a bit over the top.

What happens if you are tied to an older FF extension that isn't signed? What happens when you want to develop an extension? yes beta extensions will be signed also but what happens before the BETA what happens when i just want to make hello world and to learn what i can do?

Re: Firefox 42 will not allow unsigned extensions

#302

Post by shdon »

TheLoneWolfling wrote: post #289
shdon wrote: post #163

Earlier quoted context omitted.

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

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

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.

Re: Firefox 42 will not allow unsigned extensions

#303

Post by chriswarbo »

TazeTSchnitzel wrote: post #282
chriswarbo wrote: post #270

Earlier quoted context omitted.

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

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

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

[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

Re: Firefox 42 will not allow unsigned extensions

#304

Post by mbrownnyc »

Kronopath wrote: post #144
mbrownnyc wrote: post #138

Earlier quoted context omitted.

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

You didn't read the linked article. They say that the option will be available in Firefox 41, but Firefox 42 will have no such override.

Thanks for pointing that out. Too bad.

Re: Firefox 42 will not allow unsigned extensions

#305

Post by nathanb »

grincho wrote: post #229
nathanb wrote: post #11

It's the "no override" part that concerns me. 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 cat…

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…

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.

Re: Firefox 42 will not allow unsigned extensions

#306

Post by nathanb »

Cthulhu_ wrote: post #180
nathanb wrote: post #11

It's the "no override" part that concerns me. 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 cat…

Do you test your extension against pre-release versions of Firefox? That's kinda what they're for.

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

Re: Firefox 42 will not allow unsigned extensions

#307

Post by [deleted] »

userbinator wrote: post #103

Mozilla's hypocrisy is astounding: https://blog.mozilla.org/security/2013/01/29/putting-users-i... "Users should have the choice of what software and plugins run on their machine." https://blog.mozilla.org/theden/2014/12/15/introducing-a-sma... "Firefox is dedicated to putting users in control of their online experience" More recently: https://blog.mozilla.org/blog/2015/06/02/firefox-puts-you-in... "Firefox Puts You…

[deleted]

Re: Firefox 42 will not allow unsigned extensions

#308

Post by acdha »

yellowapple wrote: post #287
Klathmon wrote: post #224

Earlier quoted context omitted.

Chrome tried that "configuration switch" before, and what happened was malware would find and flip that switch as one of the first things it did once installed. Then it would work like it used to (installing bullshit extensions, wrecking the browser overall, and being damn near impossible to remove)

So if the malware has the capability of finding that switch and flipping it, what's stopping it from patching one's Firefox binary to skip the signature check? In other words, if malware can open up the configuration of a separate program and alter it, then malicious browser addons are probably the least of your worries.

> So if the malware has the capability of finding that switch and flipping it, what's stopping it from patching one's Firefox binary to skip the signature check?

Plenty of malware runs as the user rather than the admin, so they can install an extension in your profile or change a config setting but cannot rewrite the Firefox binary without an additional exploit.

Similarly, code signing is increasingly common so an attacker who wants to replace Firefox would need to have their own signing certificate and that offers a way to track down the malware authors.

Yes, none of this works against a complete system compromise but security is all about defense in depth. It would be irresponsible not to protect millions of people just because you cannot do so perfectly.

Re: Firefox 42 will not allow unsigned extensions

#309

Post by dveditz_ »

Arcsech wrote: post #244
grincho wrote: post #229

Earlier quoted context omitted.

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…

> We see many copies of Firefox infested with rogue add-ons the user didn't ask for or isn't even aware of. Like Pocket or Hello?

zing!

Re: Firefox 42 will not allow unsigned extensions

#310

Post by dveditz_ »

yellowapple wrote: post #288
grincho wrote: post #229

Earlier quoted context omitted.

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…

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

Post reply on HN