Make masked globals completely gone? (i.e. ReferenceError)

[natevw]

Right now there's a difference between evel('XMLHttpRequest') and evel('XMLHttpRequesy') [sic] — the former returns undefined while the latter throws a ReferenceError.

I suspect the only way to do that would be to delete every "local" variable, but that's not allowed in strict mode (and I'm not sure it'd work anyway).

BUT

If we can, somehow, it'd be cool!

c.f. http://perfectionkills.com/understanding-delete/#undeclared_assignments

[kumavis]

I'm on fire tonight:

SetIllegalReference(window,'XMLHttpRequest')
XMLHttpRequest
//=> ReferenceError: XMLHttpRequest is not defined

function SetIllegalReference(ctx, refName) {
  Object.defineProperty(ctx, refName, {
    get: function() { throw new ReferenceError(refName+' is not defined') }
  });
}

Note: not fully tested. some strange behaviour e.g.:

window.XMLHttpRequest
//=> ReferenceError: XMLHttpRequest is not defined
window.XMLHttpRequesy //[sic]
//=> undefined

Ironically the opposite behaviour as @natevw noted above. Though that should be fine for our usecase b/c the user doesn't have direct access to the iframe global

[natevw]

That could work, but if it's letting you redefine those kind of globals, in general now that the iframe is there (and most likely to stay!) it might actually be good to simply clean up (i.e. delete) as many window properties as the environment allows to be configured. Not sure what the actual performance improvement might be, but would clean up some of these things and reduce the number of the crazy wrapper function's parameters.

[kumavis]

This makes me think - why are we obscuring the iframe globals at all? its access to top that we're really worried about. The iframe global is thrown away after each evel. The iframe global primitives like Function aren't shared with the top global primatives. Instead of 'allow-same-origin', a so-called 'null-origin' iframe protects top from references from the iframe. article: http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ demo: http://www.html5rocks.com/static/demos/evalbox/index.html throw this in the demo: window.top.document.body.innerHTML.length

// in un-sandboxed iframe
window.top.document.body.innerHTML.length
//=> 2560
// in sandboxed iframe
window.top.document.body.innerHTML.length
//=> SecurityError: Blocked a frame with origin "null" from accessing a cross-origin frame.

[kumavis]

maybe null-origin iframes require message passing and are thus not synchronous ?

[natevw]

I was after a complete container, i.e. no access to outside world via XHR/JSONP/form/img/etc. And yeah, you probably need async cross-window messaging if the origins aren't the same.

If you can live with async then there are a whole host of possibilities (anything from a worker to sending the code to a server for execution) so I'm not terribly interested in that case.