On Wed, Jun 20, 2018 at 9:52 PM doodad-js Admin <[email protected]> wrote:
> Thanks > > > > *How can we discuss your idea separately from the library?* > > > > I’m more thinking at the runtime level than at the “user land”. To be > honest, I don’t care of “safeEval” on “user land”. > You seem to be asking for criticism, but seem to not want criticism of the only thing that has enough detail for criticism. > *You talk about options and ACLs but the only hint as to what those might > mean is the library* > > *How would the idea work if not by tree filtering? AdSAFE did that but > writing AdSAFE was very different from writing vanilla JS.* > > > > Yeah, sorry. The purpose is to offer something like “opcode” filtering, > but in a more expressive and user-friendly way. > EcmaScript is specified as a tree interpreter that produces completion records, not in terms of an ISA. The spec does not define opcodes, and you've provided no reason to believe that opcode filtering would provide a better balance between security and ease of writing than AST filtering. Having written a JS sandbox, I'm skeptical that either approach would work. All successful approaches have combined static analysis with at least 2 of 1. large dedicated runtime libraries, 2. source code rewriting, and 3. separation/isolation via realm/origin/worker. Any pair of these are going to require detailed correctness arguments to pass muster. I don't see how we could compare the benefits of your proposal to any other without a lot more detail.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
