10 ms·

> The barrier to install native software should be very, very high. No, the barrier that the software must leap to do awful things to your computer should be v

> The barrier to install native software should be very, very high. No, the barrier that the software must leap to do awful things to your computer should be very high. Folks complain about the secure enclave, the signing requirements, the notarization, sandboxes, etc. But those are all barriers on the producer side. App stores help mitigate this. Folks don't think twice about downloading an iOS app from the app store (I do, but I'm not normal -- I hate apps). Look at the hoops Apple had to, and continues to, go through to keep applications from unknowingly looting the user. The most criminal thing, historically, done by Windows over the ages was simply requiring EVERYTHING to be "admin". You couldn't install Minesweeper without typing in your password. So, everyone, naturally, automatically, does so without a second thought. They're conditioned that this is OK. It's not OK. It was never OK. The whole idea of having to do that, type in your password to install software, should have a big red, DO NOT DO THIS, bouncing and dancing bear around it. The Mac has always had less of this. Seems most of the exploits require users to download software and give it admin privileges. Yea, Don't Do That. Of course, the problem is the culture. It would be nice to not have to Caveat Emptor every darn thing under the assumption that it's horribly dangerous. It would be nice to grab a plum off a display and eat it without having to vet the vendor. But, bad actors, rampant bad actors, and rampant "good actors" behaving badly, have proven that we just don't live in that kind of world. Installing "safe" software, should be simple.

solardev 4y ago
We have an ecosystem where running nontrusted software can be relatively safe... it's just on the web. Legacy desktop OSes don't have the permissions models that make this easily achievable outside the browser. Even the mobile platforms are only slowly evolving (I want this app to access ONLY this folder or that picture, not all my user files). Frankly I would never trust users to be able to differentiate between sane and unnecessary permissions. If you make everything super granular or repetitive it's just going to lead to banner blindness (yes, damn it Google, I want this hiking app to know precisely where I am... I told you the last seven times you asked). Or on iOS, having to enter my longass Apple password just to download a free app whenever the fingerprint scanner doesn't work (which is usually). Even without security concerns, native apps are a pain in the ass. The web is nice in that most of the sandboxing is invisible unless you need special sensor permissions (location, mic, camera, etc.) and so the user never gets bugged about it. Or has to worry about platform idiosyncrasies, disk space, versions, etc. In many ways the web is a superior app delivery platform. Why bother installing "safe" software when you can just run it in a sandbox without any installation or prompts at all? What Java and .NET tried to do back in the day now just happens, sight unseen, in browser windows.
- zzo38computer 4y ago
  Unfortunately there are problems with running it on the web (and many problems with its design, and problems with implementations), as well as problems with native permission models of some systems, too. For example, it is not very good working for: command-line with pipes, non-Unicode character encodings, non-USB devices, non-HTTP(S) protocols, working local files without internet connection, interaction with other local programs in a good way, etc. Permissions need not be asking every time (if user will configure it to always allow or deny or other settings), and need not only be "allow"/"deny"; for example, if it requests the camera access then the user might enter a command to use instead, which might access the camera (possibly with filters such as fault simulation), or do something else such as returns a still picture (which you can use if you do not have a camera, for example), and this can be "wired" by the user configuration if not wanted to enter every time. Disk space is going to matter for any program that stores files, although one which is designed well will allow the end user to specify a disk quota for this program if desired, and will also allow specifying default disk quotas in the manifest, in order that you can use it without needing to know about these things and manually set them up, too. I had tried to make the specification of "VM3" which is meant to, among other things, solve these problems. A program can be install or just run, and all I/O must use extensions, which makes both extensible capabilities and highly user configurable capabilites. The same is true for program entries (e.g. command-line, GUI, etc). There are also some other minor things I had done differently due to I think being better than what some other designs are working.
  - solardev 4y ago
    I think that kind of computing will become more and more the realm of specialists (devs, computer scientists, whatever) doing their work, with specialized tools and permissions models. For 99.9% of regular people, there is no reason to expose them to so much unnecessary complexity. Just like with supply pipelines, most people don't need to care or know about information pipelines... they just want to consume the thing they're there to get, whether it's refined petroleum or some unit of information. All tools are built up from layers of primitives, like a car is made up of components and nuts and bolts and such, but drivers don't need to know or care how its ECU or ICE works. I think the web / mass-market computing is similar... it just doesn't (and I'd argue shouldn't) matter to most people. It's the difference between engineering for other engineers and designing for end-users, two related but ultimately separate concerns.
