And many programs require some kind of integration into the OS, such as file type associations or context menu entries, which even a single user shouldn't have access to do.
Sandboxing should be default. Associating file endings should be a suggestion to the OS, accepted by the user, not something only configurable by delegating full super admin to third party app.
Slow loading context menus where every app tries to claim its presence. Thank you for reminding me why I don’t use Windows since years ago.
A image editor should only need to load and save images I ask it to, no other system integration. iOS, Android and the browser has proven it is possible. Now the desktop needs a similar journey.
Please no. There are valid reasons to NOT sandbox, and in Windows there is sandboxing in default (windows store apps) and there are often issues with those versions of the software. For example, Slack downloaded from the windows store uses 30-40% of your CPU while idle, but not when installed from their website.
Even in Linux and using the Snap sandbox (ubuntu), there are significant issues when trying to access globally available software, which can be extremely hard to support and diagnose.
Even if sandboxing was thought about back when Linus was porting Unix, it would have been extremely slow as processors and ram was very limited back then. If we could go back in time and give them ridiculously fast processors and effectively unlimited ram like we have today, I'm sure Linux and Windows (er, DOS) would look quite different, and be much slower.
Just look at how slow mobile OS's are, despite being on ridiculously fast hardware. My Palm Pilot in 1998 felt faster and more responsive than most devices today. Android devices essentially require a human to manage the memory because starting just a few apps uses almost all of it. Even iOS devices can only run a few apps before it starts killing things. Sandboxing has an extremely high cost (with not much to gain), so high that even on modern hardware you start running into physical limits very quickly: memory, disk space, and processing power.
Until we can properly share resources in sandboxed apps (or increase the physical limits of the hardware) to a certain point, it just doesn't make sense to only be able to run a few things on a desktop machine.
Heck you could already apply many sandboxing techniques with Linux 0.x by chroot() to an empty directory followed by setuid() to "nobody". If that process needs file access, fork() a broker process before the chroot() that funnels file descriptors over an unix socket to the sandboxed process. The broker strictly checks file access permissions of course or could even present the file open dialog to the user.
This is next to no overhead in many cases (keep in mind you'll stat/open/mmap a bunch of .so's anyways on startup), except for the fork() maybe. And that can be fixed by proper sandboxing API's by the OS.
The problem is that these OS's give the processes to much permissions in the fist place (access to all the user's files, ...).
In theory, sure.
In practice, when Ubuntu added a sandbox to the calculator it started taking longer to start than Eclipse. Took them about 4 years to fix it.
Sandboxing and virtualization existed in mainframes and micros already for decades, and were originally made available in UNIXes like Tru64 and HP-UX Vaults.
Even simple optimizations like shared caches fall afoul of proper isolation. In the past browser caches could be abused to find out if a user frequented specific sites just by checking how long it would take to request a site specific resource. Result: no more shared caching, all resources had to be loaded for each site separately.
Any reasonable representation of its color would classify the Sun as white, except when comparing it to other stars, where the small differences matter a lot.
This is exactly how Qubes OS works. My daily driver, can't recommend it enough.
• Admin privs aren't needed
• Packages declare what integration points they need in an XML file
It's similar to the way macOS, iOS and Android work. You can also (starting soon in Win11) declare that the app will be sandboxed.
However, developers have to actually use this system and most don't know it exists or how to use it.
The ImageMagick developers can fix their problem by purchasing a cheap OV code signing certificate and then using Conveyor [1], which is a product my company makes. It can make these MSIX files along with all the new formats it requires for things like icons, and it can do so from Linux or macOS or whatever the developers prefer to use. So you can do releases locally without needing CI/CD or cloud signing.
Now, they'd like to have releases be done by GitHub Actions instead of using local hardware, and that would require a cloud signing service as they say. Conveyor can use those too. But that's not a technical requirement anymore, because it doesn't use any of the native toolchains so you don't need to release Windows binaries from Windows (or Mac from Mac). Conveyor can create all the files for installing and updates, and then upload them to a GitHub Release or ordinary web server, and it's free for open source projects. Given that they're initiating the release process from a laptop anyway, they can do it all locally.
Conveyor can also self-sign but that's more just to enable the tracking of permissions and things for all software. Self signed binaries still trigger warnings obviously.
By "cheap" you mean $500/year[0]? Then for anyone who isn't open source it's another $45/month on top for Conveyor. That's hardly "accessible".
That said, Conveyor looks awesome. We (thankfully) distribute our application via Steam/EGS/etc but when we were looking at bundling installers before that it was a nightmare and we probably would have just paid for Conveyor.
So this stuff only applies if you don't want to go via the store.
Now you picked DigiCert and their cloud HSM solution. They're unfortunately quite expensive. SSL.com is a lot cheaper:
https://www.ssl.com/certificates/code-signing/buy/
So about $100 / yr, with a one off fee to buy a USB key.
And then ImageMagick is open source so they could use the tool for free.
Even commercially, $100/yr plus $45/month isn't particularly expensive compared to the labor cost of developing software commercially. The cost of the tool is like one hour of skilled labor at contracting rates per month. It'll save far more time than that given that as you said, doing deployment by hand is a nightmare.
And as you note, if your app is open source then you can use it for free. So then we're down to using the MS Store + Conveyor for free: $19, one off. Anyone can afford that.
I'm going to ignore Conveyor because that post was just a sly advertisement.
Whatever woes Windows's UX and design choices cause, I'd still take it a million times over any of these three terribly improductive environments
"BlueHat IL 2023 - Default Security"
https://www.youtube.com/watch?v=8T6ClX-y2AE
"Modernize your Win32 application for security and privacy"
https://build.microsoft.com/en-US/sessions/d2ad7043-223f-4bb...
Screen readers are a good example, proper accessibility APIs came later, as a response to screen readers' needs. The first screen readers used various tricks for injecting code into other processes and emulating GPU drivers to intercept GDI calls.
Sure, if you're making a game or some browser replacement, then go for sandboxing. But most productivity software shouldn't be confined to that. We need computing to stay open, not to all be closed down mobile OS style.
Thankfully open-snitch is now available on Debian.
User-only installs are possible:
> C:\Users\YourUsername\AppData\Local is intended for MSI installations for a single user but typically doesn't require Administrative privileges. This folder is normally hidden.
* https://superuser.com/questions/1327037/what-choices-do-i-ha...
This is the variable %LOCALAPPDATA%:
* https://pureinfotech.com/list-environment-variables-windows-...
See also perhaps CSIDL_DEFAULT_APPDATA and CSIDL_DEFAULT_LOCAL_APPDATA:
* https://learn.microsoft.com/en-us/windows/deployment/usmt/us...