Well it's not some huge security risk, though it reveals some potential interference at least.
Suppose we have those very well closed JavaScript modules that is loaded into my page without knowing about each other. They are from "trusted" however some developer in lib2 made a mistake, see the code.
Lib1 http://good.site/libs/the-famous-important-lib1.js
setInterval(function(){
alert('I am doing some important stuff');
}, 1000);
Lib2 http://not-excelent.site/libs/the-cool-lib2.js
var i = setInterval(function(){}, 0);
for(; i >= 0; i-=1) {
clearInterval(i);
}
My HTML
<script src="http://good.site/libs/the-famous-important-lib1.js" type="text/javascript"></script>
<script src="http://not-excelent.site/libs/the-cool-lib2.js" type="text/javascript"></script>
In a browser or at least on Firefox, Loading Lib2 would actually break Lib1 totally. Some might say this is not important, and how silly to make such mistake.
I consider that as a bad behavior. Since we are loading more and more third party libs in our websites. Maybe a proper solution is that setInterval, and setTimeout should return an object to be really unique and un-fakeable, instead of just numeric auto increment ID.
Someone might come up with a real-world exploitation for this (still didn't test if it is cross frames, I doubt it really).
The question is: Is it? And does strict mode in ES5 overcome that?
Does strict mode in es5 overcomes that?
No. setInterval and setTimeout are part of the DOM bindings -- they are not EcmaScript builtins so are not specified in any version of EcmaScript. Nothing in strict mode specifically affects them.
This will probably change in the next version of EcmaScript since the TC39 committee thinks that concurrency is a core language feature that needs to be specified and will probably retain event loop concurrency.
Those changes are unlikely to affect the problem you raise though. Caja / Secure EcmaScript (SES) does make sure that interval and timeout ids are not guessable.