
Continuations for web programming; Capabilities for security. False promise? - theoh
Looking at the limited success of capability-based security, and also at the perhaps limited actual utility of the neat &quot;continuation-based web service&quot; concept, I&#x27;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&#x27;t quite solve the whole problem? Discuss...
======
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/](https://www.cl.cam.ac.uk/research/security/capsicum/)

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

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

[3]: [https://capnproto.org/](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.

------
nikolay
Continuations are great. I'm so sad Seaside [0] didn't pick up!

[0]: [http://seaside.st/](http://seaside.st/)

