Hacker News new | past | comments | ask | show | jobs | submit login

Well, it very much depends on your definition of "secure". The OWASP top 10 were pretty easy to eliminate entirely with a language that supports static analysis, but we accidentally introduced a couple more:

1. the model made it hard for the developer to know what data was flowing from the server to the client (e.g. are we leaking a secret as part of a closure?)

2. on the web, you can only (mostly) trust the code that's executed on the server, as the client could have been patched to be running arbitrary malicious code, but the syntax of Opa made it very easy to forget that some of the code was living in this client-side warzone, which in turn could lead to serious security vulnerabilities;

3. when you patch code, especially in auxiliary functions, it's easy to lose track of where it's going to be executed, which means that it's easy to accidentally add a secret leak/capability leak.

We tried many things to reduce the problems, and eventually settled on removing most of the intelligence from the slicer, to make it more predictable, and replacing most of the slicer's tier inference with annotations, to make sure that the developers actually paid attention to the decision. I believe that this wasn't sufficient.




thanks, in #3 what is “patch code”?


I mean during a refactoring.

I don't know how much of this applies to Electric Clojure, mind you, that's only my experience from Opa.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: