A sandbox doesn't mean "you can never do [foo]." A sandbox means "you can never doo [foo] unless the user lets you." Even web browsers (the classical "true sandboxes") have an API that gets you access to the user's microphone, and another for access to their GPS data. There's just a dialogue in between that the user can say "No" to; and, having said no, the content of the tab can't ask again, and just gets denied automatically. That's what makes it a sandbox.
I personally use several apps where I have granted one set of permissions and denied another (because it was for a feature I don't use). It has gotten a lot better than what it used to be.
It's like standard Linux permissions. If you install an app which creates its directories with mode 0777, or install a package which has a suid binary, you don't complain that Linux offers no file access control. That's the author's or packager's fault.
In a traditional app packaged as a deb/rpm the developer releases the source which then must be packaged and made to work with each distribution/platform. If the app is malicious or is sold to someone/compromised by someone who is then you are 100% hosed.
In a flatpak not designed to be properly sandboxed you are in fact no worse off than the alternative deb/rpm situation save that the issue of packing for distribution has been made easier.
It's in fact probably extremely challenging to package all sorts of applications without giving the user the option to provide an individual app elevated permissions.
At best we are relying on the user to decide which app ought to get those permissions.
If you think people can't be trusted to do this then the logical solution is to rely on packagers to decide what belongs in the official repo and keep malicious content out.
In the meantime – sure, package the app, but it shouldn’t show up as “sandboxed” in the GUI if the sandbox isn’t meaningful. Instead it should come with a nice scary warning that the app has access to all of your files… you know, for everyone to ignore and click through. (You can lead a horse to water…)
There's nothing about the idea of a sandbox that requires a specific approach.
A sandbox is an environment where capabilities can be restricted in a set of ways.
The javascript sandbox lets you manipulate the website and make network requests, but not access arbitrary files.
The flatpak sandbox is configured per-app and can prevent all fs access, all file io (with seccomp), all networking, etc.
The article is simply pointing out that most popular applications do not use the sandbox features well.
That doesn't mean flatpak does not have the sandbox they claim to, merely that it does not mesh well with many popular apps currently.
I still see nothing that merits the word "lie".