ho_schi 4y ago
That's right. Let us add here Linux. It did always separated users and process and software is maintained by distributions, which you trust. Nowadays more important, it supports control-groups which separate the actual applications. Therefore Flatpak and Docker. The idea of notarization and entitlements on MacOS is good. Maybe it is a lack of knowledge and experience on my side but the documentation needs improvement. I miss a good HowTo presenting manual usage of tools for notarization and entitlements. Apples seems to expect usage of XCode which is often not the case. Especially MacOS isn't able to report missing entitlements which required a lot time. Generally Apples stuff often doesn't provide status messages and valuable logs. I expected MacOS to show the message "App Bundle Foo is missing entitlement Bar". Also the Apple support didn't noticed that.

solardev 4y ago

We have an ecosystem where running nontrusted software can be relatively safe... it's just on the web. Legacy desktop OSes don't have the permissions models that make this easily achievable outside the browser. Even the mobile platforms are only slowly evolving (I want this app to access ONLY this folder or that picture, not all my user files). Frankly I would never trust users to be able to differentiate between sane and unnecessary permissions. If you make everything super granular or repetitive it's just going to lead to banner blindness (yes, damn it Google, I want this hiking app to know precisely where I am... I told you the last seven times you asked). Or on iOS, having to enter my longass Apple password just to download a free app whenever the fingerprint scanner doesn't work (which is usually). Even without security concerns, native apps are a pain in the ass. The web is nice in that most of the sandboxing is invisible unless you need special sensor permissions (location, mic, camera, etc.) and so the user never gets bugged about it. Or has to worry about platform idiosyncrasies, disk space, versions, etc. In many ways the web is a superior app delivery platform. Why bother installing "safe" software when you can just run it in a sandbox without any installation or prompts at all? What Java and .NET tried to do back in the day now just happens, sight unseen, in browser windows.

zzo38computer 4y ago
Unfortunately there are problems with running it on the web (and many problems with its design, and problems with implementations), as well as problems with native permission models of some systems, too. For example, it is not very good working for: command-line with pipes, non-Unicode character encodings, non-USB devices, non-HTTP(S) protocols, working local files without internet connection, interaction with other local programs in a good way, etc. Permissions need not be asking every time (if user will configure it to always allow or deny or other settings), and need not only be "allow"/"deny"; for example, if it requests the camera access then the user might enter a command to use instead, which might access the camera (possibly with filters such as fault simulation), or do something else such as returns a still picture (which you can use if you do not have a camera, for example), and this can be "wired" by the user configuration if not wanted to enter every time. Disk space is going to matter for any program that stores files, although one which is designed well will allow the end user to specify a disk quota for this program if desired, and will also allow specifying default disk quotas in the manifest, in order that you can use it without needing to know about these things and manually set them up, too. I had tried to make the specification of "VM3" which is meant to, among other things, solve these problems. A program can be install or just run, and all I/O must use extensions, which makes both extensible capabilities and highly user configurable capabilites. The same is true for program entries (e.g. command-line, GUI, etc). There are also some other minor things I had done differently due to I think being better than what some other designs are working.
- solardev 4y ago
  I think that kind of computing will become more and more the realm of specialists (devs, computer scientists, whatever) doing their work, with specialized tools and permissions models. For 99.9% of regular people, there is no reason to expose them to so much unnecessary complexity. Just like with supply pipelines, most people don't need to care or know about information pipelines... they just want to consume the thing they're there to get, whether it's refined petroleum or some unit of information. All tools are built up from layers of primitives, like a car is made up of components and nuts and bolts and such, but drivers don't need to know or care how its ECU or ICE works. I think the web / mass-market computing is similar... it just doesn't (and I'd argue shouldn't) matter to most people. It's the difference between engineering for other engineers and designing for end-users, two related but ultimately separate concerns.

ho_schi 4y ago

That's right. Let us add here Linux. It did always separated users and process and software is maintained by distributions, which you trust. Nowadays more important, it supports control-groups which separate the actual applications. Therefore Flatpak and Docker. The idea of notarization and entitlements on MacOS is good. Maybe it is a lack of knowledge and experience on my side but the documentation needs improvement. I miss a good HowTo presenting manual usage of tools for notarization and entitlements. Apples seems to expect usage of XCode which is often not the case. Especially MacOS isn't able to report missing entitlements which required a lot time. Generally Apples stuff often doesn't provide status messages and valuable logs. I expected MacOS to show the message "App Bundle Foo is missing entitlement Bar". Also the Apple support didn't noticed that.