[josephg]

That claim is too generic to add anything to this discussion. Ok, everything has a trade off. Thanks for that fortune cookie wisdom. But we’re not discussing CS theory 101. In this case in particular, what is the cost exactly? Is it a cost worth paying?

[raxxorraxor]

The cost is that developing that simple script to execute something and accessing files will have to be constructed differently. It will be much more complex.

That or the OS settings for said script will need to be handled. That is time and money.

[josephg]

I've said this elsewhere in this thread - but I think it might be interesting to consider how capabilities could be used to write simple scripts without sacrificing simplicity.

For example, right now when you invoke a script - say "cat foo.js" - the arguments are passed as strings, parsed by the script and then the named files are opened via the filesystem. But this implicitly allows cat to open any file on your computer.

Instead, you could achieve something similar with capabilities. So, I assume the shell has full access to the filesystem. When you call "cat foo.js", the shell could open the file and pass the file handle itself to the "cat" program. This way, cat doesn't need to be given access to the filesystem. In fact, literally the only things it can do are read the contents of the file it was passed, and presumably output to stdout.

> It will be much more complex.

Is this more complex? In a sense, its exactly the same as what we're doing now. Just with a new kind of argument for resources. I'm sure some tasks would get more complex. But also, some tasks might get easier too. I think capability based computing is an interesting idea and I hope it gets explored more.

[alexvitkov]

> how capabilities could be used to write simple scripts without sacrificing simplicity.

I proposed a solution for that in my original comment - you should be able to trivially bypass the capability system if you trust what you're running ($ yolo my_script.sh).

The existance of such a "yolo" command implies you're running in a shell with the "full capabilities" of your user, and that by default that shell launches child processes only a subset of those. "yolo" would then have to be a shell builtin, that overrides this behavior and launches the child process with the same caps as the shell itself.

[extraisland]

> That claim is too generic to add anything to this discussion. Ok, everything has a trade off. Thanks for that fortune cookie wisdom.

It isn't fortune cookie wisdom and no it isn't "too generic". It is something that fundamentally wasn't understood by the person I was replying to from their comment. I also don't believe you really understand the concept either.

> But we’re not discussing CS theory 101.

No we are not. We are discussing concepts about security and time / money management.

> In this case in particular, what is the cost exactly? Is it a cost worth paying?

You just accused me of "fortune cookie wisdom" and "being too generic". While asking a question where the answer differs dependant on the person / organisation.

All security is predicated on what you are protected against. So it is unique to your needs. What realistically are your threats. This is known as threat modelling.

e.g. I have a old vehicle. The security on it is a joke. Without additional third party security products, you can literally steal it with a flat blade about two inches long and drive away. You don't even need to hot-wire it. Additionally it is highly desirable by thieves. I can only realistically as a individual without a garage to store it in overnight, protect it from an opportunist. So I have a pedal box, a steering wheel lock, and a secret key switch that turns off the ignition and only I know where it is in the cab. That is like stop an opportunist. However more determined individuals. It will be stolen. Therefore I keep it out of public view when parked overnight. BTW because of the security measures, it takes about a good few minutes to be able to drive anywhere.

Realistically. Operating system security is much better than than it was. It is at the point that many recent large scale hacks in the last few years were initiated via social engineering to bypass the OS security entirely. So I would say it is in the area of diminishing returns already. So the level of threats I face and most people face, it is already sufficient. The rest I can mitigate myself.

Just like my vehicle. If a determined individual wants to get into you computer they are going to do so.

[josephg]

Thanks for educating me there champ. I'm sure you're very smart. But I've been writing software for a few decades now. Longer than a lot of people on HN have been alive. There's a good chance the computer you're using right contains code I've written. Suffice it to say, I'm pretty familiar with the idea of engineering tradeoffs. I suspect many other people in this thread are familiar with it too.

You missed the point the person you were replying to upthread was making. You're technically right - there is always some tradeoff when it comes to engineering choices. But there's a pernicious idea that comes along for the ride when you think too much about "engineering tradeoffs". The idea is that all software exists on some paraeto frontier, where there's no such thing as "better choices", there's only "different choices with different tradeoffs".

This idea is wrong.

The point made upthread was that often the cost of some choice is so negligible that its hardly worth considering. For example, if you refactor a long function by splitting it into two separate functions, this will usually result in more work for the compiler to do. This is an engineering tradeoff - we get more readability in exchange for slower compile times. But the compilation speed difference is usually so miniscule that we don't even talk about it.

"Everything comes with tradeoffs" is technically true if you look hard enough. But "No, not everything is a trade-off. Some things are just good and some are just bad" is also a good point. Some things are better or worse for almost everyone. Writing a huge piece of software using raw assembly? Probably a bad idea. Adding a thorough test suite to a mission-critical piece of software? Probably a good idea. Operating systems? Version control? Yeah those are kinda great. All these things come with tradeoffs. But the juice can still be worth the squeeze.

My larger point in this thread is that perhaps there are ways we can improve security that don't make computing measurably worse in other ways. You might not be clever enough to think of any of them, but that isn't proof that improvements aren't possible. I wasn't smart enough to invent typescript or rust 20 years ago. But I write better software today thanks to their existence.

I would be very sad if, in another 30 years, we're still programming using the same mishmash of tools we're using today. Will there be tradeoffs involved? Yes, for sure. But no matter, the status quo can still be improved.

> Realistically. Operating system security is much better than than it was. [...] So I would say it is in the area of diminishing returns already. So the level of threats I face and most people face, it is already sufficient.

What threat models are you considering? Computers might be secure enough for you, but they are nowhere near secure enough for me. I also don't consider them secure enough for my parents. I won't go into detail of some of the scams people have tried to pull on my parents - but better computer systems could easily have done a better job protecting them from some of this stuff.

If you use programming languages with a lot of dependencies, how do you protect yourself and your work against supply chain attacks? Do you personally audit all the code you pull into a project? Do you continue doing that when those dependencies are updated? Or do you trust someone to do that for you? (Who?). This is the threat model that keeps me up at night. All the tools I have to defend against this threat feel inadequate.