We should have the ability to run any code we want on hardware we own

This stuff is not just for the elderly and computer illiterate. It's for you as well. You think they're going to stop?

You're giving up freedom for safety. You will have neither.

No! Which is why I don't want every npm package I install to have unfettered access to my internet connection and to access all my files. If this is being exploited now, I might not even know! How sloppy is that!

> You're giving up freedom for safety.

At the limit, sure, maybe there are tradeoffs between freedom and security. But there's lots of technical solutions that we could build right now that give a lot more safety without losing any freedom at all.

Like sandboxing applications by default. Applications should by default run on my computer with the same permissions as a browser tab. Occasionally applications need more access than that. But that should require explicit privilege escalation rather than being granted to all programs by default. (Why do I need to trust that spotify and davinci resolve won't install keyloggers on my computer? Our computers are so insecure!)

Personally I'd like to see all access to the OS happen through a capability model. This would require changes in the OS and in programming languages. But the upside is it would mean we could fearlessly install software. And if you do it right, even `npm install` could be entirely safe. Here's how we do it: First, all syscalls need to pass unforgable capability tokens. (Eg SeL4). No more "stringy" syscalls. For safe 3rd party dependencies, inside processes we first make an "application capability" that is passed to main(). 3rd party libraries don't get access to any OS objects at all by default. But - if you want to use a 3rd party library to do something (like talk to redis), your program crafts a capability token with access to that specific thing and then passes it to the library as an argument.

Bad:

    // Stringy API. Redis client can do anything.
    redisClient.connect("127.0.0.1", 6379)

    redisConnCap = systemCap.narrow(TCPConnect, "127.0.0.1", 6379)
    redisClient.connect(redisConnCap)

This would require some PL level changes too. Like, it wouldn't be secure if libraries can access arbitrary memory within your process. In a language like rust we'd need to limit unsafe code. (And maybe other stuff?). In GC languages like C# and javascript its easier - though we might need to tweak the standard libraries. And ban (or sandbox) native modules like napi and cgo.

Everything you have suggested in this post takes away freedom. There is no solution that doesn't take away freedom / your control. There is always a trade off.

> Like sandboxing applications by default. Applications should by default run on my computer with the same permissions as a browser tab. Occasionally applications need more access than that. But that should require explicit privilege escalation rather than being granted to all programs by default. (Why do I need to trust that spotify and davinci resolve won't install keyloggers on my computer? Our computers are so insecure!)

This already exists on Linux.

I run Discord/Slack in Flatpak. Out of the box the folders and clipboard permissions are restricted. Only the ~/Downloads folder on my PC is accessible to Discord/Slack. You can't drag and drop things into these apps. Which makes sharing content a PITA.

If you don't want to worry about things like keyloggers, you should run an open source OS and use open source programs where you can verify that there are no key loggers. You should also make sure you find out what firmware your keyboard is using (many keyboards themselves have complex micro controllers on them that can be programmed).

Huh? In what way does application sandboxing take away my freedom? What can I do today that I can't do with a sandbox-everything-by-default model?

In my mind, it gives me (the user) more freedom because I can run any program I want without fear.

> I run Discord/Slack in Flatpak. Out of the box the folders and clipboard permissions are restricted. Only the ~/Downloads folder on my PC is accessible to Discord/Slack. You can't drag and drop things into these apps. Which makes sharing content a PITA.

Cool! Yeah this is the sort of thing I want to see more of. The drag & drop problem is technically solvable - it just sounds like they haven't solved it yet. (Capabilities would be a great solution for this.. just sayin!)

I've just explained that sand-boxing causes issues with file access, clipboard sharing etc.

Every hoop you add in makes it more difficult for the user to gain back control, even if that is modifying permissions yourself. Most people will just remove permissions out of annoyance.

If you remove control, you remove people's freedom.

> In my mind, it gives me (the user) more freedom because I can run any program I want without fear.

Any security mechanism has a weakness or it will be bypassed by other means. So all this will give you a false sense of security.

The moment you think you are safe. Is when you are most unsafe.

> Cool! Yeah this is the sort of thing I want to see more of. The drag & drop problem is technically solvable - it just sounds like they haven't solved it yet. (Capabilities would be a great solution for this.. just sayin!)

I don't. It is a PITA. Eventually people just turn it off. I did.

The reality is that if you want ultimate security you have to make a trade offs. Pretending you can make some theoretical system where those trade off don't exists just isn't realistic.

Your argument would suggest that virtual memory takes away user freedom, because it's now much harder to access hardware or share data between programs, but that sounds ridiculous from a modern perspective. I think it's better to keep freedom and complexity separate, and speak about loss of freedom only when something becomes practically impossible, not just a bit more complex.

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.

No I am not arguing that at all.

Think user accounts but for task classes.

If I'm doing development work, I want to be able to chain together a Frankenstein of apps, toolchain, API services and so on, with full access to everything else in that specific context.

But that doesn't need visibility of my email, my banking and accounting software should have visibility to/from neither, and random shareware apps, games and movies should run, like you say, with a browser tab level of permission.

Making this work in practice while keeping performance maximised is harder than it sounds, preventing leaks via buffers or timing attacks of one sort or another (if apps can take screenshots, game over).. for now I use user accounts, but this is becoming less convenient as the major desktop OS and browser vendors try to force tying user accounts to a specific online identity.

> 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.

I think you could do this with capabilities!

The current model makes of security implicit, where an application can make any syscall it wants and its up to the OS to (somehow) figure out if the request is valid or not. Capabilities - on the other hand - restrict access of a resource to the bearer of a certain token. The OS knows that by invoking capability X, the bearer can make requests to a certain resource / account / file / whatever. (Think of it like unix file descriptors. You just call write(1, ...) and the OS knows what file you're writing to, and what your access to that file is.)

There's lots of ways to use capabilities to build the sort of frankenstein app you're talking about using caps. Eg, you could have a supervisor task (maybe the desktop or a script or something) that has a capability for everything the user cares about. It can create sub-capabilities which just have access to specific network ports / files / accounts / whatever. It launches subprocesses and hands the right capabilities to the right sub processes. The sub processes don't even need to know what the capability they were given connects to. They just need to know - for example - that reading from the capability gives it the data it expects to receive. Then you can do all the routing & configuration from the supervisor task.

Because all the sub processes only have the specific capabilities that were passed to them, the security surface area is automatically minimised.

SeL4 shows that you can do this without losing much performance. (In SeL4, the IPC overhead is tiny.) But as I said upthread, I'm sure there's also ways to design our programming languages to allow within-process isolation. So, for example, you can call the leftpad package without giving it capabilities held by other parts of the same program.

Capabilities can also make it easy to virtualise filesystems, the network, and so on. Or to do interdiction - and snoop on the messages being sent. Its easy because you can just make virtual network / filesystem / whatever capabilities and pass those to subprocesses.

> 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.

There is a big difference between basic memory protections and what was being discussed.

This is the issue with a lot of people that work in software. They take the most ridiculous interpretation because "that is technically" correct while not bothering to try to understand what was said.

Virtual memory probably isn't what you meant, but take something like user privilege separation. It's usually considered a good idea to not run software as root. To interpret the statement generously, privilege separation does restrict immediate freedom: you have to escalate whenever you want to do system-level changes. But I think josephg's statement:

> 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.

can be directly transposed to user privilege separation. While it's true that escalating to root is more of a hassle than just running everything as root, in another sense it does provide more control because the user can run arbitrary code without being afraid that it will nuke their OS; and more freedom because you could always just run everything as root anyway.

Maybe josephg's sense of freedom and control is what you're saying there is a trade-off between. But the case of privilege separation shows that some trade-offs are such that they provide a lot of security for only a little bit of inconvenience, and that's a trade-off most people are willing to make.

Sometimes the trade-off may seem unacceptable because OS or software support isn't there yet. Like Vista's constant UAC annoyances in the case of privilege separation/escalation. But that doesn't mean that the fundamental idea of privilege levels is bad or that it must necessarily trade off too much convenience for control.

I think that's also what josephg is suggesting about sandboxing. He says that the clipboard problem could probably be fixed; then you say, "but there are other examples". What remains to be shown is whether the examples are inherent to sandboxing and must degrade a capabilities/sandbox approach to a level where the trade-off is unacceptable to most.

It really wasn't. It isn't hard to understand what was meant.

> Virtual memory probably isn't what you meant,

No it wasn't and there is no need to put "probably". It was obvious it wasn't.

> can be directly transposed to user privilege separation. While it's true that escalating to root is more of a hassle than just running everything as root, in another sense it does provide more control because the user can run arbitrary code without being afraid that it will nuke their OS; and more freedom because you could always just run everything as root anyway.

The difference is that there are very few things I need to run as user directly daily as root on my Desktop Linux box. I can't think of anything.

However having to cut and paste a meme into ~/Downloads so I can share it on Discord or Slack is a constant PITA. If you sandbox apps you have to restrict what they can access. There is no way around this. The iPhone works the same way BTW. I know I used to own one. You either have to say "Discord can have access to this file", or you have to give it all the access.

> Maybe josephg's sense of freedom and control is what you're saying there is a trade-off between. But the case of privilege separation shows that some trade-offs are such that they provide a lot of security for only a little bit of inconvenience, and that's a trade-off most people are willing to make.

No they are a false sense of security with a lot of inconvenience. The inconvenience is inherent and always will be because you will need to restrict resources using a bunch of rules.

> Sometimes the trade-off may seem unacceptable because OS or software support isn't there yet. Like Vista's constant UAC annoyances in the case of privilege separation/escalation. But that doesn't mean that the fundamental idea of privilege levels is bad or that it must necessarily trade off too much convenience for control.

There are many things that seem like they are fundamentally sound ideas on the face of it. However there are always secondary effects that happen. e.g. Often people just ignore the prompts, this is called "prompt fatigue". I've literally seen people do it on streams.

Operating systems are now quite a lot more secure than they were. So instead of going for the OS, most bad actors will use a combination of social engineering to gain initial entry to the system. The OS security often isn't the problem. Most operating systems have either app stores, some active threat management.

If you are running things from npm/PyPI/github without doing some due diligence, that is on you. This is well past what non-savvy user is likely to do.

> I think that's also what josephg is suggesting about sandboxing. He says that the clipboard problem could probably be fixed; then you say, "but there are other examples". What remains to be shown is whether the examples are inherent to sandboxing and must degrade a capabilities/sandbox approach to a level where the trade-off is unacceptable to most.

It is inherent. It obvious it is. If you want to share stuff between applications like data, which is something you want to do almost all the time. You will need to give it access at least to your file-system. The more of this you do, you will either have to give more access or having to faff moving stuff around. So either you work with a frustrating system (like I have to do at work), or you disable it.

So what happens is you only have "all or nothing".

At least two independent people understood you in the same way. So just dismissing it isn't productive.

> PITA. If you sandbox apps you have to restrict what they can access. There is no way around this.

This has nothing to do with freedom though.

> You will need to give it access at least to your file-system.

On Qubes, you copy-paste with ctrl+shift+v/c and nothing is shared unless you actively do it yourself. It becomes a habit very quickly (my daily driver). Sharing files is a bit harder (you send them from VM to VM), but it's not as hard as you want it to look.

> The moment you think you are safe. Is when you are most unsafe.

This is demonstrably false. Qubes OS has the lowest number of CVEs, even less than that of Xen. Last VM escape in it was found in 2006 by the Qubes founder (it's called "Blue Pill").

Also: https://news.ycombinator.com/item?id=27897975

Two people that we are aware of.

BTW, I often encounter this when talking to other techies. People go to the most ridiculous extremes to be contrarian. Often they don't even know they are doing. I know because I used to engage in this behaviour.

So I feel like I am well withing my rights to dismiss it.

There is nothing and I mean nothing that is completely secure.

You're not wrong, but dismissing security because there are always other threats is just security nihilism. See my link.

Why round trip it through the file system or Files.app? That seems like extra (annoying) work On my iPhone, I copy the meme onto the clipboard and then I open discord/slack/signal/Whatsapp and find the right channel/chat, and paste right in there.

Why are those the only answers?

If we had free rein to redesign our computers from the ground up, there’s lots of other ways that problem could be solved.

One obvious example is to make copy+paste be an OS level shortcut so apps can’t access the clipboard without the user invoking that chord. Then just copy paste stuff between applications.

Another idea: right now when I invoke a shell script, I say “foo blah.txt”. The argument is passed as a string and I have to trust that the program will open the file I asked - and not look instead at my ssh private keys. Instead of that, my shell program could have access to the filesystem and open the file on behalf of the script. Then the script can be invoked and passed the file descriptor as input. That way, the script doesn’t need access to the rest of my filesystem.

If we’re a little bit creative, there’s probably all sorts of ways to solve these problems. The biggest problem in my mind is that Unix has ossified. It seems that nobody can be bothered making desktop Linux more secure. A pity.

Maybe it’s time to give qubes a try.

Computers are subversive. They have the power to not only wipe out entire sectors of the economy but also defeat governments and militaries. If you let people run software freely, they can give themselves the power to do things like block ads and copy artificially scarce data at zero cost, directly impacting the bottom line of corporations. And that's when they don't run cryptography, cryptocurrency and anonymization software to escape government control.

So these businesses and governments have every reason in the world to usurp control of your computer. They want computers to only run software that's been authorized by them, so that you can do nothing that harms their interests.

It's not your computer, it's theirs, they're just letting you use it, and only if you follow company and government policy. And it's not at all about your security against external attackers in general, it's about their security against you.

It's got nothing at all to do with "capabilities". It's got everything to do with putting you in digital shackles so that you are forced to live in a dystopian cyberpunk technofeudalist digital fiefdom as a serf who pays and consumes in perpetuity.