4 ms·

> think of the elderly 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

> think of the elderly 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.

josephg 1y ago
> It's for you as well. You think they're going to stop? 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) Good: redisConnCap = systemCap.narrow(TCPConnect, "127.0.0.1", 6379) redisClient.connect(redisConnCap) This way, the redis library can only make outgoing connections on the specified TCP port. Everything else - including the filesystem - is off limits to this library. 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.
- extraisland 1y ago
  > 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. 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).
  - josephg 1y ago
    > 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. 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!)
    - 1y ago

josephg 1y ago

> It's for you as well. You think they're going to stop? 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) Good: redisConnCap = systemCap.narrow(TCPConnect, "127.0.0.1", 6379) redisClient.connect(redisConnCap) This way, the redis library can only make outgoing connections on the specified TCP port. Everything else - including the filesystem - is off limits to this library. 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.

extraisland 1y ago
> 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. 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).
- josephg 1y ago
  > 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. 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!)
  - 1y ago