Look at how the Web standbox is designed: of course some websites must access to your camera (Zoom, Jitsi, MS Teams, etc.) yet you still have to give them the permission! And it's a fine-grained permission (don't want to share your microphone, Ok just don't).

I want to be able to give programs exactly access to I want it to access, and just when I want to give it that access. This way I'm sure my SSH keys (or private emails,or bitcoin wallet, etc) will never be leaked by a malicious VSCode extension.

You can control the permissions with flatpak, it just doesn't ask you about each one by default.

But if that's what you're asking for it isn't a major change. It could even be done by using a simple shell script for installation.

On-installation is hugely different from on-use.

That's what portals are for.

So portals are not a major change?

Portals are a core part of flatpak's design.

Not of individual applications which (commonly) need adapting to make use of them.

But the web sandbox is terrible and an exercise in frustration when compared to using desktop apps ?

The web sandbox is an absolute delight for users. That users can run javascript code from malicious advertising companies without ill effect is a technological marvel. Consider all the shady nonsense advertising companies do today anyway - and imagine if they had full access to your filesystem when they do it! What a horrifying hellscape that would be.

"Oh, opened our website did you? Don't mind us - we'll just go ahead and install our own 'value add' daemons on your computer that show ads, and exfiltrate your data to improve ad targetting. You can trust us!"

It must not be all or nothing. In firewalls we have rules. In SELinux etc we have rules, and distros package them for you.

What kind of rule are you talking about? Flatpak is pretty flexible.

I'd be fairly happy for an IDE to stick to the /dev folder where I have that kind of stuff.

Yeah, my development practice also principally centers around having clang repeatedly compile /dev/urandom until it produces a program that does what I wanted.

My colleagues sometimes complain that it takes somewhat longer to do it this way than the old-fashioned “writing the code yourself” way, but on the plus side I don’t have to actually be present at all while it’s doing it. Just have it send you an email once the unit tests all pass and you’re good! This development approach has given me a bunch more time to train my monkeys to type Shakespeare. They’re getting pretty good at MacBeth, and I’m hoping to move on to Othello next week.

A friend of mine questioned why I involve ‘clang’ in the process at all; why not just echo /dev/urandom into a file, set it as executable, and then run it, instead of mucking around with the whole “compiling it with clang” step, but I pointed out, you know, at that point is it even really programming any more?

While I'd like for more portal-based file access integrated in applications, with flatseal you can pretty easily adjust what folders/files a certain flatplak application can access. E.g. I can limit firefox to only the ~/Download & ~/.mozilla directories, instead of the whole of ~. It also allows for configuring stuff like X11, wayland, network, printing and more.

There's obviously much more to do, but it already prevents many things like a pdf.js exploit being able to copy my ~/.ssh, without having to resort to some really clunky solution like a VM.

> Some programs aren't going to be very useful if you don't let them access resources on your computer, like the filesystem.

The overwhelmingly vast majority of them would do just fine without having access to my entire home directory.