Comment by mikewarot | Hacker News Reader

Comment by mikewarot | Hacker News Reader

Parent Full thread

Windows, MacOS, Linux are all dead men walking. They are all unfit for purpose in a world of persistent internet and mobile code. You can't ever fix them.

Capability Based Security is about 50 years old. It was getting added to MULTICS when UNIX took off. Fuchsia, Genode and GNU Hurd are all based on it. None of them are ready for use yet.

When you open an application, and pick a file to edit, the application is using a dialog box get your file choice. It then directly accesses the file. There is nothing enforcing your choice, we all just hope the program works as intended.

When you do the same thing in a capability systems, the operating system is using its own dialog box to get your file choice. The operating system then enforces your choice, and gives a capability for only that one file to the application. Your application has zero permissions to access anything else.

I hope I've made it clear why the rush to capability based systems is on.

Bryan doesn't see the bigger picture, but he has quite valid points anyway. It's not just old code, it's the broken model underneath it.

There is a race to get something usable to market. I hope something open-source wins.

Not sure if capability based access is indeed the future. If mobile OS are an example, I don't think too many people would like that actually.

OS are often pronounced dead. Maybe they won't be as relevant as today, but even that is questionable.

Same with programming languages. C is dead and it died many deaths. Javascript is also dead.

I worked with mobile code, also with the serverless kind. That certainly is not the future. No, sir, it isn't. MacOS may be the most endangered here, but even that is currently unlikely. Because there actually isn't a use case they cannot offer.

UWP on Windows was capability based. Not an OS, but the same principles applied. It was heavily restricted. It is also basically dead. But really dead, not like C or Javascript...

>If mobile OS are an example

Nope, not even close... those are not capability based systems. They are regular systems with with some access flags bolted on top.

Agreed 100%, I've been saying this for a few months now ever since I started reading the Fuchsia docs. It's very obvious that no sane business would continue to build anything on top of what is essentially the duct tape of today's operating systems if given a sensible opportunity.

I fully expect that that this isn't going to be a strictly consumer phone / desktop OS thing, I expect that servers might even end up as some early adopters depending on what the roll out ends up looking like.

When I looked at their application delivery section of their docs, it seemed very likely to me that I was looking at an entirely new app layer of the web in general.

Capsicum shows that the capability model can be practically implemented within Unix, ignoring bugs (i.e. ignoring monolithic vs microkernel consequences). But the poor uptake of Capsicum and the popularity of Docker also show how impractical it is for the current ecosystem of software, even though conceptually it should be a relatively easy shift. It's far easier to enforce and adopt in the context of smartphones and IoT, where APIs are already highly restricted. But these restrictions also reflect a substantially limited capacity to innovate--only the platform provider can innovate locally; everybody else has to treat the environment as a dumb terminal with accelerated graphics. Even the underlying capability frameworks are largely hidden; capabilities are an implementation detail of the exposed APIs from the perspective of the application--unless the application developer is also the platform developer like with Google and Chrome.

> But these restrictions also reflect a substantially limited capacity to innovate

They also break already existing applications and workflows – there are e.g. quite a few file formats around that don't work with the "pick a single file and that's all you can access without pestering the user once more" model: - separately stored subtitles (media players currently automatically look for those when opening a video, but with strictly sandboxed file access that would no longer work) - playlists (opening a playlist should likely implicitly allow that application to also access all the files referenced therein, but of course the OS can't be expected to understand each and every filetypes intricacies) - multi-part videos - multi-part archives - HTML documents with links to other documents and/or separately stored resources (media files/CSS/JS) - any other kind of multi-file file format

Along the same lines, download manager extensions in Firefox have become semi-useless since the switch to webextensions, because there's no way to download multiple files elsewhere than the OS downloads folder without asking the user for each and every file.

Windows has had a similar problem with UWP (which is based on a rudimentary capability system and implements the file dialog powerbox pattern outlined in mikewarot's post)

That's not strictly a good example. In Linux you can do that with mount namespaces, but the GUI around it is not there yet -- the capability system has to be implemented in user space, which I will say is definitely more difficult than just having a nice capability primitive built into the OS...

I don't think you need a full object-capability security implementation to get the specific file dialog/powerbox pattern you outlined. Windows (in UWP), MacOS and I think Linux all support it, albeit with a more ad hoc implementation.

Flatpak achieved this on Linux. There are "portals" which are dispatched and will mount virtual filesystems to permit access to specific files selected by the user. These portals typically are provided by the desktop environment as to resemble to look and feel of the user's choice. There's no kernel-level interface as the OP was alluding to but by combining several other kernel interfaces we can get this kind of sandboxing.

Reply on news.ycombinator.com