> Instead what will happen is more tightening of the walled garden
You know what? I'm starting to get excited for the walled garden to get more walls.
Native desktop applications get far too many permissions by default - its crazy that any desktop application, once running can register itself at startup, see all my files (created by any application), register system-wide keyloggers, take screenshots of other applications and download my contacts list, all without my permission. We don't let web apps do that, because web app developers aren't trusted by default. We don't let mobile apps do that, because mobile app developers aren't trusted by default. Why on earth do we implicitly trust any executable file run on the desktop so much?
Telling users not to double click on executables is obviously not working. Even for experienced users I have no idea whether some random app on the internet is trustworthy. Its a reverse lottery. I also suspect ransomware like this one would have been slowed down if it needed explicit user permission to read & modify files on disk.
We even know what the sandbox should look like, because we have two working examples in the form of the web and mobile. And we have sandboxing support & APIs in most operating systems. We're just missing the UI part.
I'm imagining something like:
- All apps get signed by the developer (Lean on SSL? Not sure the chain here.)
- The app needs to request capabilities from the user, like on iOS. "App X by Y developer wants permission to read the files in your home directory". (/ Read your contacts / Register at startup / Take screenshots / Modify these files).
- Capabilities can be viewed and revoked at a system-wide level in the control panel / system preferences.
That's fine and dandy - I'm all for it, in fact, I configure my systems thus with 3rd party tools as much as I can. Android is mostly like this (with a less than perfect implementation)
But when people talk of "walled gardens", they mostly refer to the guardian at the entrance. Only Apple decides what runs on iOS, only Microsoft decides whats in the App Shop. That's NOT good for anyone (except Apple and Microsoft).
Sure, make users jump through hoops to install alternate stores, and warn them up the wazoo when they do that. But do let them, or general purpose computing as we know it is gone.
Security professionals are almost completely unanimous about how effective Apple has been with it's "walled garden". I'm not even an Apple fan, but what they have done is pretty amazing from a security perspective. Like it or not it has worked to keep people safe from many many types of attacks.
Sandboxing and tighter security are orthogonal to app stores. The same security policy should apply to every app, regardless of whether it was installed through the official store or from another source.
What the grandparent is suggesting is akin to UAC, which received much hate when it first debuted in Vista but has now become a mostly accepted part of the Windows user experience. It has been done before, and it can be done again, with every Windows app, not just apps from the Microsoft Store.
They are orthogonal in theory, but so far not in practice - all three appstores in common use (iOS, macOS, Android) have mandated sandboxing and security.
grandparent was suggesting UAC, but started with:
> You know what? I'm starting to get excited for the walled garden to get more walls.
Yeah I don't want the only distribution model to be an App Store. And I don't want to lose the ability to run things with root access.
But I strongly believe that right now apps get too much access by default (read, write all my files is crazy). And if they need anything beyond that they just ask for root. There needs to be much more granular permissions, with more restrictive defaults and nice informative dialogs.
It's unsexy, and inconvenient for developers. But it's the right thing for our users. It's how I want random programs downloaded from the internet to behave.
>You know what? I'm starting to get excited for the walled garden to get more walls.
Yep. What developer types don't like to admit is that for the average user, who doesn't use the features excluded by the walled garden anyway, the tradeoff is well worth the security gains.
Why do you think people would treat them any differently from the UAC screen of Windows 7? That is, just click OK to grant whatever permission it wants, or disable it entirely to avoid the annoyance.
You know what? I'm starting to get excited for the walled garden to get more walls.
Native desktop applications get far too many permissions by default - its crazy that any desktop application, once running can register itself at startup, see all my files (created by any application), register system-wide keyloggers, take screenshots of other applications and download my contacts list, all without my permission. We don't let web apps do that, because web app developers aren't trusted by default. We don't let mobile apps do that, because mobile app developers aren't trusted by default. Why on earth do we implicitly trust any executable file run on the desktop so much?
Telling users not to double click on executables is obviously not working. Even for experienced users I have no idea whether some random app on the internet is trustworthy. Its a reverse lottery. I also suspect ransomware like this one would have been slowed down if it needed explicit user permission to read & modify files on disk.
We even know what the sandbox should look like, because we have two working examples in the form of the web and mobile. And we have sandboxing support & APIs in most operating systems. We're just missing the UI part.
I'm imagining something like:
- All apps get signed by the developer (Lean on SSL? Not sure the chain here.)
- The app needs to request capabilities from the user, like on iOS. "App X by Y developer wants permission to read the files in your home directory". (/ Read your contacts / Register at startup / Take screenshots / Modify these files).
- Capabilities can be viewed and revoked at a system-wide level in the control panel / system preferences.