[vvanders]

Pretty awesome stuff, will echo that this is one of the cleanest feature pages I've seen.

I'd love to hear more about your evaluation of Lua. LuaJIT is so blazingly fast(and small!) that I'm sure it'd be some pretty significant compute savings.

What sandbox solutions did you look into? Separate lua states, just overriding ENV/setfenv() or something completely different?

[kentonv]

We love Lua and LuaJIT -- we use them extensively here.

But for running third-party code, we need to everything in our power to reduce the risk of a compromise.

Every sandbox (including V8) has bugs, and security is about risk management. With scrutiny, the low-hanging fruit is found and the risk of further bugs steadily decreases. At the end of the day, no Lua sandboxing mechanism has had anywhere near the scrutiny of V8. It's a totally unfair chicken-and-egg problem: to get scrutiny you need usage, but to get usage you need scrutiny. But, it is what it is. :/

[vvanders]

Cool, appreciate the candid response.

I think there's definitely a compelling reason to use JS both from a developer comfort perspective and the fact that it's a pretty battle-tested path.

It sounds like anything short of a full-blown container(with all the overhead that brings) wouldn't be sufficient to cover the security concerns. I'd love to see Lua battle-harded a bit more in that area so was just curious if you had any new learnings.