ES Native Mode proposal

Aymeric Vitte vitteaymeric at
Thu Sep 26 02:11:40 PDT 2013

I have just commented the "Safe, closure-free..." thread, and gave some 
thoughts about CSP, as mentioned I have some hard time understanding 
what it does protect, there is no mechanism for setting independently 
script authorities, see the example I provided and the responses I got.

For those interested I provided in the CSP thread a link to a FF bug 
report where it's explained how some security policy (here Websocket 
spec) forces me to do insecure things. I don't know what list can take 
care of it, there is a discussion in [1] too, for now I did not see 
really solid arguments showing that I could be wrong.

Maybe a solution could be combination of CSP and SES, I think SES should 
come now, as far as I remember it is planned for ES8, seems too late.

Solving the code loading issue is indeed the key point, but is it feasible?




Le 26/09/2013 10:22, David Bruant a écrit :
> Le 26/09/2013 09:10, Aymeric Vitte a écrit :
>> There are other cases, like malicious code injection.
> CSP goes a long long way in preventing these.
>> 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.
> In environments where you don't have the option of freezing all 
> built-ins, running your code first allows you to keep a reference to 
> the initial XMLHttpRequest.
> You may then wonder: "how can I enforce running first?"
> => If you're in control of the webpage, it really is up to you to run 
> trusted code *before* any other scripts. If you're building a library 
> other will include at any point in time they want, hope for a standard 
> environment, expect nothing.
>> And something that prevents a bad script to do something like 
>> setTimeout(change_globals,xxx)
> The problem here is exactly the same problem than viruses.
> The only reason viruses exist at all is the design mistake that led 
> operating systems to consider than programs you (human being) start, 
> run with the same authority than you. Indeed, any program you run can 
> throw away all your files, send them over the network to whatever 
> server, etc. Hence viruses.
> Seriously, how did we end up in a world where Windows Vista (and 
> later? I've stopped Windows) think it's a good idea to ask for a 
> confirmation pretty much after any click where could would be run? If 
> Windows has a way to know the second click is secure, how much harder 
> is it to make sure the *first* click is secure!! This is insane!
> Related is this interesting talk:
> "The SkyNet Virus - Why it is Unstoppable; How to Stop it"
> It's old and low-quality (video, not content), but it's really good.
> In my opinion, the good question isn't "how to prevent a bad script to 
> do something like ...?", but rather "how can I make sure that scripts, 
> any script, can be loaded only with the authority it needs?". How did 
> the bad script you're talking about above ended up with the authority 
> to change globals?
> CSP is a good start and says "don't run scripts that aren't 
> whitelisted". You prevent scripts you haven't chosen to run at all. 
> For sure, they won't change globals.
> Caja and Module loader allow to run partially trusted code with 
> fine-grain (object-level) control of the exact amount of authority you 
> want.
> In any case, the problem starts (and likely ends) with how code is 
> loaded. When this problem is solved (and I think it pretty much is 
> with CSP and Caja/Module Loader), then most script-related security 
> problems are solveable.
> David

Peersm :
node-Tor :
GitHub :

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list