[pdonis]

> It's not insecure by design really.

Sure it is. Features like Recall, which the article mentions, are insecure by design.

> the ACL and security model

I'm not sure how this is any more secure than "Unix side". But in any case the security holes in Windows are not problems with its filesystem (at least not now that FAT is no longer used).

> Anything which can read ~ is a problem

Which in a properly configured Unix system is your user and root, and that's it. So don't run things you don't trust as your user or root. Which should be obvious common sense to anyone who uses a computer.

[cjk2]

> Sure it is. Features like Recall, which the article mentions, are insecure by design.

I'm going to be honest: I'm not bothered about Recall security. It'd be on a single user machine which contains my data anyway. There are many more tasty morsels out there if a keylogger gets on it. Like the contents of my Keepass DB or my online banking PIN, neither of which Recall would be party to but anything that runs as my user shouldn't be able to see. Plus I'd probably turn it off anyway. I mean I do appreciate people kicking them in the balls which is due.

I'm not sure how this is any more secure than "Unix side". But in any case the security holes in Windows are not problems with its filesystem (at least not now that FAT is no longer used).

As for ACLs, check NT kernel architecture, particularly object security descriptors. Particularly Windows 2000 onwards. Quite elegantly put together, but with layers of crap over them.

>Which in a properly configured Unix system is your user and root, and that's it. So don't run things you don't trust as your user or root. Which should be obvious common sense to anyone who uses a computer.

So I'll have to create another user account to run a web browser, my mail client, a software package manager or a compiler?

[firebaze]

Do you think that Microsoft won't use that data in their telemetry somehow? Probably not as raw data, but as a locally AI-distilled version of it? Linked to your microsoft account, which is almost impossible to not link nowadays if you're not an expert?

Don't you agree that the data was in the initial version accessible by all local users on the same machine? Would you consider that a security leak?

Anything which could be exploited will be exploited, the only question is how long it takes.

[cjk2]

I don't disagree with any of those, other than those I have already caveated, but they are additional points.

[pdonis]

> So I'll have to create another user account to run a web browser, my mail client, a software package manager

Not if you trust those things. And if you don't trust them, you shouldn't be using them.

> or a compiler?

On my personal machine, yes, I have a separate user account for development, such as compiling programs. Creating new user accounts on a Unix machine is pretty simple.

[worksonmine]

> So I'll have to create another user account to run a web browser, my mail client, a software package manager or a compiler?

If you can't trust those you have bigger problems than them reading your home directories. If you're paranoid use flatpak.

[pdonis]

> If you're paranoid use flatpak.

I don't think this is a good solution, both because the so-called "sandboxing" isn't all it's cracked up to be, and because you now have to depend on each individual app vendor to push you security updates, instead of just your Linux distro.

The really paranoid would probably be using BSD with jails, which AFAICT is one area in which the BSDs are ahead of Linux.

[cjk2]

They're all written by idiots in C. Why would I trust them?

[pdonis]

By this criterion you shouldn't trust Windows either.

[worksonmine]

Like the rest of the OS from kernel to most of user-space. You're making solid arguments and completely missing my point.