There are other cases, like malicious code injection.
I don't know if it's really feasible without redefining the DOM on top
of it but I feel the need since a long time, something that makes sure
you are using the right XMLHttpRequest or other and not a modified one.
And something that prevents a bad script to do something like
setTimeout(change_globals,xxx)
Regards,
Aymeric
Le 26/09/2013 01:16, Andrea Giammarchi a écrit :
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 <[email protected]
<mailto:[email protected]>> 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
David
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
