I'll leave others to make their own minds up, but I personally think the original article is FUD in a similar vein to some of the SystemD and Wayland nonsense that gets upvoted occasionally.
I don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues.
For example, OP says:
> Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions
The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissions. Well, ok, sure, that's definitely not "almost all", but that's still way too many.
I haven't used Flatpak (or Snap) before, but my impression of the technology was that it isolates apps and strongly sandboxes things so if you accidentally run something malicious, you're covered. But that doesn't seem to be the case, really. I get that this is a hard problem, and some things aren't even possible to do on X11, but then don't leave people with the belief that you can do all these things.
The response also says:
> Some directories, like ~/.local/share/flatpak/overrides, are blocked. Even if they have home or host access, they will still need explicit permissions to get read-write access to the blocked directories. Doing this with .bashrc, .zshrc and other shell configuration files would be very useful from a security standpoint to prevent sandbox escape.
That is just an awful approach to security. You need to deny by default and selectively allow, not allow by default and selectively deny. Applications do not need explicit permissions to get r/w access to blocked directories; they can simply append to ~/.bashrc or whatever, and bam, they have "permission".
I'd heard some bad things about Snap, but looks like I'll be staying away from Flatpak as well.
It's almost as if the people riding the "sandbox everything" wave have realized that an operating system is more than a set of disconnected pieces of software. And that to make it an operating system, those pieces must interact, and not be isolated from each other. Go figure.
Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.
We know some things are *objectively* better than the status quo. With attack surface as big as a modern browser or media player, not having sandboxing would be a mistake.
Just the people who are stuck to 1970's way of doing things and fear new things oppose sandboxing.
Sandboxing is fine, but it sounds like Snaps/Flatpaks don't actually do it because that would be too hard - so what's the point?
I get that some packages do actually have sandboxing, but unless it is mandatory and enforced I feel like I'm better off avoiding the ecosystem entirely and dealing with app isolation myself, using containers or VMs.
Snap/Flatpak are not doing it because that's not the layer which "does it". They provide the framework which allows since sandboxing today and will provide better sandboxing tomorrow. It's up to the app distributors to support it or not. We won't get full support immediately either.
It may be too hard today. But that's less "Flatpak is a security nightmare" and more "we're not using the features we have very well yet". I feel like some people expected 100% targeted profile for each app or will declare sandboxing a failure. This stuff will take years.
On average, I've found Snaps to be better sandboxed. But there are plenty of things to dislike about Snap e.g. not respecting XDG base directory spec, persistent daemon running as root, requiring sudo, unable to control when it decides to autoupdate, coarse grain "connection" system ...and more. A lot of obvious design mistakes that don't get fixed for one reason or another.
Well, they are also marketed as a way of isolating dependencies, which they do actually manage to some degree. So they could be weak security-wise without being completely pointless?
- have complicated permissions that users misunderstand or can be tricked into misconfiguring through inattention, misleading user interface or fatigue
- aren't actually sandboxes because the isolation they claim isn't actually achieved (I usually call these "security holes")
- are used to artificially force markets (e.g., Microsoft's UWP)
Other than that, they're great.
Signed, cranky, pre-morning-coffee programmer speaking ex cathedra from the 1970s
I think this is a valid criticism from flatpak / snap. But they are step in right direction about sandboxing (on the other hand bloat and developer trust are main problems abou these platforms for me).
> We know some things are objectively better than the status quo. With attack surface as big as a modern browser or media player, not having sandboxing would be a mistake.
Absolutely. That's why the comment that makes you characterize me as a luddite explicitly referred to the "sandbox everything wave".
Sandboxing has its place. Sandboxing everything (i.e. the "Flatpak way") is what I'm commenting on.
I think that GP's point still stands. Application security on most native platforms right now is a disaster. But application security on Linux is a dumpster fire. Yes, there are ways to do it better with SELinux, yes there are ways to isolate apps, but they're overcomplicated, inaccessible, and the end result is that most consumers don't use them.
Flatpak, for all of its many faults (and there are a lot of them), is still a strict improvement over the current security model running on most desktop Linux computers. Sandboxing native applications (even partially sandboxing them) is objectively better than the status quo.
It is embarrassing that the Linux community is still having this debate. It is exhausting, it feels like the community has to be dragged kicking and screaming away from a 20-year old security model that every other platform has moved on from.
I don't understand how you can honestly, truly say it's "technological ludditism" when it's clear that nobody in this thread is opposing the features that Flatpack and Snap claim to have, which in many forms predate UNIX and predate Flatpack/Snap -- they are just opposing the half-baked implementation that Flatpack/Snap have created.
So you think that disallowing access to word processor files to zip and unzip, or backup utilities, or ... is a perfectly reasonable way of doing things?
Because that's what we do on the web. Every app only has access to it's own files and 10 or so standard clipboard formats (and ONLY through the clipboard).
Having a portal that dictates file access would be a perfectly reasonable way of doing things, and that's the direction that Flatpak security is at least starting to move in.
There are security models that allow sharing files that don't give direct access to the entire filesystem. A word processor might need access to my Documents folder, but I might choose not to give it access to anything outside of that folder. Or I might choose to tell it it's been given access to a Documents folder, but really it has access to a VFS mount that is a composite of several folders inside of Documents including some shared folders outside of Documents.
This kind of "portal" idea is incidentally also what browser manufacturers are considering as they start to explore offering native file access[0] (although this is obviously an area that in browsers needs to be approached with a lot of caution). I don't think Google's proposal is the best way to handle this, I think it could be better. But it's still better than what's happening on desktops with native apps.
This has been the sandboxing method or choice since the 70s. Filesystem permissions were designed around users and groups, and now everybody's trying to bolt on intra-user access control lists and wondering why the experience sucks so much.
Create a `browser` user. Add yourself to the `browser` group. Maybe give `browser` read access to an area in your docs folder for convenience. Modify your browser launch script. Done.
In the default settings other users could not access the X server. I forgot how that is changed. I changed it once and now just copy the config
Biggest is getting the sound to work. Pulseaudio in system mode should do it. Although it is not recommended to use. And now my headphones do not work reliable anymore. Not sure if it is caused by system mode or by another setting.
And sharing files. Good that the browser cannot change my files, but it works both ways. My normal user cannot change the browser files, sometimes not even access the downloads.
This. I would expect a modern permissions model to be:
App has access to its own config/cache folders, and is implicitly and temporarily granted access to a file or directory on a process-lifespan basis when that file or dir is fed to that app through the file browser or through the application's "open file" file dialog box.
Possibly something more liberal could be granted for read permissions for like a gallery app or a music library thing, but that's what I'd expect for write permissions.
> temporarily granted access to a file or directory on a process-lifespan basis when that file or dir is fed to that app through the file browser or through the application's "open file" file dialog box.
I’m not sure if it’s temporary or process-lifespan basis, but AFAIK macOS’s sandbox does have a model where the user must grant access by using the system-provided out-of-process file dialog for the application to be able to access the files.
Pretty interesting. For an example, try renaming a file in MS Words by clicking on the document icon — you’ll see MS office asking for permission for the access of the parent directory. (Apple does provide rename functionality by it’s APIs, but MS Word does it by it’s own, which requires the permission.)
Definitely not perfect, but I wish people would lean on good old fashion unix more for these things instead of implementing it worse on top of it.
I skimmed the article and it looks like one thing they do is have a daemon in the background to intercept data in and out, when they could just make user groups and normal file permissions.
I know it's almost a meme at this point, but plan9 had a great system for this.
You were able to define a filesystem layered on top of your own, exposing and linking files/folders however you please to any process.
So say you have a web server. You can make a layer that only has /www and /configs, linked to some folder in /var/foo/webstuff, and /etc/fooserver/configs or something.
No reason why you couldn't standardize an interface for systems like flatpak to safely use your filesystem.
That is because it turns out that everyday software often needs such permissions to operate gracefully.
What is wanted is some system that allows one to run untrusted sofware in without fear of it compromising one's system. — the problem is that the set of software that can be so ran is smaller than expected, as most software by design is capable of making changes to one's system, as one typically uses software for such tasks.
A text editor that cannot edit every file in one's home directory would be rather useless, but in doing so, it is of course capable of completely destroying one's system as well.
The dream of being able to run “entrusted software” is not a very realistic one.
No, I think what got us into this mess is Ubuntu being a server distro with a standard release cycle (as opposed to rolling release) getting incredibly popular on desktops.
Desktop users want the newest version of their UI apps and don't care so much about stability. Ideally, the developers of e.g. Inkscape would offer the newest version on each Ubuntu version via apt, but that does not seem to be feasible.
I am no Arch user myself, but I think a rolling release is much more suitable for desktop use. I don't have the feeling most people use Snap/Flatpack for their sandbox, but much rather for getting a new version of some software.
That would be quite surprising since Ubuntu Server appeared only after Ubuntu Desktop was already the #1 desktop Linux distribution (free CDs shipped worldwide, etc).
Canonical started developing sandboxed packages for Ubuntu phones ("click" packages which evolved into "snap" packages). At about the same time, Canonical was interested in getting other big distributions (RedHat, Suse...) to align on what software (kernel, glibc, GNOME, KDE...) to offer LTS on together, but there wasn't too big of an interest from other distributions (and tbh, I think that's a good thing: upstream open source projects would be strong-armed into caring about only a few versions that monopolist distros decided to base their LTSes on).
It is my guess that Canonical has (post-phones) invested in snaps to reduce the burden of maintaining the desktop and trying to earn some money in the process through the Snap Store. Flatpak seems to be Red Hat's slightly more open response that quickly followed.
The only benefit of Snaps/Flatpak for delivering newer versions of apps over just simply statically compiling everything into an app is that some of the things are shared between snaps (like frameworks, glibc...). You still get all of the same problems (theming, fonts,...).
> Desktop users want the newest version of their UI apps and don't care so much about stability.
[Citation needed]. Can you imagine telling this to someone who is about to present on a conference call, but zoom updated automatically and fails to start now?
If you define "care" as in, "random updates cause enough instability that they make alternate OS's favorable for accomplishing the same tasks," I'd cite Windows autoupdate as fairly hard evidence that people don't care.
I imagine MS has crunched the numbers at some point, and decided that the amount of lost work and interruptions due to forcible updates (especially contrasted with the benefits of updates) is not causing a significant number of people to ditch their OS for a competitor.
Competitor? Windows is still >85% of desktop use or thereabouts - you can buy an expensive mac or you can go to hell and try out linux; neither is really an alternative for many so they just accept what happens.
So why do they bother adding new features to Windows?
I'll answer my question: Companies make decisions on the margin. They don't care that they have 85% of the market. They want that next percentage point.
The users who might switch to or from competitors are precisely the "swing voters" they have to consider.
Sandboxing does not mean no interaction. It means supervised interaction between apps where the user is in control of what to allow and what not. I'm not sure how well Flatpack does it (never used it) or Snap does it (used quite a bit but never tested how well it sandboxes) but there are other platforms that handle sandboxing pretty well and then provide APIs on top to allow interaction with the system and other apps (iOS, Android, Meego for example).
Snap and flatpak: they suffer from identical problems (in the snap world, these are "classic" snaps which get almost no restrictions).
Any app that needs to save files in your home directory, which all the traditional apps do (Gimp, Inkscape, *Office...), has to have r/w access to your home directory (duh).
So I would venture to say that this is all misleading marketing, which is mostly what the OP complains about too.
It all boils down to the same discussion we had 20 years ago: Linux proponents talked about how much better it was when it comes to viruses because only your $HOME would be affected, somehow missing to realize that in mostly single user desktops, that was the only thing anyone really cared about.
(I've exclusively used GNU/Linux systems since 1999, but not for made-up reasons like that :))
Flatpak/snap model is the one where app controls your data (which allows them to only need access to a certain subdirectory of $HOME—think Steam or Spotify), instead of allowing you to group files related by topic instead.
And that's exactly the model I don't subscribe to :)
A capability model fixes this: the application launches a file chooser which it does not control, which can then return it an fd or other token giving the application the capability to read from or write to a specific file.
Of course, this would be a considerable effort. But it's probably where we're going.
I've long argued for applications to use file choosers they do not control, but not for security reasons. I've wanted it for UI reasons.
Somewhere I've got a screenshot of a Linux system I had with half a dozen applications trying to open a file. Each used a different GUI framework or widget toolkit, each of which had its own file dialogs, and so the user gets presented with half a dozen different file choosing UIs. It was completely ridiculous.
Making the UI suck less was not a good enough reason to get any of the major GUI frameworks to support separating file choosing from apps. Maybe improving security will be a good enough reason.
Major GUI frameworks agree with you and have already adopted this approach and it is already used by many applications, and this has already been the case for years.
As mentioned above, Flatpak is already doing the two most popular toolkits. Programs just don't use toolkits to open files. So there is not a lot of "buck" here, and the tail is rather long.
Can't the sandbox override the corresponding syscalls? E.g. open() and readdir() which then block until the user has selected the file? This means you'll have to click the file twice (once for the sandbox and once for the application) but at least it is more secure.
Of course, in "classic" apps, there is explicitly no protection. They don't promise it, and you don't get those by default when trying to install a snap.
From my perspective as a Flatpak user I can say I hate how the current file access restrictions are implemented, it's confusing and annoying.
I use a messenger installed via Flatpak. So whenever I receive a file in it I cannot save it anywhere outside my Downloads folder. So every single time I then have to open a file manager and manually move the file somewhere else. Similar for the other way around - I have to copy any file I want to send into either ~/Downloads or ~/Pictures. Not a single other path is visible or accessible, if I click on "Desktop" in the list of favorites nothing happens. This is confusing and annoying for me, this would be super confusing for a user who doesn't know and care about file permissions.
I like flatpak as it can nicely fill gaps in official repositories whitout being bound to a single distro family once again. But honestly I understand why apps would just go "allow all", because anything else drives the user insane the way it is implemented now.
You can use flatseal[0] to allow apps access to extra folders in the filesystem. It's a GUI app that makes it much easier than learning how to do the same thing from the command line.
Took me a while to figure out that Signal can't save outside of Downloads as well, especially since its not the default dir it opens when trying to save an file. There's no feedback of any kind.
I see flatpak more as a distro independent package format than a way to secure my system.
Exactly, the lack of feedback is the worst part of this. The way it's done right now it looks like the file picker is completely broken and riddled with bugs; the user goes in expecting it to behave normally(given that it looks exactly the same) but it won't show files in the home dir, refuses to even show user-created directories etc.
Even a horrible and annoying pop-up dialog saying something like "file access error" would be better, at least it would be easier to google.
More confusing one is that flatpaks can't access mount points inside your home directory even with the correct flatpak permissions set.
Assume that you are running Steam as a flatpak and you want to add an extra drive to store your Steam library on and you have your extra drive already automounted inside your home directory and the correct flatpak permissions set, Steam will not find it anyway.
You have to use a mount point outside of your home directory to get that to work.
If that can make you feel better, it is exactly as annoying for mac os apps on the mac app store. I don't know anyone using Mac professionally (for e.g. design, etc...) who uses AppStore apps because of that
This way of dealing with file-access is also not secure: if all your files eventually end up in a Downloads folder which is readable by all Flatpak apps, then what advantage does this have over sharing your entire home folder?
>The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissions. Well, ok, sure, that's definitely not "almost all", but that's still way too many.
The response article did also note that the most popular flatpak apps are often ones that really need filesystem access in order to function properly, e.g. an IDE, an image editing program, an audio editing program, etc.
It's really hard to conceive of how these programs would work without some of the requested permissions. I remember the hazards of trying to get a proper IDE on ChromeOS some years back because of Google's own sandbox restrictions on allowing extensions to access the chromebook's filesystem. IIRC there was a company that even created "cloud-IDE" environments to get around this limitation.
Couldn't it be possible to ask the user to allow certain directories or files? It might be kind of annoying but it would be safer.
Also, it could integrate with the open file dialog and only allow the application to access files selected by the user, and nothing else. That would be tough because the developer would have to integrate with flatpak APIs, and I don't think flatpak is big enough for developers to care. But that would be ideal since it's safe but also not annoying.
> That would be tough because the developer would have to integrate with flatpak APIs, and I don't think flatpak is big enough for developers to care.
For GTK apps, they don’t need to do anything different, as GtkFileChooserNative[1] is recommended for non-sandboxed apps as well. GtkFileChooserNative has glib call the D-Bus API (which is proxied inside the sandbox) for the FileChooser portal[2]. The backend running outside the sandbox (xdg-desktop-portal-gtk for GNOME/GTK; there are also backends maintained by KDE and wlroots developers) shows a file chooser and makes any file (since March 2020, there is also support for folders) selected by the user available inside the sandbox using the Documents portal.
Also the portal APIs are not specific to Flatpak. They can be used by any sandboxing framework that wants to benefit from the work already done to integrate them.
Some apps don’t use GTK or Qt, some apps (like GIMP) still use GTK 2, which doesn’t have GtkFileChooserNative, and some apps haven’t been ported from GtkFileChooserDialog to GtkFileChooserNative (or can’t be ported yet because of missing features in the latter). And the Documents portal doesn’t work perfectly for all use cases: There are issues with getting notified when a file is modified externally and with getting the path of the file outside the sandbox (to display it to the user, if that’s desired).
I use flatpaks all the time and I almost always have to adjust these permissions to be more restrictive.
It's really not an issue with flatpak itself, it's the maintainers who give permissions that are not restrictive enough. It's understandable because it makes it easier to package and maintain.. but it also kind of makes the whole concept useless.
What I personally want is apps which are as, if not more restricted than mobile apps.
I use Flatpak extensively and I fully agree with you and the author of the response that there is a need to balance practicality vs. idealism when it comes to (fully auditable) FlatPak apps, as well as FlatHub's overall approach and continual work within the desktop Linux ecosystem.
What's more, the fact that an entire domain was devoted to what could have been a blog post gives credence to the responder's notion that this is FUD which, while valid for discussion, is most certainly not beneficial to the FOSS community writ large.
Either way, from the article you linked TIL about Flatseal[0] so I'll be taking that for a spin!
The criticism and response typically boils down to "Yes, but its actually not any worse than what we have now"
If you manually install a rpm, deb or add a new repo, your system is completely owned by the person who built that package or repo. The biggest problem is that flatpak advertises sandboxing when some apps disable it but I imagine in the future we will get better UI around showing the user exactly what gets exposed as well as less permissions being given to packages.
The thing is that messaging is the important bit here.
If I have Debian apt archives in my sources.list, I understand the risks, just like a pure Windows user does: other than bugs, you might be affected if someone hacks Debian/Microsoft and that's it (or, of course, someone internal to them decides to do it).
Flatpaks/snaps are designed to be built by less-trusted parties and promise things they know they can't deliver on. Now I am suddenly asked to trust these external developers that they will be as adamant with security fixes, be non-malicious, etc. And flatpak/snap are trying to convince me how that's a non-issue "because sandboxing".
Sure, we here understand the underlying technologies so we can make our own educated guesses, but majority of the people who this is aimed at don't.
Since you also mentioned "add a new repo", there are some repos you can trust even if they are not the official ones. PPAs on Launchpad build from source packages, so you can always get the source first ("apt-get source package" after adding the repo). If someone is just bundling binaries and the build is a no-op, you can drop the repo right away. Sure, it requires some effort and you won't be checking every repo, but for sufficiently popular repos, somebody would be doing that.
It'd be ideal if apr grew support for limiting packages that can come out of a repo, so you'd have to whitelist when something new pops up ("hey, this repo has now introduced libc version X, and your libc is coming from repo main: do you want to allow upgrades from non-main repo to libc? [only once] [yes] [no]").
I decided to look at the messaging - the websites of both Flatpak[0] and Snap[1] make no claims about security, or about being "designed to be built by less-trusted parties".
Both of them focus more heavily on the convenience of distribution than any user-facing benefits such as sandboxing.
If you're referring to the GNOME Software "Sandboxed" badge, it still indicates that there are some universal properties of the sandbox. (For example, flatpak apps live in their own PID namespace and cannot see what other processes are running on your system.) Also, there is a permissions badge on the right that does indicate the level of access you'd be granting to the app. (Full $HOME access is indicated with High, and a click on the badge tells you exactly what it needs.) There could be some work needed to do around guarding `.bashrc` and similar, though.
In addition, Flatpaks and Snaps are both served as repos - a `.flatpakref` for instance is just a reference to a repo. Using a `.flatpakref` to install software is like adding a repo to your sources.list, but in ways more secure:
1) Flatpak doesn't have the concept of install scripts (and doesn't have a way to install a setuid binary), so just installing an app won't cause a security hole. On the other hand, a `.deb`/`.rpm` can run arbitrary code as root in the install scripts.
2) Packages on Flatpak are scoped to the repo you installed them from - for example, if you request `org.gnome.Calculator` from flathub, another repo can't serve version 10000 of the same app and have users install it. If the same app is available on multiple repos, flatpak will prompt you and ask what version to install.
example output for `flatpak install org.gnome.Calculator`:
Remotes found with refs similar to ‘org.gnome.Calculator’:
"Convenience of distribution" is, by nature, targeted at application distributors which are not the end-users I (or the OP) claimed to be affected by the messaging.
So yes, I think the messaging in GNOME Software should be improved (hard for me to check on Ubuntu because it does not come with Flatpak support on by default).
Note that ".bashrc and similar" is a huge amount of files (just off the top of my head, .profile, .zshrc, .cshrc, .Xsession, .xinitrc, .ssh/config [for eg. ProxyCommand]... you get the gist).
The sandboxing is not always weak. On most apps its almost fully locked down and has access to only your downloads folder. Its only things like vscode which need everything.
You can also manually set permissions using flatseal to lock it down as much as you want.
Putting a blue shield on "sandboxed" when allowing (write!) access to my home directory falls on the extreme side of "weak" to me.
Sure, they are capable of locking it down better. But they haven't in 2+ years. It shows where their priorities are.
Flatseal I'll have to look into though, thanks! A user-controllable method is always a plus, and I do love sandboxes. Most apps need very little access, and locking them down prevents a LOT of kinds of misbehavior, intentional or accidental.
Access to a shared downloads folder doesn't sound “fully locked down” to me. I can imagine situation where I wouldn’t want one app to see what is downloaded by other apps.
Would be better if each process had its own downloads folder (it’s own file system namespace even).
Each flatpak app does have its own namespace and dir it can save whatever it wants to. Some packages like the MS teams one have been given access to downloads only so you can share files with people. You can turn off this access if you want.
Flatpak also has a thing called portals which let the program request a privileged filepicker so the user can select any file and the filepicker grants access to it for the program. The problem is not all apps are set up to work properly with this right now.
Flathub actually does review submissions reasonably well. You have to give a justification for each permission you request and why it couldn't be done in any other way.
It is hard to guess at motives when author is unknown.
Or when neither of the CVE links go anywhere.
Maybe I've understood how Flatpaks work incorrectly (please correct me if so), but the applications are ran in containers. So how would an attacker exploit CVE-2019-17498 on a Gitg? Its not like Gitg has a port open for listening incoming messages.
With ffmpeg I don't know if things like Chromium are actually using the flatpak ffmpeg or if they ship with their own libs.
You've misunderstood "how Flatpaks work": they are using the same system calls that containers use for containerization but in a different way, look at https://en.wikipedia.org/wiki/Linux_namespaces (Snaps use AppArmor too if that's a more familiar technology).
They are not containers in themselves: if you feel this is pedantic, the way namespaces are used can make all the difference (eg. why you should not be running stuff in docker containers as root which can easily be used to get root on the host).
Which is good as one should discuss the merits of the arguments brought forth when discussing the pros and cons of a technology rather than who who said it or what motives they might have.
Edit: when I wrote this comment only the first sentence of the parent existed.
I find your takeway that it is f.u.d. from this response quaint.
To sum up the issues:
- We agree that write access to the entire home directory compromises any and all security, but we are aware of the problem and trying to fix it.
- We checked the claim of “Many of the popular flatpack applications still have access to the entire home directory,” and conclude that 23 of the 50 most popular ones do.
- We partially disagree that the “sandboxed” icon is misleading, because it does limit some things, even though we as per issue one agree that access to the full home directory gives malware carte blanche.
- We agree on the point that the outdated example library with a vulnerability used is true as stated.
- We agree with the issue, but we have a tool built that mitigates it by altering developers.
I hardly would say that this rebuttal amounts to showing “f.u.d.”; — it alleges no technical falsehood in the article, but at some points simply disagrees that it is as much of a problem as the article claims it is, not numerically in terms of facts, but simply disagreeing on whether full write access to the home directory is truly such a big issue as the original article makes it out to be.
> Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions
TheEvilSkeleton counts them and 23 out of 50 is not almost all, so that is a technical falsehood, albeit not one that invalidates the author’s point. There are other falsehoods that do invalidate the author’s points. This one, for example:
> Two years is not enough to add a warning that an application is not sandboxed if it comes with dangerous permissions (like full access to your home directory)?
This is wrong because GNOME Software did, before the flatkill author’s 2020 update, add a warning (which is missing from the author’s screenshot) indicating that the app has high permissions and can access all files and folders (it’s still described as sandboxed, which technically it is, just with the ability to escape the sandbox; further changes to GNOME Software to make this clearer are already planned). The author’s screenshot was presumably taken using an outdated version of GNOME Software; they should have checked more recent versions before making claims about what features developers did or did not add.
And here’s another falsehood:
> So I need to run multiple fcitx daemons on my desktop and switch between them as I switch flatpak apps depending on which fcitx libraries are bundled with that app
The flatkill author misunderstood the implications of the bug report (in addition to seemingly misunderstanding where fcitx comes from; it’s part of the runtimes, rather than being bundled with each app). The issue was caused by a change in Flatpak, fixed in fcitx, and there is no need for the fcitx versions to match going forward.
I'll leave others to make their own minds up, but I personally think the original article is FUD in a similar vein to some of the SystemD and Wayland nonsense that gets upvoted occasionally.