Linux sandboxing improvements in Firefox 57
morbo.org
morbo.org
I don't doubt that such a sea change in public consensus is possible - it happened several years ago with the surge of Chrome in about 2010 [1]. Chrome was markedly quicker than the competition in its day, but I believe that Firefox 57 makes at least as big a performance leap in day-to-day usage over its rivals as Chrome did when it came to prominence. For much of the last ten years, Chrome has been the go-to browser for the tech-saavy user - Firefox is now as well placed as it could ever be to reclaim that crown.
[1] https://commons.wikimedia.org/wiki/File:Browser_usage_share,...
You can see some mockups on Victoria Wang's Twitter: https://twitter.com/violasong/status/926189788486557697
http://www.omgubuntu.co.uk/2017/08/firefox-client-side-decor...
The icon indicators also are really nice. At this point the only reason I use Chrome is b/c of Google Meet (which doesn’t support Firefox).
The only thing I wish was better in the beta is battery life/usage. Safari is still king in terms of its effect on you battery.
Edit: to be clear I use Firefox beta on Linux and macOS regularly.
I think WebExtensions were a good idea, but removing the raw access is removing what made Firefox great in the first place. Hopefully they will add an escape hatch in a future release but I'm not holding my breath. I wonder how long staying on nightly will allow "legacy" extensions.
But sure, a bit of performance is nice I guess.
I still wish they hadn't crammed it down our throats before it was ready, though. Jetpack extensions worked fine.
It's really quite visible, multiprocess was rolled out in Firefox 48 on the 2nd August 2016: https://www.netmarketshare.com/report.aspx?qprid=1&qpaf=&qpc...
The raw access is also what made Firefox slow and cumbersome compared to Chrome. The recent performance improvements would have been impossible with the legacy extension apis.
Honesty I think this is a good move.
This is simply not true as evidenced by the fact that Nightly still has the legacy extension API and the improved performance.
That being said FF was slowing down to keep extensions compatible. This is why I think WebExtensions are a good idea. They should be the recomended path with promised future compatibility. Then FF can not worry as much about refactoring the internals as there are fewer extensions that would be broken and they "signed up" for it.
I would rather have a faster FF and have to patch VimFX every couple of releases then have FF show down development for fear of breaking things. That being said loosing the extensions that gave FF it's magic is not a good tradeoff in my opinion.
On nightly the extensions.legacy.enabled can be set to allow instalation of legacy extensions.
This was for pre-57 and doesn't apply to 57+.
The intent is to have a way to prototype new WebExtension APIs (like hiding individual tabs, or the entire tab bar, or new theme APIs), but there's no requirement that they ever get merged upstream. You're welcome to build and distribute your own for whatever purpose you might want.
https://palant.de/2017/11/11/on-web-extensions-shortcomings-...
Also it seems to not have done much as basically every extension just asks for full access to every page, but I guess that some don't is an improvement.
No. Firefox's WebExtensions API already offers more than Chrome's does (see webRequest as an example: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/AP...) and more APIs will be added over time to enable more features.
They've refactored tons of code under the hood, basically all the changes that they've wanted to do for years but couldn't do, because it would have broken too many extensions over and over.
We're also talking about all the performance improvements that were made since Firefox 48. The majority of legacy extensions are not multiprocess-compatible and they would not have rolled out multiprocess in 48, if they wouldn't have known those multiprocess-incompatible extensions to be deprecated now with 57. Otherwise AMO would have basically been reverse Russian Roulette, where only roughly 1 out of 6 extensions will not kill your performance.
Yes, a lot would be. However if they could still be used many of them would have been fixed by now.
> The majority of legacy extensions are not multiprocess-compatible
Yet many are.
My point is basically that I would like if FF supported the legacy "API" and left the community to manage fixing things that were broken. I would take this work over not being able to have some extensions any day.
Otherwise you'd have tons of extensions that could be rewritten as WebExtensions but aren't, because it's less work in the short-term to just fix them for the XUL changes. In the long-term, however, it would be a lot more work, especially if Mozilla starts recklessly breaking things.
Similarly, many unmaintained extensions will disappear and WebExtensions will be written to replace them. Those will almost certainly have better quality and performance. Shouldn't be all too hard to pull off for an unmaintained extension.
And then there's also stories like with NoScript's transition, which very much is a lot of work, but it will leave the NoScript maintainer with a much cleaner code base, not just from the WebExtension API being cleaner, but also simply because he rearchitectured the whole thing, as he was forced to rewrite anyways. And he'll get significantly better performance out of this, too.
He would not have done a rewrite without this, but he's glad that he did it.
However even if the WebExtensions had an "escape hatch" to browser internals it would still require significant porting effort and the promise of being marked as "Full Browser Access" and "Likely to Break" would probably convince everyone who can to port anyways.
I'm not convinced they're going in the right direction. Annoying dicking around adding new stuff as default that should be extensions (ones you can remove, and that you choose to add). Then in FF56 on Kubuntu I've noticed a slow down, a lot of lagging for me; but much worse most of [18/20] the add-ons I use are now "legacy" which gives a sense of foreboding that I'll be left choosing long established add-ons _xor_ bugfix/security updates.
We'll see of course, perhaps I'm just getting a little too cynical having been browsing since the days Lynx, Mosaic and Netscape were new tech.
I understand that a lot of devs and power users are annoyed but hopefully we're not the only target audience, we just happen to be a quite vocal in places like HN.
[0] Step-0 of https://iotdarwinaward.com/post/improve-your-privacy-in-age-...
As much as I would like to see that its not gonna happen, and I am writing this as a Firefox user.
Remember what 'REAL' Opera 12 did in its times comparing to Chrome or Firefox? It loaded pages faster, used less memory, was most standards compliant and also came with bundled torrent client, and mail client and RSS client and ... and having 100+ tabs opened DID NOT EVEN SLOWED IT!
... and guess what, both Firefox and Chrome had more users while Opera had about 4-5%.
It did not mattered if it was faster or better.
Currently Opera is just a Chrome with different skin, so I moved to Firefox with Midori and Iridium as 'backups'.
I'm so glad Firefox catches up. Instead of thinking "I wish Chromium had better UI and I had more RAM", I can just be happy with my browser, embracing my workflow instead of trying to adapt it to the available tools.
Well, for now it is still much slower than Chrome https://www.phoronix.com/scan.php?page=article&item=firefox-...
https://v8project.blogspot.de/2017/04/retiring-octane.html?m...
Web browser escapes usually target the operating system kernel in order to break out of the sandbox. Chrome can reduce its attack surface on Linux using seccomp, and while there's a win32 syscall filter on Windows 10, I'm not sure if Chrome uses it. Windows has stronger kernel self protection features than Linux, but also more attack surface.
Chrome uses Linux namespaces (like LXC/Docker/...) for isolation in addition to seccomp-bpf.
Chrome is by far the most secure one right now, but as evidenced by this blog article, Firefox is catching up.
I believe the specific win32k syscall filter you're referring to (where you can white/black list specific syscalls) is still only accessible to Microsoft applications (Edge uses it).
I'm not entirely sure how things stack up now. In the past I never had much faith in the vanilla linux kernel.
I guess there's a price in each choice.
Debian is providing Firefox ESR 52 even in oldstable (check security upgrades) https://tracker.debian.org/pkg/firefox-esr
"Jessie and Stretch backports of Firefox release and beta are gone because of the requirement of rust to build them, which is not available in Jessie or Stretch. Please update your apt sources to use Firefox ESR instead."
I'm not sure how that Rust requirement and ESR 59 will play together; I'll assume they won't play together very well.
"won't" is a strong claim especially considered you didn't provide any source to back it. The page you've linked doesn't talk about such a possibility at all. This is only your wild guess right now.
Disclaimer: Affiliated with Mozilla, but not with the Firefox team.
Is there a way to build Firefox without GTK? For example for something like Plasma Mobile? It would be good if there was some fallback mode where Firefox would render UI elements using HTML itself, without relying on UI toolkits.
Even if that means Firefox breaks every few weeks due to a new GTK release.
Even if that means Firefox never will properly support multi-monitor HiDPI on Linux (and not at all on X11).
I can see why it can be harder to bind to Qt from Rust, but this is now a solved problem I think:
https://phabricator.kde.org/source/rust-qt-binding-generator...
Browser.html is an experiment in that idea for Servo:
https://github.com/browserhtml/browserhtml
If it works out it may end up in Firefox in the long term.
Well, and then you'd probably run into security restrictions, as under normal circumstances, you don't ever want something from inside Gecko to communicate with extensions and probably other things, but for this you need that capability.
Having said that, Mozilla is actually exploring into this direction: https://github.com/browserhtml/browserhtml/blob/master/READM...
And presumably, this is the future, as it would also allow them to get rid of the XUL UI Toolkit, meaning they can entirely focus on core browser technologies. (Which is something different from the XUL/XPCOM extension API that they're deprecating on Tuesday.)
That's not terribly hard to do today either. That's why browsers implemented those obnoxious fullscreen animations and notifications somewhen last year.
This isn't quite a meaningful assertion. The way it works in Firefox is that a UI developer specifies in a xul or html document that there should be a button:
<button id="myButton" label="Click me!"/>
Note in particular the `-moz-appearance: button;`. This tells the rendering engine to figure out how big the button is, ask the OS to draw a button of that dimension, and then composite the OS button on top of the button node. I'm not an expert but a quick glance at the code points me to https://dxr.mozilla.org/mozilla-central/source/widget/gtk/ns..., which seems to be the main entry point for Gecko to ask for a widget to be rendered.
As you can see, Firefox does not rely on a toolkit to tell it how buttons _work_, only how they _look_. You could supply a stylesheet that overrides the -moz-appearance rules and you'll get buttons that are rendered purely by Firefox. (You might need to supply some more style rules so that they actually look like buttons.)
If you want to compile without GTK, that's a little more complicated. Firefox uses the toolkit for things like the message loop, mouse and keyboard event processing, etc. You could do all of that in straight Xlib, but who would want to? Certainly nobody has wanted to enough that they've been maintaining an Xlib port all of these years.
Since Webrender is designed like a game engine, may be it should use SDL or something of that sort.
It would be easier to simply build a Qt version of the bits that depend on GTK, so Linux users can choose between those two. But considering how little Firefox seems to care about Linux user experience (FF has been broken with transparent GTK themes since forever and nobody cares; FF removed Linux native audio support and nobody cares), I doubt this will happen and I doubt a patch would be accepted upstream for reasons of "maintenance overhead". This ignores that maintenance overhead is much higher when two independent parties have to maintain the upstream and a patchset, but is for some reason accepted practice in the open-source world.
No, they didn't. I'm listening to Soundcloud in my Firefox right now; it's sending sound to PulseAudio just fine.
What you actually meant to say is that Firefox removed support for those 1% of Linux users (i.e. 0.01% of total users) that don't have PulseAudio for whatever reason.
security.sandbox.content.read_path_whitelist
The standard way to access files for extensions seems to be with Native Messaging: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Na...
Basically make the user install a small program on their PC, then your extension talks to that program, the program reads out the file that you need and then hands it back to your extension.
I mean, Firefox even has a `security.turn_off_all_security_so_that_viruses_can_take_over_this_computer` pref (used in testing; you won't see it in about:config but IIRC you can manually add it. Don't.). Prefs that break security are not new :)
Defense in depth concept is not new either.
But yes, it seems to be something you can flip in production. The argument being that if you're in a position to flip prefs you already can break security in a million ways. It's not something you can accidentally flip either.
(The pref doesn't actually "let viruses take over the computer", it just turns off all the security checks)
Useful for some internal unit/integration tests for release and test builds, but really dangerous when pointed to the web.
sandboxing is great, but if the site is spooky enough im just going to load it in elinks/lynx and grok the text. Chromium also has sandboxing, and if youre really paranoid enough, surf from suckless.org is a webkit style do-it-yourself browser thats fairly reliable.