Hacker News Reader

Comment by masterj | Hacker News Reader

I suspect capability models are going to get more popular https://en.wikipedia.org/wiki/Capability-based_security

I'm doing some work in this space[1], it's a really deep and hairy problem. There's a lot that you can do at the OS level sand boxing of course, but you may want some areas of you code to have network access and for some areas that use external dependencies to not have that access. Tracking where systems have side effects ends up being a lot of book keeping and a lot of languages that implement an object-capability model require you to thread caps through all of your calls, which IMO is bad ergonomics and a place where bugs creep in as functions accrue caps. Or sometimes they have rather superficial cap systems like Hack, or are rather awkward like in Deno.

[1] https://march-lang.org/docs/capabilities

That's a really interesting project! Being able to assert more, statically, about what our software is doing seems like a real growing need

Thank you, I really appreciate that. I'm really trying to make it easy to assert what code can do, then enforce it at compile time and optionally via the build tool at runtime via OS sandboxing integration. Supply chain attacks are also an area I'm exploring by having deps declare caps and then the build can scan and inspect binaries.

It's been a real education. I talked to one of the people behind Caja and learned a lot.

Why do you invent a new language for your work?

Why did you not embed your language into another one, with type system that is superset of what you need?

For example, there's capabilities expressed in Haskell: https://github.com/tweag/capability

Capabilities there are tracked at type level and are subject to type erasure, if possible.

I'll blow my own trumpet and promote my own Haskell capabilities library, Bluefin: https://hackage.haskell.org/package/bluefin

Bluefin is used in production, and as far as I know capability is not.

That looks really cool. Can you narrow Bluefin.IO to reads/writes separately? One of the things I've worked on is the ability to allow code to read files, even specific files, but deny writes.

Yeah you can write a capability that encapsulates exactly whatever effects that you like!

Did this start as an effect system and then capabilities shook out naturally?

Yes! It started as an implementation of the effect system I always wanted: effects passed on the value level, rather than implicitly on the type level. Once I'd done that I realise that it was actually a capability system (and that was the better way of describing it, because more people already know what a "capability system" is).

That’s not surprising there’s a lot of mechanical overlap between the two. It’s a really interesting relationship.

Yeah, I think they're basically identical concepts. I'm writing an article on that topic right now.

I’d love to read it!

Here you go! It's a complete document, but I'll continue to edit it over the next few days before I announce it. I'd love to hear any thoughts you have.

https://h2.jaguarpaw.co.uk/posts/bluefin-capability-system/

Awesome, I'll take a look and shoot you an email if I have anything interesting to say about it.

Cool, my contact details are on the front page of that site.

There are a few reasons for this. I really can't seem to wrap my head around Haskell in the wild as written by real people. I also wanted to tie capabilities into the build system tooling so that the build tool could verify caps and launch executables into an OS sandbox. Bolting on capabilities doesn't offer the same ability to enforce them, for example the March package manager ForgePM will reject packages that falsify their cap manifest. Moreover I was reading some papers that inspired the language, and wanted to try it. Cap(X) is also erased b the type checker during compilation in March.

Reply on news.ycombinator.com