Everything in that reference basically says "yep the criticism is valid" and in a few cases the author expands on that with "but it's ok because..." and then lists various reasons why it's fine that it's still a problem but that's it's being worked on. They also had to correct a good chunk of just outright incorrect information they were supplying mid-post about system updates.
One item was addressed, which was that flatpak now notifies the user that sandbox escapes are possible based on the app's configuration.
As a response to the criticisms, it's not a great one.
Consider also, there are better ways that some of these issues could have been tackled. Why not have flatpak prompt for permissions as they're used, e.g.: "This app wants to open your home directory" rather than at install-time. That would make it abundantly clearer to the end users this is aimed at.
> Why not have flatpak prompt for permissions as they're used, e.g.: "This app wants to open your home directory" rather than at install-time. That would make it abundantly clearer to the end users this is aimed at.
I'm going out on a limb and guessing that it is because that's what is done in mobile, and it's usage in mobile has re-taught everyone the lesson that constant dialog prompts just train users to click through dialog prompts without reading them. That's bad, and annoying.
I do still think there are better solutions to that problem, but it would require more effort from users to get applications working if they weren't designed with sandboxing in mind, which is the vast majority of applications, which in turn means that Flatpak probably wouldn't have grown as quickly.
While that's true, at least some users are protected. I've never really bought into that particular criticism of mobile. Users are going to click through regardless until they've been burned a bunch of times. The users who pay attention to those prompts are the ones you want to benefit, and hopefully eventually those other users will be trained into the safer behaviour. (Yeah I hear myself)
As it stands though, flatpak out of the box has all the security issues of running old unpatched systems in order to mostly have compatible runtime environments, which, in my experience, don't actually buy me that much. The few times my distro hasn't already shipped a copy of an application, AppImage, Flatpak, or Snap haven't had the solution either.
This entire experiment we're doing with "ship the developer's box" as the new standard of software delivery and the different warring philosophies employed to turn that into a reality are interesting. My money is on the least secure, least safe, least functional, but best marketed thing winning out.
On the other hand my family learned the opposite lesson (without assistance from me).
They essentially deny every such permission request and for the few they actually care about (getting notifications from 2 or 3 of the 50 apps that want notification access) they come and asked for assistance.
One of the nice things about the iOS ecosystem is that apps aren’t allowed to be nonfunctional if you deny them access to something.
Everything in that reference basically says "yep the criticism is valid" and in a few cases the author expands on that with "but it's ok because..." and then lists various reasons why it's fine that it's still a problem but that's it's being worked on. They also had to correct a good chunk of just outright incorrect information they were supplying mid-post about system updates.
One item was addressed, which was that flatpak now notifies the user that sandbox escapes are possible based on the app's configuration.
As a response to the criticisms, it's not a great one.
Consider also, there are better ways that some of these issues could have been tackled. Why not have flatpak prompt for permissions as they're used, e.g.: "This app wants to open your home directory" rather than at install-time. That would make it abundantly clearer to the end users this is aimed at.