[dpwm]

> I just wonder why the author of this page does not disclose his name...

> And even hides this from the whois info.

The registrant country is listed as France and the registrar is OVH. They are simply adhering to the GDPR. I have domains that have been like this since May, even though I would be quite happy to have everything public.

> This could have been written by a person with a grudge for all I am concerned.

Your comment could have been written by somebody with a grudge against the person you are claiming could have had a grudge for all I am concerned. A vested interest can make a difference, but I don't really see how any of the points are hard to verify.

Does this being written by a person with a grudge really negate the points made?

- Flatpak is claiming to be secure

- Flatpak is sandboxing apps with full access to your home directory.

(What is the worst thing that an app can do? Nuke your home directory or run malicious software. The sandboxing here does little to mitigate this.)

- Apps are not being updated as quickly as their distribution repository counterparts.

- At some point in its past, a (presumably) privileged component with permissions to setuid did not check that it wasn't blindly copying setuid.

It seems to me that this is more about easy delivery of software with a security claim that is arguably pretty weak at the moment against likely attack vectors. I can't see that changing without first thinking of what you're actually sandboxing for.

There are already software delivery systems, such as 0install and appimage, that do not make claims about being sandboxed and yet provide a similar (or greater in the setuid case) level of security for the main threats.

I find it hard to understand who the project is for. If you're a developer on your own machine then using your distro's package manager is probably more secure. If you're a sysadmin, letting users use flatpak serves only to increase the attack surface for privilege escalation.

[toyg]

The problem is that distro package managers are many and often complex to satisfy, which is one of the reasons people don’t develop “real” desktop software for Linux.

The new generation of installers (flatpak, snap etc) takes a cross-distro approach that is supposed to result, more or less, in “package once, run everywhere”: you build your app in a certain way and every distro should be able to run it, regardless of package managers. It’s basically a way to offload the compatibility headaches to flatpak developers and distribution builders.

Obviously that approach works only if flatpak does actually get good support in all distributions and becomes a de-facto standard, which is a challenge because there are many competitors (Ubuntu Snap being the most relevant one). If it remains just a glorified rpm (i.e. a redhat-specific tool), then there is no point.

[dpwm]

> The problem is that distro package managers are many and often complex to satisfy, which is one of the reasons people don’t develop “real” desktop software for Linux.

If by real you mean the kind of proprietary {ad,spy,toolbar}-ware encrusted "real" desktop software that Windows has become notorious for then I think we may be better off without it. If you're talking about OSX, then I think you're missing that it's a market skewed towards those with the money and will to pay for proprietary software. Plenty of people are developing "real" desktop software for Linux.

> The new generation of installers (flatpak, snap etc) takes a cross-distro approach that is supposed to result, more or less, in “package once, run everywhere”: you build your app in a certain way and every distro should be able to run it, regardless of package managers. It’s basically a way to offload the compatibility headaches to flatpak developers and distribution builders.

This isn't novel. 0install and AppImage have been around for a while now. What is novel is that Flatpak combines this with sandboxing that doesn't really do so much to mitigate against any vulnerabilities that aren't in the kernel. I actually think they've got the sandboxing right, in that they are really starting with minimum privileges and adding only what is needed.[0] The problem, as they state, is that it is fine to drop all privileges for something like a single-player game, but it sucks for a file manager. At least according to their wiki, they're already doing most of what you could imagine you could improve on the sandboxing. [0]

It's always this interaction with the outside world that breaks sandboxing. It's rather easy to make a sandbox that runs as nobody and has no privileges and no capabilities and no file access. It's a bit harder to make something which has any of those things in a way which the user can grant sensible permissions.

It sounds like in Portals [1] the Flatpak team have gone in pretty much the only workable direction, although the Wiki is hopefully out of date and there are more portals. The problem they will have found is that to package anything useful and get feedback and validation requires that they implement the most difficult bits first. So I suspect the situation is "secure file picker is coming".

Sandboxing is a lot of work, not in the closing down but in the opening up. One of the more innovative approaches is to be found in Sandstorm [2]. Although marketed as a way to run web applications on your own server easily, it is actually a tight sandbox built on top of Cap'n Proto, which means that E-style capability-based RPC is intrinsic.

