Snap is very easy to break out of because they use braindead nonstandard ways for confinement that only work for Ubuntu. They never bothered to fix that even though already more than half a decade has passed.
Flatpak uses standardized Bubblewrap for sandboxing, which relies on extremely simple but reliable and battle-tested standard Linux kernel features. The sandboxing mechanism is distro-independent and is regularly tested. Many non-rolling distros also give the Flatpak package an update cycle exemption which means that all new sandbox and security features rapidly arrive to everybody who regularly install updates.
> The one and only true sandbox packages are on systems running Windows XX. They keep everything away from system files, registry and etc.
UWP? Yes, that's a good example of sandboxing, but for non-sandboxing stuff, UWP is a steaming pile of garbage.
> Even non-AppArmor stuff has some confinement, just a lot weaker
My understanding is that without AppArmor, snaps can see the entire filesystem. That would make them about as secure as a flatpak with `filesystem=host`, i.e. not at all.
https://forum.snapcraft.io/t/snap-vendor-lock-in-approach-to-confinement-is-problematic/25018
that first blog is from 2016. a lot has changed since then. second blog relies on the fact that flatpak has access to the home directory. of course it does because applications need to read files.
> of course it does because applications need to read files.
I have to disagree with this a bit. Apps with full home access are effectively unsandboxed. Users should be aware of this, and so GNOME Software now labels such apps as "Potentially Unsafe".
However, this is a necessary stepping stone; if Flathub had forbidden `filesystem=home`, flatpak never would have taken off like it has. The goal is for most apps to use portals instead of having sandbox-escaping permissions, and there are plenty that meet that standard already.
you found a blog and another blog (?) with a creative domain... and then a Reddit post taking about the latter
after that I rest my case, you are right. it's over, snaps won. from now on I will not trust Fedora anymore and their review process. because I read this, thanks to you.
how can I trust a distro that comes with flatpak pre installed. and if I don't trust that I can't trust in anything multiple people have done in the process to create a distro.
again, thank you
I'm fine using Flatpaks I feel fine using them. You can build the most secure living quarters; that doesn't mean anyone would really want live in a maximum security prison.
If you want want safety and security you must do one of two things. You must read, understand, vet and verify every single line of code that runs on your system. OR you must put trust into something/someone. You put trust in your distro, why wouldn't you trust a flatpak from Fedora?
[Sandboxes](https://docs.flatpak.org/en/latest/basic-concepts.html#sandboxes)
>With Flatpak, each application is built and run in an isolated environment, which is called the ‘sandbox’. Each sandbox contains an application and its runtime. By default, the application can only access the contents of its sandbox. Access to user files, network, graphics sockets, subsystems on the bus and devices have to be explicitly granted. Access to other things, such as other processes, is deliberately not possible.
By necessity, some resources that are inside the sandbox need to be exposed outside, to be used by the host system. These are known as ‘exports’, since they are files that are exported out of the sandbox, and include things like the application’s .desktop file and icon.
So flatpaks have been granted, on install, access to 'other things' to make the app behave in a manor a user expects. If you don't want an app to have access to the network you can remove such permission, same for files.
What to you is a safe secure system to you?
I hate flatpak and snap packages. They take up a lot of space, they start slowly, ...
The standard distro native packages (deb, rpm, etc) are secure enough!
Flatpak has never had any issues with speed (and snap is supposedly much improved now).
Canonical pushing snap with its original absurdly slow startup and thus planting the idea that sandboxed apps are inherently slow might be the most harmful thing they've ever done to the linux ecosystem.
> The standard distro native packages (deb, rpm, etc) are secure enough!
If by 'secure enough' you mean running arbitrary code as root, then sure.
Flatpak apps starts very slowly compared to standard packages.
If you use packages from trusted sources, you don't have to worry about security. If you use packages from untrusted sources, the package format won't really protect you from anything.
> Flatpak apps starts very slowly compared to standard packages.
Do you have any data to back up this claim?
> If you use packages from untrusted sources, the package format won't really protect you from anything.
There is a fundamental difference between flatpak and native packages here. Installing a flatpak does not execute vendor-supplied code. And as long as you verify that the sandbox is intact (e.g. GNOME Software labels it 'Safe'), you're pretty safe to run it also.
Even if you trust the code in native packages, you still have to contend with security vulnerabilities. For example, I hope you never open untrusted PDFs in an unsandboxed libpoppler-based PDF viewer.
The first flatpak that you launch after a reboot will be slower by a few milliseconds to launch than your typical rpm. I dont know why that is (probably having to reload some libraries that would have already been within memory for rpms? idk) and I dont think it matters much. But i guess it's true in a very limited sense.
Well, on real world all flatpak apps have an access to home directory (I can't think of many apps that would be useful without it), so they can do whatever they want with your data, write their code to ~/.profile, etc. Most valuable thing on your computer is your data and it is accessible without root, so flatpak apps are as insecure as deb or rpm.
It's more than I'd like, but certainly not all. Consider something simple like GNOME Calculator. It has network access to check real-time exchange rates for currency conversion, so it's theoretically exploitable. The flatpak is completely locked down (except for network access), so it's safer than the native version.
As another example, Firefox only has access to `~/Downloads` by default.
A lot of the flatpaks that have excessive filesystem permissions do so in support of some obscure or edge-case feature. You can often disable the permissions in Flatseal and have the app still work (YMMV). I did this with Evince, for example. It originally had `filesystem=host`, which was later reduced to `filesystem=home:ro` (read-only) plus access to removable media. That is a significant improvement, but still not ideal. It doesn't need any of that to open PDFs, so I removed it.
> I can't think of many apps that would be useful without it
That's what the File Chooser portal is for.
>Do you have any data to back up this claim?
lol everyone knows that, this is a common experience. Let me show you:
[https://forum.manjaro.org/t/flatpaks-very-slow-to-start/104629](https://forum.manjaro.org/t/flatpaks-very-slow-to-start/104629)
[https://discussion.fedoraproject.org/t/gtk-and-any-flatpak-apps-are-now-extremely-slow-starting-in-plasma/80563](https://discussion.fedoraproject.org/t/gtk-and-any-flatpak-apps-are-now-extremely-slow-starting-in-plasma/80563)
[https://forum.manjaro.org/t/firefox-starts-very-slow/107124](https://forum.manjaro.org/t/firefox-starts-very-slow/107124)
[https://github.com/flatpak/flatpak/issues/4211](https://github.com/flatpak/flatpak/issues/4211)
[https://www.reddit.com/r/Fedora/comments/rdnse5/are\_flatpaks\_slow\_or\_is\_it\_just\_snaps/
https://forums.linuxmint.com/viewtopic.php?t=319106](https://www.reddit.com/r/Fedora/comments/rdnse5/are_flatpaks_slow_or_is_it_just_snaps/%20https://forums.linuxmint.com/viewtopic.php?t=319106)
[https://www.reddit.com/r/pop\_os/comments/sxv95n/flatpaks\_are\_very\_slow\_to\_load\_on\_pop/](https://www.reddit.com/r/pop_os/comments/sxv95n/flatpaks_are_very_slow_to_load_on_pop/)
[https://www.reddit.com/r/suckless/comments/swbx8l/flatpak\_starts\_up\_applications\_much\_slower\_when/](https://www.reddit.com/r/suckless/comments/swbx8l/flatpak_starts_up_applications_much_slower_when/)
[https://forums.opensuse.org/t/why-are-flatpaks-that-slow-under-opensuse/151172](https://forums.opensuse.org/t/why-are-flatpaks-that-slow-under-opensuse/151172)
[https://community.learnlinux.tv/t/slow-startup-of-applications/2639](https://community.learnlinux.tv/t/slow-startup-of-applications/2639)
If you open a pdf with a software that can read or write in your home, you are not safe. And there can be a security part in any program, also in the flatpak runtime.
Most of those can be attributed to bugs and/or misconfiguration. There was a well-known issue where x-d-p-gnome being installed would cause a long startup delay in non-GNOME environments. That bug is now fixed.
So yes, software has bugs. I'm talking something inherent with the design or implementation of flatpak (like the infamous snap issue).
Also, your third link has nothing to do with flatpak.
When you starts a flatpak app, the runtime must to load and initialize the the needed platforms, for example org.freedesktop.Platform, org.freedesktop.Platform, org.gnome.Platform, ....
This is not a bug, this is a design decision. A flatpak app is ALWAYS slower than the same non-flatpak app.
The files already exist unpacked on the filesystem in e.g. `/var/lib/flatpak/runtime/org.freedesktop.Platform/...`. Initializing the runtime basically means making some bind mounts inside a namespace.
How long do you think that takes? You can try it yourself:
time flatpak run --command=true org.gnome.Calculator
I typically get around 120ms across multiple apps.
I raise my hand, I still don't want to use anything outside my distros package management, be it flatpaks, snaps or appimages or whatever.
Not a single one of these systems fix the fundamental problem with packaging in the Linux ecosystem. They make it worse. Now there's a packaging system of your OS, and a dozen alternative solutions concurrent with packages dependant on one guy producing a working package supposedly working on everything. What a load of nonsense!
I can use rclone, but...
I recommend Flatpak Dropbox instead of Dropbox.deb.
Install Dropbox with Flatpak and connect your account. 2.
After the connection is complete, restrict access to the Home folder with Flatseal.
Partially allow :
\~/.var/app/com.dropbox.Client
\~/Dropbox
\~/.dropbox
\~/.dropbox-dist
/tmp
Flatpak can use access restrictions on its own like this.
You can see permissions for each Flatpak that you install. And you can modify the permissions using Flatseal. If course the UI/UX could still be improved, but the underlying technology is completely trustworthy and reliable.
Snap is very easy to break out of because they use braindead nonstandard ways for confinement that only work for Ubuntu. They never bothered to fix that even though already more than half a decade has passed. Flatpak uses standardized Bubblewrap for sandboxing, which relies on extremely simple but reliable and battle-tested standard Linux kernel features. The sandboxing mechanism is distro-independent and is regularly tested. Many non-rolling distros also give the Flatpak package an update cycle exemption which means that all new sandbox and security features rapidly arrive to everybody who regularly install updates. > The one and only true sandbox packages are on systems running Windows XX. They keep everything away from system files, registry and etc. UWP? Yes, that's a good example of sandboxing, but for non-sandboxing stuff, UWP is a steaming pile of garbage.
[удалено]
> Even non-AppArmor stuff has some confinement, just a lot weaker My understanding is that without AppArmor, snaps can see the entire filesystem. That would make them about as secure as a flatpak with `filesystem=host`, i.e. not at all. https://forum.snapcraft.io/t/snap-vendor-lock-in-approach-to-confinement-is-problematic/25018
that first blog is from 2016. a lot has changed since then. second blog relies on the fact that flatpak has access to the home directory. of course it does because applications need to read files.
> of course it does because applications need to read files. I have to disagree with this a bit. Apps with full home access are effectively unsandboxed. Users should be aware of this, and so GNOME Software now labels such apps as "Potentially Unsafe". However, this is a necessary stepping stone; if Flathub had forbidden `filesystem=home`, flatpak never would have taken off like it has. The goal is for most apps to use portals instead of having sandbox-escaping permissions, and there are plenty that meet that standard already.
🙋♂️ Check permissions before installing duh, they are shown before installing in cli
And even in GUIs like GNOME Software and Plasma Discover for the most part
you found a blog and another blog (?) with a creative domain... and then a Reddit post taking about the latter after that I rest my case, you are right. it's over, snaps won. from now on I will not trust Fedora anymore and their review process. because I read this, thanks to you. how can I trust a distro that comes with flatpak pre installed. and if I don't trust that I can't trust in anything multiple people have done in the process to create a distro. again, thank you
>"I cannot raise my hand!" maybe you should see a doctor... your 3rd link is linking to the same post as your 2nd link btw
I'm fine using Flatpaks I feel fine using them. You can build the most secure living quarters; that doesn't mean anyone would really want live in a maximum security prison. If you want want safety and security you must do one of two things. You must read, understand, vet and verify every single line of code that runs on your system. OR you must put trust into something/someone. You put trust in your distro, why wouldn't you trust a flatpak from Fedora? [Sandboxes](https://docs.flatpak.org/en/latest/basic-concepts.html#sandboxes) >With Flatpak, each application is built and run in an isolated environment, which is called the ‘sandbox’. Each sandbox contains an application and its runtime. By default, the application can only access the contents of its sandbox. Access to user files, network, graphics sockets, subsystems on the bus and devices have to be explicitly granted. Access to other things, such as other processes, is deliberately not possible. By necessity, some resources that are inside the sandbox need to be exposed outside, to be used by the host system. These are known as ‘exports’, since they are files that are exported out of the sandbox, and include things like the application’s .desktop file and icon. So flatpaks have been granted, on install, access to 'other things' to make the app behave in a manor a user expects. If you don't want an app to have access to the network you can remove such permission, same for files. What to you is a safe secure system to you?
I hate flatpak and snap packages. They take up a lot of space, they start slowly, ... The standard distro native packages (deb, rpm, etc) are secure enough!
Flatpak has never had any issues with speed (and snap is supposedly much improved now). Canonical pushing snap with its original absurdly slow startup and thus planting the idea that sandboxed apps are inherently slow might be the most harmful thing they've ever done to the linux ecosystem. > The standard distro native packages (deb, rpm, etc) are secure enough! If by 'secure enough' you mean running arbitrary code as root, then sure.
Flatpak apps starts very slowly compared to standard packages. If you use packages from trusted sources, you don't have to worry about security. If you use packages from untrusted sources, the package format won't really protect you from anything.
> Flatpak apps starts very slowly compared to standard packages. Do you have any data to back up this claim? > If you use packages from untrusted sources, the package format won't really protect you from anything. There is a fundamental difference between flatpak and native packages here. Installing a flatpak does not execute vendor-supplied code. And as long as you verify that the sandbox is intact (e.g. GNOME Software labels it 'Safe'), you're pretty safe to run it also. Even if you trust the code in native packages, you still have to contend with security vulnerabilities. For example, I hope you never open untrusted PDFs in an unsandboxed libpoppler-based PDF viewer.
Yeah I haven't experienced Flatpak being slow at all. I have Spotify, Jellyfin, and Discord in Flatpaks and they all launch pretty snappily.
The first flatpak that you launch after a reboot will be slower by a few milliseconds to launch than your typical rpm. I dont know why that is (probably having to reload some libraries that would have already been within memory for rpms? idk) and I dont think it matters much. But i guess it's true in a very limited sense.
Well, on real world all flatpak apps have an access to home directory (I can't think of many apps that would be useful without it), so they can do whatever they want with your data, write their code to ~/.profile, etc. Most valuable thing on your computer is your data and it is accessible without root, so flatpak apps are as insecure as deb or rpm.
It's more than I'd like, but certainly not all. Consider something simple like GNOME Calculator. It has network access to check real-time exchange rates for currency conversion, so it's theoretically exploitable. The flatpak is completely locked down (except for network access), so it's safer than the native version. As another example, Firefox only has access to `~/Downloads` by default. A lot of the flatpaks that have excessive filesystem permissions do so in support of some obscure or edge-case feature. You can often disable the permissions in Flatseal and have the app still work (YMMV). I did this with Evince, for example. It originally had `filesystem=host`, which was later reduced to `filesystem=home:ro` (read-only) plus access to removable media. That is a significant improvement, but still not ideal. It doesn't need any of that to open PDFs, so I removed it. > I can't think of many apps that would be useful without it That's what the File Chooser portal is for.
>Do you have any data to back up this claim? lol everyone knows that, this is a common experience. Let me show you: [https://forum.manjaro.org/t/flatpaks-very-slow-to-start/104629](https://forum.manjaro.org/t/flatpaks-very-slow-to-start/104629) [https://discussion.fedoraproject.org/t/gtk-and-any-flatpak-apps-are-now-extremely-slow-starting-in-plasma/80563](https://discussion.fedoraproject.org/t/gtk-and-any-flatpak-apps-are-now-extremely-slow-starting-in-plasma/80563) [https://forum.manjaro.org/t/firefox-starts-very-slow/107124](https://forum.manjaro.org/t/firefox-starts-very-slow/107124) [https://github.com/flatpak/flatpak/issues/4211](https://github.com/flatpak/flatpak/issues/4211) [https://www.reddit.com/r/Fedora/comments/rdnse5/are\_flatpaks\_slow\_or\_is\_it\_just\_snaps/ https://forums.linuxmint.com/viewtopic.php?t=319106](https://www.reddit.com/r/Fedora/comments/rdnse5/are_flatpaks_slow_or_is_it_just_snaps/%20https://forums.linuxmint.com/viewtopic.php?t=319106) [https://www.reddit.com/r/pop\_os/comments/sxv95n/flatpaks\_are\_very\_slow\_to\_load\_on\_pop/](https://www.reddit.com/r/pop_os/comments/sxv95n/flatpaks_are_very_slow_to_load_on_pop/) [https://www.reddit.com/r/suckless/comments/swbx8l/flatpak\_starts\_up\_applications\_much\_slower\_when/](https://www.reddit.com/r/suckless/comments/swbx8l/flatpak_starts_up_applications_much_slower_when/) [https://forums.opensuse.org/t/why-are-flatpaks-that-slow-under-opensuse/151172](https://forums.opensuse.org/t/why-are-flatpaks-that-slow-under-opensuse/151172) [https://community.learnlinux.tv/t/slow-startup-of-applications/2639](https://community.learnlinux.tv/t/slow-startup-of-applications/2639) If you open a pdf with a software that can read or write in your home, you are not safe. And there can be a security part in any program, also in the flatpak runtime.
Most of those can be attributed to bugs and/or misconfiguration. There was a well-known issue where x-d-p-gnome being installed would cause a long startup delay in non-GNOME environments. That bug is now fixed. So yes, software has bugs. I'm talking something inherent with the design or implementation of flatpak (like the infamous snap issue). Also, your third link has nothing to do with flatpak.
When you starts a flatpak app, the runtime must to load and initialize the the needed platforms, for example org.freedesktop.Platform, org.freedesktop.Platform, org.gnome.Platform, .... This is not a bug, this is a design decision. A flatpak app is ALWAYS slower than the same non-flatpak app.
The files already exist unpacked on the filesystem in e.g. `/var/lib/flatpak/runtime/org.freedesktop.Platform/...`. Initializing the runtime basically means making some bind mounts inside a namespace. How long do you think that takes? You can try it yourself: time flatpak run --command=true org.gnome.Calculator I typically get around 120ms across multiple apps.
`time flatpak run --command=true org.gnome.Calculator` `real 0m0,406s` `user 0m0,023s` `sys 0m0,014s`
I raise my hand, I still don't want to use anything outside my distros package management, be it flatpaks, snaps or appimages or whatever. Not a single one of these systems fix the fundamental problem with packaging in the Linux ecosystem. They make it worse. Now there's a packaging system of your OS, and a dozen alternative solutions concurrent with packages dependant on one guy producing a working package supposedly working on everything. What a load of nonsense!
I can use rclone, but... I recommend Flatpak Dropbox instead of Dropbox.deb. Install Dropbox with Flatpak and connect your account. 2. After the connection is complete, restrict access to the Home folder with Flatseal. Partially allow : \~/.var/app/com.dropbox.Client \~/Dropbox \~/.dropbox \~/.dropbox-dist /tmp Flatpak can use access restrictions on its own like this.
You can see permissions for each Flatpak that you install. And you can modify the permissions using Flatseal. If course the UI/UX could still be improved, but the underlying technology is completely trustworthy and reliable.
Thought they debunked most those. None the less I feel safe using flatpak esp if they are from the developers themselves