←back to thread

2071 points K0nserv | 2 comments | | HN request time: 0.408s | source
Show context
zmmmmm ◴[] No.45088995[source]
> In this context this would mean having the ability and documentation to build or install alternative operating systems on this hardware

It doesn't work. Everything from banks to Netflix and others are slowly edging out anything where they can't fully verify the chain of control to an entity they can have a legal or contractual relationship with. To be clear, this is fundamental, not incidental. You can't run your own operating system because it's not in Netflix's financial interest for you to do so. Or your banks, or your government. They all benefit from you not having control, so you can't.

This is why it's so important to defend the real principles here not just the technical artefacts of them. Netflix shouldn't be able to insist on a particular type of DRM for me to receive their service. Governments shouldn't be able to prevent me from end to end encrypting things. I should be able to opt into all this if I want more security, but it can't be mandatory. However all of these things are not technical, they are principles and rights that we have to argue for.

replies(38): >>45089166 #>>45089202 #>>45089284 #>>45089333 #>>45089427 #>>45089429 #>>45089435 #>>45089489 #>>45089510 #>>45089540 #>>45089671 #>>45089713 #>>45089774 #>>45089807 #>>45089822 #>>45089863 #>>45089898 #>>45089923 #>>45089969 #>>45090089 #>>45090324 #>>45090433 #>>45090512 #>>45090536 #>>45090578 #>>45090671 #>>45090714 #>>45090902 #>>45090919 #>>45091186 #>>45091432 #>>45091515 #>>45091629 #>>45091710 #>>45092238 #>>45092325 #>>45092412 #>>45092773 #
josephg ◴[] No.45089489[source]
My parents are getting old and they aren't tech savvy. The missing piece here is that I want my parents to have a computer they can safely do their banking on, without leaving them vulnerable to scams and viruses and the like. I like that they have iphones. Doing internet banking on their phone is safer than doing it on their desktop computer. Why is that?

The reason is that the desktop PC security model is deeply flawed. In modern desktop operating systems, we protect user A from user B. But any program running on my computer is - for some reason - completely trusted with my data. Any program I run is allowed to silently edit, delete or steal anything I own. Unless you install special software, you can't even tell if any of this is happening. This makes every transitive dependency of every program on your computer a potential attack vector.

I want computers to be hackable. But I don't also want my computer to be able to be hacked so easily. Right now, I have to choose between doing banking on my (maybe - hopefully - safe) computer. Or doing banking on my definitely safe iphone. What a horrible choice.

Personally I think we need to start making computers that provide the best of both worlds. I want much more control over what code can do on my computer. I also want programs to be able to run in a safe, sandboxed way. But I should be the one in charge of that sandbox. Not Google. Definitely not Apple. But there's currently no desktop environment that provides that ability.

I think the argument against locked down computers (like iphones and androids) would be a lot stronger if linux & friends provided a real alternative that was both safe and secure. If big companies are the only ones which provide a safe computing experience, we're asking for trouble.

replies(21): >>45089546 #>>45089576 #>>45089598 #>>45089602 #>>45089643 #>>45089690 #>>45089745 #>>45089884 #>>45090077 #>>45090112 #>>45090128 #>>45090605 #>>45090660 #>>45091074 #>>45091275 #>>45091454 #>>45091793 #>>45092007 #>>45092495 #>>45092746 #>>45114735 #
extraisland ◴[] No.45089602[source]
Everything in life is about trade-offs. Certain trade-offs people aren't going to make.

- If you want to run an alternative operating system, you got to learn how it works. That is a trade off not even many tech savvy people want to make.

- There is a trade-off with a desktop OS. I actually like the fact that it isn't super sand-boxed and locked down. I am willing to trade security & safety for control.

> Personally I think we need to start making computers that provide the best of both worlds. I want much more control over what code can do on my computer. I also want programs to be able to run in a safe, sandboxed way. But I should be the one in charge of that sandbox. Not Google. Definitely not Apple. But there's currently no desktop environment that provides that ability.

The market and demand for that is low.

BTW. This does exist with Qubes OS already. However there are a bunch of trade-offs that most people are unlikely to want to make.

https://www.qubes-os.org/

replies(5): >>45089940 #>>45090318 #>>45090562 #>>45090759 #>>45091309 #
alexvitkov ◴[] No.45090759[source]
No, not everything is a trade-off. Some things are just good and some are just bad.

A working permission system would be objectively good. By that I mean one where a program called "image-editor" can only access "~/.config/image-editor", and files that you "File > Open". And if you want to bypass that and give it full permissions, it can be as simple as `$ yolo image-editor` or `# echo /usr/bin/image-editor >> /etc/yololist`.

A permission system that protects /usr/bin and /root, while /home/alex, where all my stuff is is a free-for-all, is bad. I know about chroot and Linux namespaces, and SELinux, and QEMU. None of these are an acceptable way to to day-to-day computing, if you actually want to get work done.

replies(2): >>45090992 #>>45091274 #
extraisland ◴[] No.45091274[source]
No everything is a trade off. That is a reality of life in general.

Anything that is proposed has a cost associated with it (time, money). That always has to be weighed up against any potential benefit.

replies(1): >>45092239 #
josephg ◴[] No.45092239[source]
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?
replies(2): >>45092511 #>>45092659 #
raxxorraxor ◴[] No.45092511[source]
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.

replies(1): >>45099588 #
1. josephg ◴[] No.45099588[source]
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.

replies(1): >>45101997 #
2. alexvitkov ◴[] No.45101997[source]
> 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.