[linmob]

Confirming these settings at first launch is something that mostly annoys users. Remember: Most users just install software via Flatpak because this way they don't have to compile it themselves, deal with a tarball or use an outdated release their distribution ships.

Also, if you want to review or change these settings, you can use Flatseal[0]. Arguably, it should be installed by default.

The problem with flatkill.org is that it leads to users rather downloading a random deb off the internet or an AppImage than using Flatpak, which both have worse security stories.

[0] https://github.com/tchx84/Flatseal

[bayindirh]

If macOS, iOS and Android can get away with one-time permission pop-ups when access is first needed, I'm sure the same model can be applied to Linux.

The annoyance doesn't come from the security, it's from un-refined UX.

[Wowfunhappy]

As it happens, macOS didn’t get away with it for me. It’s the single largest reason I’m moving away from the platform.

On iOS the system works because of the type of tasks I do (and do not) perform on a phone. But when I start an automated Applescript and it pauses partway through with a permissions prompt, that’s a problem.

[loloquwowndueo]

Escaping from annoying micromanagement pop-ups is a big part of why I use Linux. If this changes and it becomes as naggy as Windows I might have to move to Openbsd :)

[cycloptic]

From that perspective, moving to OpenBSD seems mostly pointless as currently the best practice there if file permissions are too strict seems to be "comment out some unveil lines and recompile the program." Not really an improvement IMO.

From that angle if the permission dialogs bothered you then you could just recompile flatpak to unconditionally approve all dialogs. (Maybe there is even a setting for this already?) Of course as a sibling comment has said, this would be pretty dangerous, almost equivalent to using windows without UAC, or sudo with NOPASSWD.

[bayindirh]

I personally think being able to know what my applications are doing and being able to micromanage software permissions if I need to is beneficial.

In 2021, UNIXen are not as isolated as before. A lot of closed source software is creeping into the ecosystem. I'm not against that, but being able to limit them to sandboxes is a good thing IMHO.

I run VMs for such software, but a lighter weight solution is may prove more useful for some scenarios.

[GordonS]

To he fair to Windows, if you really want to, you can disable UAC prompts. Obviously that's generally a very bad idea, but it can be done.

[Daho0n]

Flatpak != linux. Different conversation.

[loloquwowndueo]

You apparently didn’t read the parent: “ I'm sure the same model can be applied to Linux.” I was replying to that, so perhaps your reply belongs one level up. I read the parent as “all next-gen packaging formats should adopt this pattern” and envisioned a hell where said packages are the only way to get new software, if any of them gains enough traction. I already know of a few packages I depend on which are only officially packaged as snaps - I’ve had to find alternatives or look into compiling from source (not always feasible - I don’t have a ton of time to tinker anymore).

[bayindirh]

> I read the parent as “all next-gen packaging formats should adopt this pattern” and envisioned a hell where said packages are the only way to get new software, if any of them gains enough traction.

Parent here. Whoa, you're reading too deep into that. How do you think that I envision such a future? Even I didn't know I've envisioned such a future.

If I had time to implement such an elaborate subsystem, I'd do it as a user-configurable kernel level interface. Like a more user-configurable, more flexible version of SELinux or AppArmor.

The first thing I'd implement would be a global on/off switch, too. I've seen and worked in enough projects where keeping it on was the only sensible choice, and I know enough that some people (incl. me in some scenarios) would like to keep it turned off.

For clarity, I neither support snaps, commercialization of Linux distributions to create commercial lock-ins, centralizing packages like Snap and dumbing down Linux. I already don't touch Chrome, Electron, VSCode and other pseudo opensource and pseudo free software and use some paid, cross-platform closed source software since they solve some real problems of mine, but I wouldn't dream of a Linux like you're creating by reading my simple comment.

Wow.

[gspr]

> or use an outdated release their distribution ships.

And a good chunk of those people often would be just fine with that "outdated" version.