> I've just explained that sand-boxing causes issues with file access, clipboard sharing etc.
You've explained that flatpak has issues with file access and clipboard sharing. My iphone does sandboxing too, but the clipboard works just fine on my phone.
I don't think "failing clipboards" is a problem specific to sandboxing. I think its a problem specific to flatpak. (And maybe X11 and so on.)
> If you remove control, you remove people's freedom.
Sandboxing gives users more control. Not less. Even if they use that control to turn off sandboxing, they still have more freedom because they get to decide if sandboxing is enabled or disabled.
Maybe you're trying to say that security often comes with the tradeoff of accessibility? I think thats true! Security often makes things less convenient - for example, password prompts, confirmation dialogue boxes, and so on. But I think the sweet spot for inconvenience is somewhere around the iphone. On the desktop, I want to get asked the first time a program tries to mess with the data of another program. Most programs shouldn't be allowed to do that by default.
> Pretending you can make some theoretical system where those trade off don't exists just isn't realistic.
I think you might be arguing with a strawman. I totally agree with you. I don't think a perfect system exists either. Of course there are tradeoffs - especially at the limit.
But there's still often ways to make things better than they are today. For example, before rust existed, lots of people said you had to make a tradeoff between memory safety and performance. Well, rust showed that by making a really complex language & compiler, you could have memory safety and great performance at the same time. SeL4 shows you can have a high performance microkernel based OS. V8 shows you can have decent performance in a dynamically typed language like JS.
Those are the improvements I'm interested in. Give me capabilities and sandboxing. A lot more security in exchange for maybe a little inconvenience? I'd take that deal.
> You've explained that flatpak has issues with file access and clipboard sharing. My iphone does sandboxing too, but the clipboard works just fine on my phone.
> I don't think "failing clipboards" is a problem specific to sandboxing. I think its a problem specific to flatpak. (And maybe X11 and so on.)
There are other examples.
e.g. There are other things that become a PITA on the phone. Want to share pictures between apps without them having full access to the everything. You need to manually share each picture between apps.
The point being made is that it causes usability issues. What those usability issues are will vary depending on platform. However they will exist.
> Sandboxing gives users more control. Not less. Even if they use that control to turn off sandboxing, they still have more freedom because they get to decide if sandboxing is enabled or disabled.
Anything that gets in my way is something that taken control away from me. Unfortunately giving me full control comes with dangers. That is a trade off.
> Maybe you're trying to say that security often comes with the tradeoff of accessibility? I think thats true! Security often makes things less convenient - for example, password prompts, confirmation dialogue boxes, and so on. But I think the sweet spot for inconvenience is somewhere around the iphone.
No usability and control.
BTW, Your sweet spot is a platform which is the most locked down.
> On the desktop, I want to get asked the first time a program tries to mess with the data of another program. Most programs shouldn't be allowed to do that by default.
Well I don't want to be asked. I find it annoying. I assume that this is the case when I install the program. So I don't install software in the first place that I think might be risky. If I need to install something that I might think is iffy then I find a way to mitigate it.
> But there's still often ways to make things better than they are today. For example, before rust existed, lots of people said you had to make a tradeoff between memory safety and performance. Well, rust showed that by making a really complex language & compiler, you could have memory safety and great performance at the same time.
You aren't selling it to me. I got so annoyed by Rust that I didn't complete the tutorial book. Other than the strange decisions. One thing I hate doing is fighting with the compiler. That has a cost associated with it.
I spend a lot of time fighting with the TypeScript compiler (JS ecosystem is a mess) as a result to have some things work with TypeScript you need to faff with tsconfig and transpilers. Then once you are past that you have to keep the compiler happy. Frequently you are forced to write stupid code to keep the compiler happy. That again has a *cost*.
> V8 shows you can have decent performance in a dynamically typed language like JS.
I work with JavaScript a lot. While performance is better, it isn't actually that good.
There was also two secondary effects.
- Websites ballooned up in size. Also application development moved to the browser. This meant you can lock people in your SaaS offering. Which reduces control/freedom.
- There is a lot of software that is now written in JavaScript that really shouldn't be. Discord / Slack are two of the slowest and memory hogging programs on my computer. Both using Electron.
> Those are the improvements I'm interested in. Give me capabilities and sandboxing. A lot more security in exchange for maybe a little inconvenience? I'd take that deal.
Again. It is a trade-off that you are willing to take. I am willing to make the opposite trade-off.