It's actually a reason why we went down the 'create your own language for operators' path - we originally wrote our operators in C++, but when we shifted to the browser it was clear that wasn't going to go well :) We looked at sand-boxing, but given how long the NaCl guys took to get it working, we really didn't want to take that on as a start-up. We also wanted something that a web developer would be comfortable working with - so we looked at JS and decided we could create a variant for performance.
We don't give pointers, and we do things client-side like guarded arrays (not necessary on the server). Memory management is handled by the core. I will get our guys to put a post up that covers KL in more detail - security was a major consideration for us.
While I have you here :) , can you please elaborate on your Bullet/Fabric demo? Specifically, how did you get the Bullet C++ code to run on the Fabric Engine? (Since that doesn't use C++?)
Right - they have to be 'trusted', much like a plugin. People will have to explicitly choose to install them. Right now we bundle them all in he plugin, but that's just until we write the manager
Makes sense about portability, but what is your security model? Are you using static analysis, sandboxing like NaCl, or something else?