Sandboxed apps have no access to anything, cutting down on kernel attack space. The only connection to the outside world is through a UNIX socket file descriptor opened by the supervisor. The capabilities-based security model mean that a sandboxed app could request the ability to connect to "drive.google.com", or even a specific URL. This could also be passed to other apps through the supervisor, subject to user approval. Capabilities can be stored on disk to be later restored from the supervisor.

In Sandstorm the UI for granting capabilities between apps is working, but progress has slowed as the team have all had to find other ways to pay the bills.

> Obviously that approach works only if flatpak does actually get good support in all distributions and becomes a de-facto standard, which is a challenge because there are many competitors (Ubuntu Snap being the most relevant one). If it remains just a glorified rpm (i.e. a redhat-specific tool), then there is no point.

I think the problem is that if your target is casual users, they're not going to necessarily understand the nuances and limitations of the sandboxing.

[0] https://github.com/flatpak/flatpak/wiki/Sandbox

[1] https://github.com/flatpak/flatpak/wiki/Portals

[2] https://sandstorm.io/how-it-works#capabilities

[TimJYoung]

"If by real you mean the kind of proprietary {ad,spy,toolbar}-ware encrusted "real" desktop software that Windows has become notorious for then I think we may be better off without it."

You're ignoring a huge amount of business software that is created for, and runs on, Windows. That's like judging Android or iOS based upon the consumer crapware that gets sold/given away in their app stores, as opposed to the many business apps that are used to automate and improve all sorts of tasks on mobile devices.

I keep seeing this pattern repeated over and over again: someone (this has been me, several times) mentions on HN that Linux needs a better way to allow for binaries to be dropped on a system and run without requiring re-compilation or overly-complicated containers/sandboxes, and the answers invariably end up being "don't want it, don't care". But, the reality is that there are a very large number of people that would jump to Linux in a heartbeat if they could target the OS for distribution in that fashion. It just seems like a bunch of ideology run amok with zero thought given to the actual needs of professional developers/companies. And, there's a lot of evidence that this is one of the primary things holding back Linux adoption on the desktop.

The rest of your reply was very informative, thanks.

[dpwm]

> You're ignoring a huge amount of business software that is created for, and runs on, Windows. That's like judging Android or iOS based upon the consumer crapware that gets sold/given away in their app stores, as opposed to the many business apps that are used to automate and improve all sorts of tasks on mobile devices.

Thanks for this. Indeed I was responding a bit flippantly to the whole "real" desktop software, as if there isn't any on Linux. I appreciate now it probably wasn't meant in that way, and so that aspect of my response was flippant and unhelpful.

Indeed, it seems for every example we find of serious expensive proprietary software that runs on Linux, there is another that doesn't.

We have Maya running on Linux, and Softimage. Both sold by Autodesk (albeit acquired). And yet other Autodesk products, like 3dsmax and Autocad, do not have Linux support. Asking about this on their forums appears to result in a rather curt response to read the system requirements where it says "Windows."

These are tools that people learn and take with them between jobs, and I can well imagine that these are people that could work on desktop Linux without too many problems as long as those tools moved with them. Replying "but blender can do that!" is completely ignoring the reality that people have invested significant time into these tools and know them well. Whilst blender is an amazing piece of free software, it's by no means an industry standard. In the way that Gimp is quite phenomenal, it seems many professionals find it lacks features that Photoshop has.

I don't think the "web browser" response cuts it in other areas either, even if a lot of the less technically demanding software is going cloud-based.

> It just seems like a bunch of ideology run amok with zero thought given to the actual needs of professional developers/companies. And, there's a lot of evidence that this is one of the primary things holding back Linux adoption on the desktop.

I think you're right, and I'm probably in that category. I've also seen what bad vendors can do to an ecosystem though. The windows ecosystem is still full of dodgy vendors.

I'm quite convinced that package-once-with-sandboxing will happen, and I will admit that Flatpak is probably in a prime position for that to happen. I think they've probably got the most correct direction of all the attempts in the space, it just doesn't seem to be there yet.

From a commercial vendor point of view, it's also not a problem if the user's home directory is bind mounted and over a year ago there was a bug with the sand-boxing that let malicious vendors install software that could run as root. Let's not forget that most Windows apps don't go anywhere near a sandbox in the first place and their installers need system-wide access. There's plenty of low-hanging fruit still in this space.

Things have definitely got better in recent years. One of the biggest things to improve this is that 32-bit x86 is dying off. There were a number of vendors that did the "we can just build 32-bit, like windows" without realising or caring about the horrors of multi-arch dependency hunting that they were inflicting on the sysadmin.

