Unlike Medicine, many of the ideas that we had in the past were better than the commonly accepted way things are done now.
Capability based security, for example was something that allowed you to run any program, with no danger to your system. It's not part of any common OS. They had it at Xerox PARC, but Steve Jobs chose not to take that part.
On the other hand, the PARC focus on replicating paper was a step backwards from work by Engelbart and others.
The limitation of a single desktop was put in place to allow children to ease into the desktop metaphor... it wasn't meant for adults to be stuck with the training wheels on.
I've been digging back, looking for the ideas we missed... and boy, there are some really powerful tools waiting to be reified in a modern context.
Capability based security, for example was something that allowed you to run any program, with no danger to your system. It's not part of any common OS.
I know, I know. Norm Hardy was really good, his system, KeyCos, worked, and few could understand him. I used to know his "explainer", Susan Rajunas. We don't even have proper "rings of protection", like Multics, any more.
Although the real problem today is that we need to run programs with less authority than the user running them, and we still lack a good conceptual model for doing that. "Allow write to SD card" is far, far too powerful a privilege to grant.
we need to run programs with less authority than the user running them, and we still lack a good conceptual model for doing that
Isn't this now the standard reality for most desktop and mobile OSs?
"Allow write to SD card" is far, far too powerful a privilege to grant.
Granting a permission based upon user approval is never secure anyway since if they want to see the porn / flashing lights they are going to click the button regardless. Having spent some time with both carriers and mobile device manufacturers, there are also areas of undeclared commercial utility in keeping control with the OS (device manufacturer) and out of the hands of the user: DRM, app sales, increased chargeable mobile data use, reduced chance of non-cellular data paths (mesh networking), etc.
People manage permissions just fine in the real world... if you have money in your pocket, you can pick and choose what portion of it to hand to the cashier when you're purchasing something.
When you had someone $3.50... you're giving them $3.50 of capability, and no matter how clever the Loch Ness Monster is, they'll never get more than that $3.50.
If on the other hand, you have to give them the entire wallet... like you do in Windows, Linux, etc... the game is over.
Capability Based Security is NOT the same as "Global Permission to do X"
PayPal exists because it is an instantiation of capabilities for finance on the internet.
That was the old way. The new way is you give them your credit card or WeChat 'bill me' code. You get billed whatever the merchant wants to bill. Any post-facto complaint will be at the cost of your own time.
Your further analogy is factually inaccurate. Under Windows, AFAIK most programs have a partially restricted permission set, hence Run as administrator. In Linux, under modern distributions, most programs run in both a user and a cgroup context, and some under further restrictions such as chroot and caps.
>The new way is you give them your credit card or WeChat 'bill me' code. You get billed whatever the merchant wants to bill. Any post-facto complaint will be at the cost of your own time.
Sure, that may be the "new" way, but that doesn't mean it's better! Much of the payment fraud online couldn't exist if customers were in control of how much money to send and when rather than the merchant.
>Under Windows, AFAIK most programs have a partially restricted permission set, hence Run as administrator. In Linux, under modern distributions, most programs run in both a user and a cgroup context, and some under further restrictions such as chroot and caps.
Under normal circumstances, they're restricted only to the extent that your user is restricted. That's far from the level of granularity that GP is talking about.
> Isn't this now the standard reality for most desktop and mobile OSs?
Not really, no. Because there isn't a comprehensive intent layer in the UI that is fully trusted and in which the user can grant capabilities.
Just a couple examples; if you download a PDF file with a mobile browser and want to open it in an app, the only option is to grant eternal (unless you manually revoke it) access to the local file system to the entire viewer app. A capability-aware UI would, at the "what do you want to do with this file?" system dialog grant a one time capability to read the particular file to the app the user picks. The capability persists as long as the app retains it. The app can't fork off a sub-process or send it to another app and clone the capability to the file; it would have to ask the user to do that. The mechanism for that trusted user request and response is where all UIs (and most CLIs) fail.
Designing a safe and useful capability desktop/mobile environment is hard. Modern UIs and CLIs are just papering over the details of actual objects in the privilege system. Icons and filenames are only a human-readable representation of objects accessible with capabilities and so there's a disconnect between UI representation, user intent, and user interactions. Solving that means replacing arbitrary custom UIs with trusted, object-aware system UIs that reveal the actual state of capabilities and objects instead of a simplified representation.
> Granting a permission based upon user approval is never secure anyway since if they want to see the porn / flashing lights they are going to click the button regardless.
The UI model would have to be significantly different with a lot of trusted components. Basically any UI element that can grant a capability to another app/process has to be part of the trusted system. That means a user-level app can't even ask for permissions to objects because it can't see them, know they exist, or refer to them in a way the system UI could grant a capability. Interaction between applications would be more like a smart clipboard; a user would open their camera app, take a picture, and grant a read capability to an app that's waiting for it.
There's a lot of 'convenience' lost in a pure capability system because there's no default trust in the good intentions of app developers.
There is a potential further development that allows convenience; formal proofs for application software that adheres to a particular data management policy. Say instagram wants to formally verify that photos taken automatically by the app (selfie button or whatever) can never be uploaded without user permission. Prove that the component for taking photos within the app drops all capabilities to the network and the main app itself before taking any photos; all it can do is fill up a particular folder/directory with new photos that are visible to the user, who can then trigger an upload (grant capability to a particular photo to the main app from a secure view of the directory) with another trusted interface. That trusted component could be granted a capability to the camera itself once the proof is verified.
Clearly if reasonable security is a goal default trust should be restricted. Minimum trust thresholds should be distinct from sometimes-needed trust which should be delineated on a per-item/per-session/temporally restricted basis.
Currently the way the web works, 1st party user downloading almost any 2nd party file means a 3rd party app of user-defined identity starts and reads the 2nd party file from a 4th party server in a 5th party format running on a 6th party OS with a 7th party network, 8th party browser and 9th+ party certificate chain in an unknown filesystem context. What is wrong with this picture? You can't establish trust in this context. All you can do is establish boundaries for failure.
Modern history has shown that this tower-of-crap™ approach is the most commercially expedient means to distribute new functionality to general computing devices. I would argue that the path forward in general computing is therefore to work on processes to enhance and apply those restrictions using improved architectural decisions at the interface level combined with CI/CD processes that automatically apply them.
In short: stop asking the user, just design the system to grossly limit the scope and impact of any damage.
> In short: stop asking the user, just design the system to grossly limit the scope and impact of any damage.
Yep. This has to come from OS vendors and while iOS and Android took some steps in this direction they're still basically POSIX about it instead of capability-based.
There's also a really unfortunate trend where apps want to be the entire user interface for everything. Manage the SMSs, be the camera and photos albums, handle payments, etc. This breaks all security guarantees by the OS.
> A capability-aware UI would, at the "what do you want to do with this file?" system dialog grant a one time capability to read the particular file to the app the user picks. The capability persists as long as the app retains it. The app can't fork off a sub-process or send it to another app and clone the capability to the file; it would have to ask the user to do that. The mechanism for that trusted user request and response is where all UIs (and most CLIs) fail.
I'm not an expert on iOS. From reading their latest security guide and a bit of wikipedia I think the following is true:
* iOS uses the ZNU kernel, a Mach derivative with BSD POSIX environment with traditional POSIX processes, ipc, filesystems, and networking.
* iOS implements runtime security by process/user-id separation and ACLs on system and inter-process APIs. The ReplayKit uses a similar idea by giving an app a handle on a single recording session, but it's implemented on top of the POSIX framework. For contacts it's clearly ACL based and either an app has access to all contacts or none whereas a capability system would allow a particular form of access to a single contact.
Capability systems are implemented by a kernel enforcing capabilities as the sole method of interacting with other objects in the system. There is no generic open(), connect(), read(), or listen() although there are similar methods on certain capabilities processes can hold.
For example, the user could provably give one contact to an app which was further allowed to share that contact with a third app under certain circumstances e.g. "schedule a call to Mom next Thursday" which would involve granting a scheduling app a capability to initiate a phone call but only to the number in the particular contact within a certain time window, by granting a re-grantable capability to the phone
number (and maybe display name) subfield(s) of the Mom contact, which the scheduler would hand off to the phone dialer at the desired time. This is a mildly contrived example because of the complexity of generating the specific capabilities necessary to accomplish it, but it should give an example of what is possible to do securely with a capability system that would be difficult or impossible with traditional ACLs.
I'm not sure how things are implemented on the OS level, but the high-level view from an app developer is this:
Apps are heavily sandboxed on the app bundle level. Any code that's installed from the App Store in an app bundle has no way to access the filesystem outside of its sandbox. There is no "access the file system" permission like on Android or on desktop OSes.
Inter-app communication is extremely limited. There is no way for an app to launch a process in another app bundle. When you open a file from the system Files app, your app gets access to that file only.
There is a small handful of high-level APIs that allow inter-app communication, including a URL handler, and a "share this file" dialog box, where you give the OS a file URL and the OS lets the user pick another app and the OS grants access to only that file to the other app. There are also some very narrowly-defined APIs for audio plugin-type data stream integration (which is gated by App Store approval)
There is no OS-mediated way to share live objects (you can share objects, but the receiving app just gets a copy of the state of it at the time of sharing)
For the OS-managed databases (photos, contacts, music etc), the exposed APIs vary wildly in how they manage permission
> Although the real problem today is that we need to run programs with less authority than the user running them,
All true; But. What really stopped capability systems is that most users cannot be bothered to grant minimum privilege. Even most developers cannot - we invented containers in part as a way to mitigate the consequences of failing to grant minimum privilege.
As the old saying goes, you go to war with the army you have. I have a bunch of fantastic solutions to all our problems, if only programmers would work 10 times harder for every line of code, and the project managers would be OK with that, and the business funding it would be OK with that, and society would be OK with getting 1/10th the software.
Capabilities-based stuff is really neat, but it's also really complicated to put into practice, and I live in a world where it's often a struggle to get developers to label their brand new REST interface for whether or not it's "admin only". Personally, I think a lot of that "really complicated to put into practice" is essential complexity, not incidental; anytime you sit down and really think about what the optimal permissions scheme around any even slightly non-trivial system ought to be, you generally end up with something pretty complicated. But even if the perfect system existed and you handed it to the real developers we have today, you'd still be working with people who would do whatever the simplest thing they could do to fully bypass the capabilities system is and get on with life without a moment's twinge of conscience.
I don't want to be too hard on the average programmer; contra fashionable cynicism, things are actually getting better on the decade time scale. But at the current pace, "capabilities" are probably still a decade or two away from even being "niche".
I wish I could show this to a Big Data analyst I worked with. He spent all day doing machine learning things but once complained to my team that we were making access control too complicated.
>we invented containers in part as a way to mitigate the consequences of failing to grant minimum privilege
Also because it's extremely difficult to grant minimum privilege on your typical general-purpose OS today. Spawn a new process and the default is that it has all the same authority that you do - it takes a lot of work to dial that down.
This is typically inverted in a capability system: the program only has the authority that you give it.
> Capability based security, for example was something that allowed you to run any program, with no danger to your system. It's not part of any common OS. They had it at Xerox PARC, but Steve Jobs chose not to take that part.
For FreeBSD there's Capsicum(1) and for Linux, although the implementation is not strictly capabily-based, there's SE-Linux which depending on the usecase resembles capability-based restrictions.
SE-Linux is the worst possible way to secure a linux system, its like when Microsoft went overboard on warnings, instead of actually trying to solve the problem.
The main implementation difference in a capability based system is using a PowerBox to select files to give to a process, instead of letting the process access everything the user has rights to.
The Burroughs mentioned by Knuth, already had tagged memory, a systems programming language with unsafe code blocks, co-routines, bounds checking, the whole package, Go like compile speed (for 1961 hardware), compiler intrisics instead of Assembly, the whole package.
Nowadays still available as Unisys ClearPath MCP, with high level security as selling point, while it will take generations to fix UNIX and C's adoption at large, if ever.
When you someone performs surgery on one patient, the legacy medical impacts of that surgery are contained to at most 2 people and their immediate families. There will probably be fewer than 10 surgeries where someone might think about that -- and we don't begrudge a surgeon who doesn't.
When you add a commit to an OS, the legacy impact of that stays with the OS and must be un-done by anyone who changes it.
I find the comparison between medicine and computer science very interesting! I have never thought about it this way.
Could you elaborate on how you „dig back“? Do you read old papers / books? I imagine that one would have to dig through much old stuff that just isn‘t interesting until you find something that could be really usefull (like capability based security).
Look at the recent talks by Alan Kay, Ted Nelson, Joe Armstrong on YouTube. Watch "The Mother of all Demos" by Douglass Engelbart.
There is a lot of stuff online, just follow the threads. I've been pushing Capability Based Security for a decade... only in the last 6 hours did I learn that they had it at Xerox PARC, in an offhanded comment by Ted Nelson at the end of one of his videos, where he mentions the great ideas that got away.
One of my favorite talks by Joe Armstrong -- computer science, a guide for the perplexed. He talks through what he feels are some important but forgotten ideas in CS
Well, better in some sense: they might be cleaner, or more robust on some axis, but perhaps not practical or efficient. But, with computing the landscape can change rapidly so it is always good to see if older ideas can now be made a reality.
"The limitation of a single desktop was put in place to allow children to ease into the desktop metaphor." Any source for this? I dont thinkchildren were the target customers at that time.
I agree. But I am wondering, I remember linux had a lot of multiple Desktops, but somehow this fad never stuck. So maybe one Desktop was somehow a good idea?
I'm not sure fad is the right descriptor here. Unix WMs have had virtual desktops since the 90s (80s?), MacOS got them around 2006 and Windows in 2015.
Use by the non-initiated may not be that high, but that shouldn't be surprising given that user education is a very scarce resource and it's being spent elsewhere.
Aren't document tabs, eg browser tabs, an app-confined version of multiple desktops. The idea behind their are virtual screens of content you can switch between.
Every KDE I've installed (Slackware, Mandrake, Ubuntu, Fedora), to my recollection defaulted to multiple desktops.
I'm so happy Win10 has virtual desktops as in moving from Linux to MS Windows - mandated by my workplace - that was a massive pain point.
> Capability based security … allowed you to run any program, with no danger to your system.
‘No danger to your system’ shouldn't be conflated with ‘no danger to you.’ The problem with capabilities is that they reinforce and solidify the ‘smartphone model’: your data isn't yours, it's an app's, so what you're permitted to do with it is entirely controlled by someone else.
We shouldn't fear ideas just because it could be used to restrict some users of some systems. In the end, there will continue to be a market for less regulated hardware and OSes. Linux and the BSDs, as an end user if you own the system, are still wide open. x86/x64 systems aren't getting more locked down in general, and there's a significant movement toward more open hardware (at least within some niches) with RISC-V.
Something like capability based security would be a godsend for the corporate and enterprise environment compared to what's commonly in place.
See also Bret Victor's talk, "The Future of Programming". The conceit: it's 1973, he describes (with an overhead projector and transparencies) some then-innovative ideas that he hopes will be adopted in the future.
> Capability based security, for example was something that allowed you to run any program, with no danger to your system. It's not part of any common OS.
Basically, haven't we "reinvented" this via "The Eternal Mainframe"? Only now it's called Amazon Web Services?
> They had it at Xerox PARC, but Steve Jobs chose not to take that part.
At least they created Object Pascal and did two OSes with it, and contributed later on to the C++ industry adoption, instead of being yet another C powerhouse cloning UNIX.
> Capability based security, ... They had it at Xerox PARC, but Steve Jobs chose not to take that part.
To be fair:
1) Apple II and Macintoshes were slow
2) and single user
3) and pre-Internet (no networking, even.)
Microsoft also had to make an early choice about what features to add to DOS, particularly networking or multiuser, and networking was chosen to implement first. (Probably because of Novell and other early networking competitors.)
> the PARC focus on replicating paper was a step backwards
"Replicating paper" was resurrected about 10 years ago when everybody was making apps with a UI like books turning pages. There was actually a programmer (Russian name if I receall) who specialized in consulting on that, advising companies on what algorithms to use and how to get the page flipping appearance they wanted. I thought it was pointless but hilarious, as it was totally ornamental.
Capability based security, for example was something that allowed you to run any program, with no danger to your system. It's not part of any common OS. They had it at Xerox PARC, but Steve Jobs chose not to take that part.
On the other hand, the PARC focus on replicating paper was a step backwards from work by Engelbart and others.
The limitation of a single desktop was put in place to allow children to ease into the desktop metaphor... it wasn't meant for adults to be stuck with the training wheels on.
I've been digging back, looking for the ideas we missed... and boy, there are some really powerful tools waiting to be reified in a modern context.