ES Native Mode proposal

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Sep 25 16:16:08 PDT 2013


I think is not ... or at least is not real-world possibility. We have two
scenarios:

  1. you know what you include
  2. you are the library included

In first case you don't need anything because you know the code and you
know no script will hurt so you can even do whatever you want with natives
... who cares if that's convenient for you, why not.

The second case you might arrive too early, so no other library could work
in a frozen env, or too late, the env has been already modified you can
freeze it and live in troubles for you and other scripts.

I am usually the guy living in the first case .. with as less external
dependencies as possible and where code is OK even if extended in a
reasonable way but I don't think there is a reasonable solution for the
second case.

Once again we all trid in the past and failed for usability, performance,
not so secured env ... etc etc ...

As summary if you have a party in your house ... you better know your
guests :D





On Wed, Sep 25, 2013 at 3:48 PM, Aymeric Vitte <vitteaymeric at gmail.com>wrote:

> It's not easy to freeze the world like Caja is doing, and it's not easy to
> have a library that takes care of it securely, and the use case is not
> always to use modules to have a fresh global.
>
> Some years ago, doing widgets stuff inside web pages, I had a
> "RestoreNativeVar" function restoring natives using strange hooks like
> taking them from iframes (no comments...)
>
> The issue is probably not TC39 only, but looking at W3C security groups
> specs which apparently have some hard time defining something secure, maybe
> SES concepts are coming late in the TC39 schedule, all new Web API define
> more globals, this is usefull to have something that freezes the entire
> global when you need it instead of hacking around.
>
> Regards,
>
> Aymeric
>
> Le 25/09/2013 23:50, David Bruant a écrit :
>
>  Le 25/09/2013 17:41, Michaël Rouges a écrit :
>>
>>> Hi all,
>>>
>>> Given the number of scripts from various sources that may be contained
>>> in a web page, there may be prototypingconflicts.
>>>
>> Be careful about what you include? To be proactive in that process,
>> freeze all builtins beforehand. You'll know soon enough if something breaks.
>> If you do want to enhance prototype, isolate this code and run it before
>> freezing builtins.
>>
>> The module loader API has something close to what you ask:
>> http://wiki.ecmascript.org/**doku.php?id=harmony:module_**
>> loaders#loader.prototype.**definebuiltins_obj<http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders#loader.prototype.definebuiltins_obj>
>>
>> David
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
> --
> Peersm : http://www.peersm.com
> node-Tor : https://www.github.com/Ayms/**node-Tor<https://www.github.com/Ayms/node-Tor>
> GitHub : https://www.github.com/Ayms
>
>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130925/8d89d0df/attachment-0001.html>


More information about the es-discuss mailing list