3 ms·
Continuations for web programming; Capabilities for security. False promise?
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...
- nikolay 11y agoContinuations are great. I'm so sad Seaside [0] didn't pick up! [0]: http://seaside.st/ http://seaside.st/
- evancordell 11y agoI 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 11y agoCapabilities 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.