FW: Proposal: safeEval

[doodad-js Admin]

Thanks,

 

You seem to be asking for criticism, but seem to not want criticism of the only thing that has enough detail for criticism.

 

I was not asking for criticism, I was just submitting an idea (with an opened, non-destructive discussion).

 

The spec does not define opcodes

 

I know

 

you've provided no reason to believe that opcode filtering would provide a better balance between security and ease of writing than AST filtering

 

AST filtering is fragile because every change on the language can break it.

 

 

Claude

 

 

From: Mike Samuel <mikesamuel at gmail.com> 
Sent: Thursday, June 21, 2018 9:04 AM
To: doodadjs at gmail.com
Cc: Isiah Meadows <isiahmeadows at gmail.com>; es-discuss <es-discuss at mozilla.org>
Subject: Re: FW: Proposal: safeEval

 

 

On Wed, Jun 20, 2018 at 9:52 PM doodad-js Admin <doodadjs at gmail.com <mailto:doodadjs at gmail.com> > 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.

 


 <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 

Virus-free.  <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> www.avg.com 

 



---
This email has been checked for viruses by AVG.
https://www.avg.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180622/c93d69b3/attachment.html>