Today, Sept 16th 2021, the Desktop Team has opened a Feature Freeze exception to replace the Firefox seed in ubuntu-desktop from a deb package to a Mozilla-official Firefox snap. This is the result of cooperation and collaboration between the Desktop and Snap teams at Canonical and Mozilla developers, and is the first step towards a deb-to-snap transition that will take place during the 22.04 development cycle.
What does this mean, and who does it affect?
This will only impact users of Ubuntu Desktop installing 21.10 or upgrading to 21.10. If you run one of the flavours, you won’t be affected - yet. The deb will continue to be supported through the life cycle of 21.10, and the deb to snap transition is scheduled to be completed in 22.04.
Wait, why the change?
Good question! When Mozilla approached Canonical, they had some clear benefits in mind. Those included:
Cross-platform support: The snap will run on all distributions that run snapd - now and in the future
Authenticity: You’re getting Firefox, unadulterated, straight from the source
Effortless updates: Get security updates from Mozilla, fast
Less time on maintenance, more time for features: Community developers can focus on innovation, instead of being mired in support
I still have questions
We understand! This is a big change, and we welcome your questions in this post. As community members who help make Ubuntu - and use it in your everyday lives - a change to a popular web browser is a big deal, and your concerns are not only valid, but vital to making 22.04 and future releases a success.
To start off the questions, here’s a few that came to mind:
Didn’t you do this before? Yes. Kind of, with the transition to the Chromium snap a few years ago. You can read about that here in our chromium snap transition blog post. However, that decision was all us, for maintenance reasons. This time around, for Firefox, it’s a coordinated effort between Mozilla and Ubuntu.
Isn’t it going to be slow? Long answer short? We don’t want it to be. Have a read of how we solved the chromium startup problem, and a blog post about the speed improvements that come with the newest compression algorithm snaps use. Building the snap with a newer toolchain (clang & rust) and more optimisations will likely result in a faster application. But keep us honest, and let us know what speeds you see with the new snap.
What’s the point of putting Firefox in a snap, if it already uses sandboxing? Having the application strictly confined is an added security layer on top of the browser’s already-robust sandboxing mechanism. The browser sandbox protects the browser against malicious code, whereas the snap confinement protects the user against the browser acting maliciously. So these are really two complementary security mechanisms.
After the transition, do I HAVE to use the snap? We (Mozilla and the Desktop Team) recommend the snap, but, if you’d prefer otherwise, Mozilla still offers their distro-agnostic builds for amd64 and i386.
What can I do?
Test and give us your feedback. Lots of it. Test fresh installs and upgrades of Ubuntu Desktop 21.10 (the beta is almost here!), and when it comes time to test daily builds of JJ, test stock Ubuntu AND the flavours, especially flavours that may have to make changes to accommodate for the snap. Let us know where things go wrong, or slow, or otherwise not well, so by the time the final release of 22.04 is out, we’ve all helped make Firefox run seamlessly, swiftly, and more securely.
Is that really true, though, given the type of access needed for that kind of sandbox to actually do its thing? The browser support plug contains severalscary things. I’m ignoring obvious confinement shortcomings that should improve over time (e.g. x11), I’m mostly curious regarding the interplay between both confinement systems. Feels like the snap needs to be pretty open in order for the browser sandbox to work, which means it can’t really protect the user from the browser behaving maliciously. Do you see that changing over time?
I have chromium snap installed, and it’s slower than chrome. It also suffer from few other quirks.
It’s not beta yet, so i can’t tell how much slower it is, or how problematic it is. It also won’t affect me till 22.04 due to kubuntu not having it, just gnome.
Benchmarks will be on Phoronix soon, most likely.
again, how is the difference here, making such a claim without concrete numbers does not really prove your point …
i’m using the chromium snap as well on all my machines.
all i can say here is that it does not launch noticeable slower (between 3-5 sec before it is ready to be used) than the deb packaged firefox.
websites seem to load at the same speed when both sit side by side, there is also not noticeable difference in scrolling or anything …
while i can not compare to chrome (since i do not use it) there is definitely no noticeable speed differences between the deb packaged firefox and chromium on my 20.04 systems and i’m using both side by side (chromium for all work related stuff, FF for private things) all day happily.
becomes not experimental anymore and set by default rather soon … that should handle it just fine (it does for me today) and remind you to close the app to allow it to update once you have the ability to …
I have that set on my matterhorn snap (hi popey and trevino!) and I really hate showing up to work in the morning to a matterhorn instance that dies the first time I try to open a link or an attachment or can’t save which channels I’ve read. Even that refresh-app-awareness thing doesn’t let you postpone an update to a time of your choosing, it just reduces the frequency of how often forced updates happens on frequently-updated snaps.
Sure, sometimes unattended-upgrades does the same thing for my deb-packaged Firefox, but I get to run apt update && apt upgrade at times of my choosing and usually catch a Firefox update that way. (I also strongly dislike that Firefox requires a restart when the package has been updated; alas that’s a windmill I’ve tilted against for far too long.)
unattended-upgrades is different from snap’s forced updates in at least two major respects:
it’s easy to turn off if you don’t want
when Firefox in deb is updated, the application asks politely to restart. It doesn’t just start failing to perform operations due to permission denied errors.
I’ve heard for ages of problems with chromium-browser failing to save bookmarks or keep state across updates while running. Have those problems been sorted out? Were they unique to chromium-browser? Or are they common in all applications when they are packaged in snap?
Noticeably slower than .deb chrome. Also upgrading mid-usage didn’t look good. Don’t get me wrong, i’m not in burn the snaps alive camp, but it’s not ready yet. Just like wayland.
Guess we will have rocky 22.04 with all those unproven tech
seems the matterhorn snap has no .desktop file then …
refresh-app-awareness will make sure that there are no upgrades forced for any desktop apps as long as you keep the app open (and ignore the multiple notifications you get per day) for more than 60 days … if you have it enabled it will only after that period force an upgrade, you will not lose bookmarks or sessions …
regarding matterhorn you should perhaps check what lxd does to convince refresh-app-awareness to work correctly, i get the notifications for it as well and its running state is not touched (nor is it upgraded without my consent within the 60 day frame) until i let it upgrade…
It might not, command-line applications often don’t have them. If it has one, I haven’t got a clue how to use it.
What provides these? I’ve never seen them.
snap’s forced refreshes might be great for applications like youtube-dl, where any given process is likely to live for an hour or two at a maximum. It’s really bad on any process that can (and should) run for weeks or months without interruption.
Perhaps this is the source of the disconnect. Remove that 60 day business and we might be on to something.
Don’t let perfect be the enemy of good. A significant step forward would be moving that feature out of experimental and enabling it by default. And that should happen before this change.
To be clear: this won’t help CLI apps without desktop files(update: it will, see below), and it won’t help services, but it will help apps like Firefox.
they are normal desktop notifications that pop up and then sit in the clock/calendar after they vanished from screen …
so you are saying i should not upgrade my browser within the next 60 days when there is a security upgrade released and i get a notification popup to please close it to allow it to upgrade ?
Sure, that’s fine; all I know is I’ve heard this complaint about snap from dozens of people and several companies over the years. I feel this pain myself on the snap apps I use. I don’t want this pain to extend to the other applications I use.
Oh absolutely, and if were possible to agree more than wholeheartedly I would. But I think part of the problem with experimental features continuing to be zombies is that folks are asking for the world so the feature never feels ready. In reality, we just need some progress.
@sarnold could you please file a bug against snapd if you have refresh-app-awareness enabled, I don’t see the same behavior, for me refresh-app-awareness does work specifically for the matterhorn snap:
The notifications currently are created with the D-Bus API for org.freedesktop.Notifications.Notify, this may not work on all desktops I suppose but it certainly works on GNOME Ubuntu
. That’s been the status quo for years.