So thank you for your comment. It made me realise that I was probably being quite flippant about software which does fulfil a niche need and does it well, and that you only need one piece of such software to tie someone to an operating system they may otherwise have no affinity for.

[TimJYoung]

Thanks for the thoughtful comments, they are very much appreciated.

The thing that a lot of Linux developers don't seem to get about Windows is that its binary distribution model is an opportunity/productivity multiplier, and it all hinges on three major points:

1) Backward-compatibility is real, and, contrary to what most people say about MS/Windows, this is very pro-consumer. Just chucking code at people and saying "but, you can just re-compile it" ignores a lot of realities, including the fact that even developers don't want to be forced to recompile binaries that they are not, themselves, working on as their actual work.

2) You can deploy 32-bit binaries on 64-bit systems and they work just fine. It really made the switch to 64-bit versions of Windows a non-event, whereas this is another issue that developers need to worry about when targeting Linux. And, there are a lot of applications that simply don't benefit from being 64-bit because they don't need, or can't use, the increased address space, so forcing developers to specifically target 64-bit is just another unnecessary hurdle.

3) You can actually create binaries for Windows that don't require any dependencies other than what is available in the OS. This means that you can create binaries that work on tablets, laptops, desktops, and servers without recompilation. This also ties in to your comment about the installers, but the reality is that you really only need admin access for an installer to put things into the "Program Files" folder tree, or to install services. Apart from that, most professional software doesn't touch anything other than the user-specific folders (if Windows doesn't delete them first ;-) ).

I don't think that this point can be overstated: if you create a neutral OS platform where desktop developers can deploy their software with minimal fuss and no gatekeepers, you will win the desktop space, period. More than anything else, desktop developers want to make money, and an open OS that does its thing and stays out of the way is the ticket to that money. But, in order to do this, a lot of current Linux developers will need to get used to sharing Linux with commercial vendors and proprietary software, and I think that's still a hard sell. And, unfortunately, a large part of that mindset is wedded to this bizarre idea that desktop developers like Windows because of Windows. Desktop developers like Windows because a) that's where the users are, and b) they can make money without being forced or required to expose their source code. If the same can be done with Linux, then Linux will have no problem taking the OS space away from MS completely.

Linux is stuck in "server/appliance mode" right now, and it's a shame because if there was ever a time for Linux to take over the desktop, it's now. As you say, web applications are just not a suitable replacement for all desktop applications. MS keeps trying to lock down how development is done on Windows and, if they succeed, then everything that I stated above will go away and there will be a lot of developers looking for a new home. Any OS that starts out with "you can only use our development tools/languages, and no others", is going to whither away and die. It happened to Apple once, it appears to be happening to Apple again, and MS has apparently decided that it should emulate Apple. The whole reason why Windows became popular in the first place was because there were a ton of development tools/compilers/languages that could be used to produce binaries for Windows, and Windows gave zero preference to any of them. This was carried over from MS-DOS. And, none of this precluded any vendor from going ahead and providing/selling their source code along with the product. Linux developers have just got to let go of trying to control how people use the OS, and just try to make it as amenable to as many usage/deployment scenarios as possible.

[finchisko]

I like what Microsoft did in UWP. App is allowed to read own files, files explicitly selected by user from Open Dialog. For anything else app developer has to ask for permission and user has to approve it (like in iOS, Android....). Specially the second option is nice, because you as user have a choice to grant access only for specific files and dirs you want app to have the access.

[dpwm]

UWP sounds like it gets it right, but a lot depends on the granularity of the permissions. I'm not even sure you can win: too fine grained and the user ends up with permission fatigue and just clicks through, too coarse grained and the user has to choose between full access or no access. I think android gets this very wrong, but has improved somewhat.

I'm not sure if it's been tried but I think a better way might be to create some set of capabilities that can be applied, so you get complete confinement by default but can bulk set permissions of your choosing.

According to design docs, this is what is meant to happen with Flatpak. I'm not a user so I don't know how close it comes.

It appears that Flatpak falls short fo this with quite a few apps, which seems weird if they did implement the file portal they spoke of.

[gbraad]

Flatpak does not claim to be secure. This is also clearly stated in the FAQ. They provide a means of separation of applications. Sandboxing is not per se a form of security, just like this was with Docker in the 'early days'.