Microsoft is rewarded for security, privacy and reliability failures each time a consumer buys another Windows PC.
And, to be fair, so is every other software project with an imperfect track record, that continues to have users, whether FOSS or closed source.
I'm about to say goodbye to Windows forever -- and it has nothing to do with their security vulnerabilities. It has to do with 1) the incredibly shitty software they produce (Windows 11) and 2) their lack of ethics in regards to pretty much everything. I'm about to go all in on Linux - I've been using both OSes for years now but Linux to me today is the superior choice and I see 0 reason why anyone would want to touch Windows (and I hope to god many developers follow me) -- Windows is an absolute atrocity.
I'm with you 100%.
I'm typing this on a computer that came with Windows 11. I booted it a few times, and reserved a terabyte of my (8TB) SSD for it, but I never use it at all. I've got some Windows VMs, from XP through 10 that I rarely use, but I use them when needed for things that require those platforms.
I got an email from Intuit two weeks ago informing me that they weren't going to support Windows 10 anymore, so I guess I'll be deleting my Windows 10 VM soon, but I have no intention of ever creating or running a Windows 11 VM, or installing anything important on the soon-to-be-deleted Windows 11 partition I have, so I guess I'll quit using TurboTax after 40 years of using it.
I looked into the possibility of running TurboTax with Wine (or CrossOver, for which I have an eternal license), but apparently it doesn't run at all there.
I don't use Linux as my primary OS anymore. However the default protections of the Linux desktop is worse than Windows's which is rather sad. For "root" level operations Windows has several layers to protect the system itself. The newer Appx packages are have scoped security protections around them.
On Linux, yes you can spend months modifying Flatpaks, or writing SELinux rules or apparmor profiles but nobody does that. The out-of-the-box Linux user distros are quite a bit lacking and it is only a matter of time that malware that steal secrets from home directory to arrive to Linux too.
> On Linux, yes you can spend months modifying Flatpaks, or writing SELinux rules or apparmor profiles but nobody does that.
For what it's worth, RHEL and to some degree Fedora do give you those SELinux rules for most of their packages. That OOB for anything you would install with rpm.
> it is only a matter of time that malware that steal secrets from home directory to arrive to Linux too.
No need to wait? Most of the malware distributed over npm/pypi has supported Linux and sometimes MacOS for a long time.
Windows has AppContainers which is for the most part a wrapper around the Windows Kernel Mandatory Integrity Level (MIL) feature.[1][2] MIL restricts certain API calls of processes depending on the integrity level of the current process vs. integrity level of a target process for the API call. The idea being a process with a low integrity level wouldn't be able to read or write via IPC to a process with a high integrity level. The process with a high integrity level would instead need to read or write via IPC to the process with a low integrity level.[3]
Because there are obvious architectural limitations of having a linear scale of privilege levels which one places all processes on, Windows has tried implementing "Windows Sandbox" as an alternative sandboxing mechanism that executes a process in a Hyper-V virtual machine that has restrictions placed on the interfaces exposed into the virtual machine.
I believe Windows Kernel still doesn't have any similar functionality to Linux's namespaces that are much more capable and flexible with sandboxing applications. The reason I recall is Windows' GDI subsystem (painting/drawing) being implemented within the Windows Kernel, not a userspace process as you see with Wayland compositors on Linux systems. This GDI subsystem I believe was the main problem holding back the Windows Kernel from implementing Linux-like namespace and sandboxing functionality.
Linux and common desktop environments such as Gnome also offer sandboxing out-of-the-box in more ways than a typical Windows installation, including as examples:
- very granular seccomp filters implemented for system processes (typically via the simple and accessible method of systemd service configuration) to only permit a process to make certain syscalls or access only specific system resources (files, network interfaces, etc)
- seccomp filters for revoking permissions on processes once they've started up and no longer need certain permissions. See for example OpenSSH and how it forks into less privileged processes once ports have been opened, keyfiles read, etc.
- Use of multi-process application architectures where each process is individually sandboxed, where a Windows equivalent would be a monolithic application. See for example use of "glycin" in Gnome applications for parsing and loading images in separate sandboxed processes from other parts of the application[4], or "tracker" again in Gnome applications which sandboxes the processes for metadata extraction from each file.
[1] https://learn.microsoft.com/en-us/windows/security/book/appl...
[2] https://learn.microsoft.com/en-us/windows/apps/windows-app-s...
[3] https://learn.microsoft.com/en-us/previous-versions/dotnet/a...
[4] https://gitlab.gnome.org/GNOME/glycin
edit: some references added
Just to add a bit of history--there was a little known software product, a name which I cannot remember or find, in the early 2000s for Windows NT based operating systems, which hooked API calls of Windows applications to implement seccomp-like filtering for random Windows applications. I recall it allowed users to restrict an application to not perform certain system actions, access certain folders/files, etc. It was well ahead of its time for early 2000s operating system hardening and I think may have been an inspiration arising from early 2000s rootkits.
It predated https://github.com/sandboxie-plus/Sandboxie but Sandboxie is an example (from 2004) of a similar project that has a longer development history. There have been other similar projects that have come and gone over the years too.
Could it have been something out of Mark Russinovich's Sysinternals?
Windows has had namespace capabilities for ages, via Windows jobs, which are used on Windows containers infrastructure.
Nowadays serveral kernel services and drivers are virtualized, running inside Hyper-V instances.
Some of the Windows 11 hardware requirements is that all optional virtualization and sanboxing security features are no longer optional.
"Job" objects allow some resource limits to be applied to groups of processes (including any children they spawn) but don't do much or anything for restricting the system resources accessible to process in a job.[1] Instead that is a feature called "silos"[2][3][4], as well as the accompanying use of Windows Brokering File System filter driver[5] (or is it UCIFS, or BFS+UCIFS...?[4]), as well as SeAccessCheck interception[6], and whatever else applied to a "silo" or processes.
Hardly anything about "silos" and seemingly nothing about BFS (for providing a virtual filesystem to a process) is documented publicly by Microsoft. Unless a Windows application developer has a particular interest in reverse engineering the Windows Kernel, they're probably not going to be using much of Windows Kernel sandboxing/isolation techniques beyond the simple interface that UWP exposes for GUI applications because it's just too hard otherwise.
For example, in the excellent description of this officially undocumented mess at [2] and [3], the author notes:
"What is interesting here is that there does not seem to be any general mechanisms for restricting access to syscalls globally, which means that the attack surface can be quite large. Indeed, even if it is possible for the Kernel to know if the execution comes from inside a Silo, each syscall must set up its checks (or not). In addition, some syscalls do not directly block access to Silos, but rather implement a different logic between a host and Silo context."
Another author at [4] finds all sorts of unexpected behaviours from this complex use of call interception, filter drivers, etc, such as endpoint security software not being aware of silos and use of filter drivers like BFS, etc, and not properly restricting or logging activities of "sandboxed" processes as developers and users of endpoint security software may expect.
Even if someone reverse engineered an adequate understanding of silos and whatever else Microsoft call "Process Isolation", they'd also potentially have to then learn the completely different Hyper-V isolation approach, as well as Mandatory Integrity Levels (MILs), as well as old school Windows ACL permissions, as well as the newish "Virtual Secure Mode" (VSM)[7]. It'd be like setting up a Linux system that has every Linux Security Module (LSM) enabled at once because SELinux is just too simple on its own.
[1] https://learn.microsoft.com/en-us/windows/win32/procthread/j...
[2] https://blog.quarkslab.com/reversing-windows-container-episo...
[3] https://blog.quarkslab.com/reversing-windows-container-part-...
[4] https://www.deepinstinct.com/blog/contain-yourself-staying-u...
[5] https://ht3labs.com/Brokering-File-System-January-2025-Patch...
[6] https://learn.microsoft.com/en-us/windows/win32/secauthz/imp...
[7] https://github.com/tpn/pdfs/blob/master/Battle%20of%20SKM%20...
Yeah I hate Microsoft as much as the next guy but every product has security vulnerabilities. If the product is popular enough, then hackers spend time discovering those vulnerabilities.