8 ms·

This way of working should have been left behind in the previous century. Sandboxing should be default. Associating file endings should be a suggestion to the

by Too 3y ago

This way of working should have been left behind in the previous century. 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.

withinboredom 3y ago
> Sandboxing should be default. 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.
- nolist_policy 3y ago
  The problem is that sandboxing is an afterthought on these platforms.
  - withinboredom 3y ago
    That is obvious. Like saying the "sun is yellow because it is about 4.5 billion years old." 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.
    - nolist_policy 3y ago
      Performance has absolutely nothing to do with sandboxing. 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, ...).
      - michaelt 3y ago
        > Performance has absolutely nothing to do with sandboxing. 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.
        pjmlp 3y ago
        More a matter of execution than the technology. Sandboxing and virtualization existed in mainframes and micros already for decades, and were originally made available in UNIXes like Tru64 and HP-UX Vaults.
      - josefx 3y ago
        > Performance has absolutely nothing to do with sand boxing. 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.
    - gizmo 3y ago
      Every time a user space program makes an syscall the OS already has to go through layers of indirection. The OS can provide a program with a virtual or restricted view of the filesystem instead of the real thing just as easily. The OS already prevents processes from accessing each other's memory. There are some difficulties with sandboxing peripherals and GPU access, but for the most part sandboxing has absolutely no performance impact. Sandboxing doesn't mean the OS has to spin up a virtual machine every time you want to run a program.
- Semaphor 3y ago
  Does this also affect non-store sandboxes? I think it's pro-only, but windows supports sandboxing for any kind of app.
fsflover 3y ago
> Sandboxing should be default This is exactly how Qubes OS works. My daily driver, can't recommend it enough.
mike_hearn 3y ago
Windows has already made that journey years ago. The MSIX system works the way you suggest: • 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. [1] https://conveyor.hydraulic.dev/ https://conveyor.hydraulic.dev/
- maccard 3y ago
  > The ImageMagick developers can fix their problem by purchasing a cheap OV code signing certificate and then using Conveyor 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. [0] https://order.digicert.com/step1/code_signing https://order.digicert.com/step1/code_signing
  - mike_hearn 3y ago
    Well, firstly, buying certs is optional. You can distribute via the Microsoft Store and they'll sign for you. That's a $19 one time fee, no subscription. It's by far the cheapest way to distribute signed software on Windows. Conveyor can prepare everything and do the upload for you. 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/ 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.
jcelerier 3y ago
> iOS, Android and the browser has proven it is possible. 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
- pjmlp 3y ago
  Security is coming anyway, unless you stay on old Windows versions. "BlueHat IL 2023 - Default Security" https://www.youtube.com/watch?v=8T6ClX-y2AE 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-4bbe-81e7-e83abc6fa631 https://build.microsoft.com/en-US/sessions/d2ad7043-223f-4bb...
miki123211 3y ago
The problem with sandboxing is that you're limited to the APIs that your vendor provides, which stifles creativity. For a vendor to open those APIs up, they have to realize that there's somebody out there wishing to use these APIs. If all platforms were properly sandboxed from the start, a lot of software we now know and love would never have existed, it couldn't be created because of the missing APIs, but the APIs wouldn't be added because the vendor wouldn't know that some software needs them. 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.
tsimionescu 3y ago
I disagree entirely. The only reason for creating native apps is to allow apps to interoperate and integrate deeply with the OS. Apps should be free to pass data around with each other, and this absurd level of security overreach, suggesting every app should be sandboxed, is actively hurting the computing world. 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.
- mixmastamyk 3y ago
  That made sense in the olden times of a decade or two ago. Now, when you can not trust any software on your machine to refrain from exfiltrating telemetry—no longer. Even FLOSS is not enough. Thankfully open-snitch is now available on Debian.
- pjmlp 3y ago
  When $HOME is exposed to the world it matters.

by Too 3y ago

withinboredom 3y ago

> Sandboxing should be default. 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.

nolist_policy 3y ago
The problem is that sandboxing is an afterthought on these platforms.
- withinboredom 3y ago
  That is obvious. Like saying the "sun is yellow because it is about 4.5 billion years old." 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.
  - nolist_policy 3y ago
    Performance has absolutely nothing to do with sandboxing. 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, ...).
    - michaelt 3y ago
      > Performance has absolutely nothing to do with sandboxing. 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.
      - pjmlp 3y ago
        More a matter of execution than the technology. Sandboxing and virtualization existed in mainframes and micros already for decades, and were originally made available in UNIXes like Tru64 and HP-UX Vaults.
    - josefx 3y ago
      > Performance has absolutely nothing to do with sand boxing. 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.
  - gizmo 3y ago
    Every time a user space program makes an syscall the OS already has to go through layers of indirection. The OS can provide a program with a virtual or restricted view of the filesystem instead of the real thing just as easily. The OS already prevents processes from accessing each other's memory. There are some difficulties with sandboxing peripherals and GPU access, but for the most part sandboxing has absolutely no performance impact. Sandboxing doesn't mean the OS has to spin up a virtual machine every time you want to run a program.
Semaphor 3y ago
Does this also affect non-store sandboxes? I think it's pro-only, but windows supports sandboxing for any kind of app.

fsflover 3y ago

> Sandboxing should be default This is exactly how Qubes OS works. My daily driver, can't recommend it enough.

mike_hearn 3y ago

Windows has already made that journey years ago. The MSIX system works the way you suggest: • 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. [1] https://conveyor.hydraulic.dev/ https://conveyor.hydraulic.dev/

maccard 3y ago
> The ImageMagick developers can fix their problem by purchasing a cheap OV code signing certificate and then using Conveyor 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. [0] https://order.digicert.com/step1/code_signing https://order.digicert.com/step1/code_signing
- mike_hearn 3y ago
  Well, firstly, buying certs is optional. You can distribute via the Microsoft Store and they'll sign for you. That's a $19 one time fee, no subscription. It's by far the cheapest way to distribute signed software on Windows. Conveyor can prepare everything and do the upload for you. 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/ 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.

jcelerier 3y ago

> iOS, Android and the browser has proven it is possible. 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

pjmlp 3y ago
Security is coming anyway, unless you stay on old Windows versions. "BlueHat IL 2023 - Default Security" https://www.youtube.com/watch?v=8T6ClX-y2AE 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-4bbe-81e7-e83abc6fa631 https://build.microsoft.com/en-US/sessions/d2ad7043-223f-4bb...

miki123211 3y ago

The problem with sandboxing is that you're limited to the APIs that your vendor provides, which stifles creativity. For a vendor to open those APIs up, they have to realize that there's somebody out there wishing to use these APIs. If all platforms were properly sandboxed from the start, a lot of software we now know and love would never have existed, it couldn't be created because of the missing APIs, but the APIs wouldn't be added because the vendor wouldn't know that some software needs them. 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.

tsimionescu 3y ago

I disagree entirely. The only reason for creating native apps is to allow apps to interoperate and integrate deeply with the OS. Apps should be free to pass data around with each other, and this absurd level of security overreach, suggesting every app should be sandboxed, is actively hurting the computing world. 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.

mixmastamyk 3y ago
That made sense in the olden times of a decade or two ago. Now, when you can not trust any software on your machine to refrain from exfiltrating telemetry—no longer. Even FLOSS is not enough. Thankfully open-snitch is now available on Debian.
pjmlp 3y ago
When $HOME is exposed to the world it matters.