[ric2b]

> Libraries should have major versions and the latest of each major version should be compatible with anything using that major version

Should, but accidental breaking changes are a thing. Plus flatpack more or less solves this by having standard runtimes (base collections of libraries/dependencies that flatpack apps target) that get security updates.

> That requires the person configuring the app's container to have both detailed knowledge of the app and detailed knowledge of the container system. It's common for this not to be the case.

With Snap, developers explicitly ask for the permissions they need and the approval process evaluates if it makes sense for that app to have those permissions (and by default or not).

[zrm]

> Should, but accidental breaking changes are a thing.

They're a thing either way. If a library has a security update that breaks your app, your choices are to have a security vulnerability or to have a broken app, until somebody fixes whatever is broken in either the library or the app. The only good option is to fix the breakage quickly -- or do better testing to begin with.

> Plus flatpack more or less solves this by having standard runtimes (base collections of libraries/dependencies that flatpack apps target) that get security updates.

At which point they might as well be their own packages so that you only have to install one copy of that version, since they're the same for every application anyway.

> With Snap, developers explicitly ask for the permissions they need and the approval process evaluates if it makes sense for that app to have those permissions (and by default or not).

This is not a solution to the hardness. If the developer doesn't understand the permissions model well enough to know to ask for a given permission they need, the app is broken. If they ask for permissions they don't need, either the approvers need to understand the app well enough to know it doesn't need that, or they approve permissions it doesn't need.

It doesn't get you out of needing somebody who understands both the app and the permissions model well enough to be able to correctly specify which permissions the app needs and doesn't.

[ric2b]

This permissions model and approval process already works in mobile app stores. Yeah, if the developer doesn't understand the permissions model they ship a broken app, so what? Are we supposed to expose our computers so that incompetent developers don't break their own apps accidentally?

[zrm]

> This permissions model and approval process already works in mobile app stores.

The permissions are too coarse-grained. Flashlight apps ask for ridiculous permissions and get them. Some permissions are "too dangerous" so you can't have them even if the user trusts you completely and you have a good reason, which makes certain apps impossible. It's rubbish.

> Yeah, if the developer doesn't understand the permissions model they ship a broken app, so what?

So then they err on the side of requesting too many permissions, which is made even worse when they're coarse-grained.

> Are we supposed to expose our computers so that incompetent developers don't break their own apps accidentally?

What Linux does, to start, is to not package things from incompetent developers. If your app is nothing but a fork of Thunderbird that uploads all the user's contacts to your server, Debian isn't going to package that because there's no demand for it. But you could get the equivalent thing into the app stores, because things get there when developers push them there, not when packagers pull them there.

Then the Linux apps have the source code for anybody to view and modify. If the app was originally written to do something problematic, you can modify the app not to do that before distributing it.

That makes the permissions model much less important, because the problem of malicious apps is much reduced and all you need it for is containing bugs.

Your app isn't supposed to access the network, so you assert as such. Then if it has a bug or somehow gets compromised, the system can at least prevent it from accessing the network.

But you don't have such an aggressive tension between false positives and false negatives because more of the false positives got eliminated through having access to the source code and not packaging garbage apps to begin with. If a Debian packager doesn't restrict the app from accessing the network even though it didn't really need to, probably doesn't matter anyway. If an app store does the same thing, that was the only thing preventing the app from sucking up all your contacts and sending them to a third party server.