Re: Proxies as prototypes
Le 23/11/2014 07:41, Axel Rauschmayer a écrit : I’d expect the following code to log `GET bla`, but it currently doesn’t in Firefox. That’s because the Firefox implementation of proxies isn’t finished yet, right? Yes. That would be https://bugzilla.mozilla.org/show_bug.cgi?id=914314 I think. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Eval, literal eval, safe eval
Introdution: - eval executes piece of code - eval can not be safely used with external input - Python's ast.literal_eval would be almost useless in modern JavaScript (almost all data types can be easily send as JSON) literal_eval description: The string or node provided may only consist of the following Python literal structures: strings, numbers, tuples, lists, dicts, booleans, and None. My proposition is safe eval. Safe eval ( eval.safe(string: code, callback) ) should perform theses steps: - Create isolated realm without capabilities to perform almost any IO (implementation dependant - no XHR, no importScript, no require) - evaluate code in context of created realm - post result of last evaluated expression back to creator realm using structured-clone algorithm - call callback with returned data Pros: + sandbox offered by language + easy to run in other thread + quite easy to polyfill + servers can send computations to users + Cons: - Realm creation can be costly (but implementations can solve this problem in many ways) - proposal does not include support for asynchronous operations ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Eval, literal eval, safe eval
On Sun, Nov 23, 2014 at 12:27 PM, Michał Wadas michalwa...@gmail.com
wrote:
literal_eval description:
The string or node provided may only consist of the following Python
literal structures: strings, numbers, tuples, lists, dicts, booleans, and
None.
Also known as JSON.parse.
My proposition is safe eval.
Safe eval ( eval.safe(string: code, callback) ) should perform theses
steps:
- Create isolated realm without capabilities to perform almost any IO
(implementation dependant - no XHR, no importScript, no require)
- evaluate code in context of created realm
- post result of last evaluated expression back to creator realm using
structured-clone algorithm
- call callback with returned data
Pros:
+ sandbox offered by language
+ easy to run in other thread
+ quite easy to polyfill
+ servers can send computations to users
+
Cons:
- Realm creation can be costly (but implementations can solve this
problem in many ways)
- proposal does not include support for asynchronous operations
evalSandboxed would perhaps be a better term.
Btw. you can do a sort of sandboxed eval today by overriding all names
found in window. There are some caveats however. The so sandboxed code can
still access (and change) object internals, such as
mystring.constructor.prototype.asdf = function(){ console.log(gotcha);
}.
A sandboxes primary purpose isn't just to restrict access to global
symbols, it's also to prevent it from corrupting the surrounding codes
internals. One way to do that of course would be to have the so sandboxed
code run in total isolation on a separate VM instance, however there's some
issues with that too.
It would often be the case that you'd want to provide an interface to the
sandboxed code. So sandboxing alone isn't quite sufficient, you'd also need
to have a suitable API/syntax to describe interfaces, safe to pass to the
sandboxed code, such that the sanboxed code cannot corrupt any piece of
those interfaces.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Retrieving generator references
23.11.2014, 07:03, "Brendan Eich" bren...@mozilla.org:Axel Rauschmayer wrote: As an aside, I still feel that two concerns are mixed in a generator function: * The creation of the generator object. This is where the generator function is like a constructor and where you’d expect `this` to refer to the generator object.Nope, not a constructor (and if you don't call with 'new', what is 'this', pray tell?).Hmm... Interestingly, in Chrome if you do call it with 'new', 'this' would refer to a generator itself. But not in FireFox. I'm playing around with this example: ```function *G() { console.log(this === x) yield 1 console.log(this === x)} x = new G()x.next()x.next()``` Shows "true, true" for V8 and "false, false" for FF engine. ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proxies as prototypes
On Sun, Nov 23, 2014 at 11:58 AM, David Bruant bruan...@gmail.com wrote: Le 23/11/2014 07:41, Axel Rauschmayer a écrit : I’d expect the following code to log `GET bla`, but it currently doesn’t in Firefox. That’s because the Firefox implementation of proxies isn’t finished yet, right? Yes. That would be https://bugzilla.mozilla.org/show_bug.cgi?id=914314 I think. Correct, that's a known bug. Jason and Eric (CC'd) are working on fixes to our MOP and Proxy implementation and I'd guess that this'll be fixed soon-ish. As pointed out in the bug, you can work around it by also implementing a [[Has]] handler. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxies as prototypes
On 23 Nov 2014, at 13:39, Till Schneidereit t...@tillschneidereit.net wrote: On Sun, Nov 23, 2014 at 11:58 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Le 23/11/2014 07:41, Axel Rauschmayer a écrit : I’d expect the following code to log `GET bla`, but it currently doesn’t in Firefox. That’s because the Firefox implementation of proxies isn’t finished yet, right? Yes. That would be https://bugzilla.mozilla.org/show_bug.cgi?id=914314 https://bugzilla.mozilla.org/show_bug.cgi?id=914314 I think. Correct, that's a known bug. Jason and Eric (CC'd) are working on fixes to our MOP and Proxy implementation and I'd guess that this'll be fixed soon-ish. As pointed out in the bug, you can work around it by also implementing a [[Has]] handler. Thanks David and Till! I’ve only recently become fully aware of how much work that is, because proxies expose so much of the MOP (especially when it comes to getting and setting properties). With a proxy that logs when traps are triggered, you can see that auto-expansion in the Firefox console already triggers `ownKeys`, which is nice. I’m looking forward to `Reflect` being available in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=987514 https://bugzilla.mozilla.org/show_bug.cgi?id=987514 As you probably know, this is a polyfill: https://github.com/tvcutsem/harmony-reflect Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Eval, literal eval, safe eval
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/ http://research.google.com/pubs/pub40673.html https://code.google.com/p/google-caja/wiki/SES www-cs-students.stanford.edu/~ataly/Papers/sp11.pdf http://wiki.ecmascript.org/doku.php?id=strawman:concurrency desperately needs updating in light of modern promises, but see discussion of Vats and there. On Sun, Nov 23, 2014 at 3:27 AM, Michał Wadas michalwa...@gmail.com wrote: Introdution: - eval executes piece of code - eval can not be safely used with external input - Python's ast.literal_eval would be almost useless in modern JavaScript (almost all data types can be easily send as JSON) literal_eval description: The string or node provided may only consist of the following Python literal structures: strings, numbers, tuples, lists, dicts, booleans, and None. My proposition is safe eval. Safe eval ( eval.safe(string: code, callback) ) should perform theses steps: - Create isolated realm without capabilities to perform almost any IO (implementation dependant - no XHR, no importScript, no require) y - evaluate code in context of created realm y - post result of last evaluated expression back to creator realm using structured-clone algorithm n. Structured clone sucks. - call callback with returned data Prefer promises to callbacks Pros: + sandbox offered by language y. Plan is to refine Realm API for ES7 by trying to redo SES in terms of Vats. + easy to run in other thread y + quite easy to polyfill Well, it wasn't as easy as I first expected, but we do have a SES polyfill. Not yet for Vats or Dr. SES + servers can send computations to users y + Cons: - Realm creation can be costly (but implementations can solve this problem in many ways) y - proposal does not include support for asynchronous operations Dr. SES does. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Eval, literal eval, safe eval
On Sun, Nov 23, 2014 at 3:38 AM, Florian Bösch pya...@gmail.com wrote:
On Sun, Nov 23, 2014 at 12:27 PM, Michał Wadas michalwa...@gmail.com
wrote:
literal_eval description:
The string or node provided may only consist of the following Python
literal structures: strings, numbers, tuples, lists, dicts, booleans, and
None.
Also known as JSON.parse.
My proposition is safe eval.
Safe eval ( eval.safe(string: code, callback) ) should perform theses
steps:
- Create isolated realm without capabilities to perform almost any IO
(implementation dependant - no XHR, no importScript, no require)
- evaluate code in context of created realm
- post result of last evaluated expression back to creator realm using
structured-clone algorithm
- call callback with returned data
Pros:
+ sandbox offered by language
+ easy to run in other thread
+ quite easy to polyfill
+ servers can send computations to users
+
Cons:
- Realm creation can be costly (but implementations can solve this
problem in many ways)
- proposal does not include support for asynchronous operations
evalSandboxed would perhaps be a better term.
SES uses the term confine, as that's what it does -- much better than
sandboxing.
Btw. you can do a sort of sandboxed eval today by overriding all names
found in window. There are some caveats however. The so sandboxed code can
still access (and change) object internals, such as
mystring.constructor.prototype.asdf = function(){ console.log(gotcha);
}.
Not in SES, by use of Object.freeze, etc, to freeze the primordials of the
SES realm on initialization. We have a design and partial implementation
for CES -- Confined EcmaScript, which is like SES except the primordials
are not frozen. As a polyfill, this wasn't worth completing. With Realm API
support, perhaps we'll revisit.
A sandboxes primary purpose isn't just to restrict access to global
symbols, it's also to prevent it from corrupting the surrounding codes
internals.
Among other things, yes.
One way to do that of course would be to have the so sandboxed code run in
total isolation on a separate VM instance, however there's some issues with
that too.
It would often be the case that you'd want to provide an interface to the
sandboxed code. So sandboxing alone isn't quite sufficient, you'd also need
to have a suitable API/syntax to describe interfaces, safe to pass to the
sandboxed code, such that the sanboxed code cannot corrupt any piece of
those interfaces.
See SES.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Eval, literal eval, safe eval
On Sun, Nov 23, 2014 at 8:22 AM, Mark S. Miller erig...@google.com wrote: https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/ http://research.google.com/pubs/pub40673.html https://code.google.com/p/google-caja/wiki/SES www-cs-students.stanford.edu/~ataly/Papers/sp11.pdf http://wiki.ecmascript.org/doku.php?id=strawman:concurrency desperately needs updating in light of modern promises, but see discussion of Vats and there. See also the two talks announced at http://www.eros-os.org/pipermail/cap-talk/2011-November/015079.html On Sun, Nov 23, 2014 at 3:27 AM, Michał Wadas michalwa...@gmail.com wrote: Introdution: - eval executes piece of code - eval can not be safely used with external input - Python's ast.literal_eval would be almost useless in modern JavaScript (almost all data types can be easily send as JSON) literal_eval description: The string or node provided may only consist of the following Python literal structures: strings, numbers, tuples, lists, dicts, booleans, and None. My proposition is safe eval. Safe eval ( eval.safe(string: code, callback) ) should perform theses steps: - Create isolated realm without capabilities to perform almost any IO (implementation dependant - no XHR, no importScript, no require) y - evaluate code in context of created realm y - post result of last evaluated expression back to creator realm using structured-clone algorithm n. Structured clone sucks. - call callback with returned data Prefer promises to callbacks Pros: + sandbox offered by language y. Plan is to refine Realm API for ES7 by trying to redo SES in terms of Vats. + easy to run in other thread y + quite easy to polyfill Well, it wasn't as easy as I first expected, but we do have a SES polyfill. Not yet for Vats or Dr. SES + servers can send computations to users y + Cons: - Realm creation can be costly (but implementations can solve this problem in many ways) y - proposal does not include support for asynchronous operations Dr. SES does. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Retrieving generator references
Thanks all. My intent wasn't to propose that something was necessary, just to ask if something was available that I was missing. I'll dig in on the await spec and take a good look at the various examples everyone provided. Thanks! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
