Comment by mikewarot
20 days ago
>Unfortunately, it actually is the best means to keep a society of the masses functioning more safely online
Imagine if people felt that way about electrical power distribution? Every single thing you ever plugged in required a license to be validated at the time you tried to use an outlet?
For me, it's obvious that better ways of doing things exist, but I'm weird, and possibly a crank.
The solution, in my opinion, is to do the same thing we do with power in the home... limit the damage that can be done by anything plugged in, only giving away a limited capability for power delivery in a given outlet.
The analogous way to do this in an operating system is to discard the idea of providing all of the computing resources available to every program you run, and limit it in some way. The "permissions flags" we've all come to dread, first with UAC in Microsoft Windows, and now on our phones, obviously suck, and won't work.
The way to do it on a desktop, is to allow the user to choose exactly which resources a program may use, at runtime, by dialog boxes similar to the ones they already use, but with the additional behavior that the operating system enforces their choices, instead of just praying a program operates as intended.
On a phone, I don't have as strong an intuition, but I'm sure it can be worked out, both in a friendly, and secure way that doesn't require full time checking with consent from our betters in the corporate overlord hierarchy.
We can have secure and user friendly compute, both in our desktops, and in all our devices.
> The way to do it on a desktop, is to allow the user to choose exactly which resources a program may use, at runtime, by dialog boxes similar to the ones they already use, but with the additional behavior that the operating system enforces their choices, instead of just praying a program operates as intended.
> We can have secure and user friendly compute, both in our desktops, and in all our devices.
I'm doubtful about that, e.g. basically all existing file system sandboxing implementations that I'm aware of tend to break workflows that are more complex than "open exactly the one single file the user selected". (Apple's implementation tries a bit harder, but you still run into limitations pretty quickly.)
E.g. when I open an image in my favourite image viewer, I don't just want to view the one picture I've opened, often enough I also want to browse through other pictures within the same directory without having to explicitly open all those other images through some OS-secured gateway. And even that isn't enough, because my favourite image viewer also has the nifty feature of being able to quickly switch into a different directory (plus it has its own built-in thumbnail directory browser), so ultimately the only way to use its full functionality is through full file system access.
Or videos – subtitles are often enough stored in separate files, so a video player will want to look for those files, too, when it starts playing a video. Split-up archive files work along the same lines, too.
And never mind things like both HTML or DWG files, both of which can reference arbitrary other files up and down the directory hierarchy which need to be loaded at the same time, too…
Now the OS can't be expected to know about the peculiarities of each and every file type, plus you can't make permissions dialogues arbitrarily complex, either, which leads you back to the dilemma of ultimately either breaking more complex workflows, or else having to provide an escape hatch that then promptly runs the risk of getting abused by malicious actors, too.