> The meme is still alive that windows accumulates garbage and becomes slower with time, so you need to reinstall it periodically.
I've not needed to worry about this since Windows XP. Which was what? 25 years ago almost.
> Reinstallation is also how you fix regressions, because ms is busy with cloud services.
I've never had hardware regressions with Windows. I've had plenty of weird and annoying bugs return with Linux.
e.g. My Dell 6410 has an issue where the wifi card would die after suspend with kernel 6.1. However it would get fixed by a patch, and then get unfixed the next patch.
> As I remember, on linux I have an ample choice of kernel versions, but I didn't encounter regressions. For windows intel provides only the latest drivers.
"Swings and Roundabout".
Again. It is a pretty niche problem. I've had plenty of weird hardware regressions with the Kernel. Recently there was a AMD HDMI audio bug, IIRC it was kernel related.
No it doesn't. I barely do anything to manage my Windows Installation. I install loads of garbage (I mostly still run the same programs as I did 15 years ago).
I don't understand why people propagate these falsehoods.
You are only thinking of attacking computer directly itself. Often people socially engineer access to a computer system. Many UK super markets were hacked, using some of the software that is very secure, because people managed to socially engineer access.
There is nothing and I mean nothing that is completely secure.
> At least two independent people understood you in the same way. So just dismissing it isn't productive.
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.
> 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.
> The problem is that if what "really counts" is too vaguely defined, then it's hard to pin down and argue the point.
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".
What happens when the OS that is running the browser fails to update because /boot has run out of room for a new Linux kernel (this happened to me the other week)?
What happens when the browser update fails because the package database got corrupted?
What happens when a lock file stop the whole system updating because of a previous iffy update?
You are going to need to drop to a terminal and fix that issue or reinstall the whole OS.
Either way you are going to need to know something about how the machine works.
> The typical user doesn't know how Windows works, and they can run that.
That is because Windows for the most part manages itself and there are enough IT professionals, repairs shops and other third support options (including someone that is good with computers that lives down the road) where people can problems sorted.
This is not the case with Linux.
> These days, users can run a friendly GNU/Linux distribution not knowing how it works. So, disagree with you here.
Sooner or later there will be an issue that will need to be solved with opening up a terminal and entering a set of esoteric commands. I've been using Linux on and off since 2002. I have done a Linux from Scratch build. I have tried most of the distros over the years, everything from Ubuntu to Gentoo.
When people claim that you will never have to know how it works. That is simply incorrect and gives a false impression to new users.
I would rather that other Linux users tell potential users the truth. There is trade off. You get a lot more control over your own computer, but you will need to peek under the hood sooner or later and you maybe be on your own solving problems yourself a lot of the time.
No I am not. The example given was ridiculous and absurd and you are doing exactly the same thing.
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.
> 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.
> I think a lot of it is "nobody has bothered building it yet" vs security.
All of this takes considerable time, money to build and after that you need to get people to buy into it anyway. Large billion dollar software companies have difficulty doing this. If you think it is so easy, go away and build a proof of concept.
BTW They have implementing sand-boxing in most desktop operating system. It is often a PITA. Phone like permissions model already exist in Windows, Linux and I suspect MacOS in various guises.
For development there are various solutions that already exist.
So these things already exist and often people don't use them. The reason for that is that there is usually reduces usability by introducing annoyances.
> Eg Qubes runs everything in Xen isolates - which is a wildly complex, performance limiting way to do sandboxing on modern computers.
It exists though today. If I care about security enough, I am willing to sacrifice performance. That is a trade off that some people are willing to make.
> There are much better ways to implement sandboxing that don't limit performance or communication between applications. For example SeL4's OS level capability model. SeL4 still allows arbitrary IPC / shared memory between processes. Or Solaris / Illumos's Zones. But that route would unfortunately require rewriting / changing most modern software.
If you solution starts with "rewriting most modern software". Then it isn't really a solution.
BTW what you are suggesting is a trade off. You have to trade resources (time and money typically) to build the thing and then you will need to spend more resources to get people to buy into using your tech.
> 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?
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.
> 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).
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.
I've not needed to worry about this since Windows XP. Which was what? 25 years ago almost.
> Reinstallation is also how you fix regressions, because ms is busy with cloud services.
I've never had hardware regressions with Windows. I've had plenty of weird and annoying bugs return with Linux.
e.g. My Dell 6410 has an issue where the wifi card would die after suspend with kernel 6.1. However it would get fixed by a patch, and then get unfixed the next patch.
> As I remember, on linux I have an ample choice of kernel versions, but I didn't encounter regressions. For windows intel provides only the latest drivers.
"Swings and Roundabout".
Again. It is a pretty niche problem. I've had plenty of weird hardware regressions with the Kernel. Recently there was a AMD HDMI audio bug, IIRC it was kernel related.