HN Explorer

Continuations for web programming; Capabilities for security. False promise?

2 points by theoh ↗ HN
Looking at the limited success of capability-based security, and also at the perhaps limited actual utility of the neat "continuation-based web service" concept, I'm just wondering if anyone would agree that these are both examples of a simple concept that is initially appealing for its elegance, but actually doesn't quite solve the whole problem? Discuss...

3 comments

[ 3.1 ms ] story [ 19.2 ms ] thread
evancordell
I don't think it's fair to say capability-based security doesn't solve the whole problem. Although it's true they're not nearly as mainstream, projects like Capsicum[0] are still being worked on and discussed, there are modern capability-restricted sandboxes like Caja[1] and the Pony language claims to be capability-secure[2]. Not to mention it's the backbone of Sandstorm's Cap'nProto[3].

[0]: https://www.cl.cam.ac.uk/research/security/capsicum/

[1]: https://developers.google.com/caja/

[2]: http://www.ponylang.org/

[3]: https://capnproto.org/

kentonv
Capabilities are a basic tool that is used all the time in real systems, often by people who don't even know they're using capabilities. Examples of capabilities in the real world include:

- Unix file descriptors.

- The "choose file" dialog used to upload files to web sites.

- CSRF tokens.

- "Anyone with the link can access" aka "unlisted" access control as implemented by many web apps.

- OAuth2 access tokens.

- Google Chrome's sandbox.

- Mac OSX's app sandbox.

- Sandstorm.io's sandbox.

Of course, none of these are "theoretically pure" capabilities, but successful systems are never theoretically pure anything.