Before I dig in too far, I do want to make a note that I did not read the USENIX paper in its entirety. I did a pretty thorough skim, and read the parts that s

Before I dig in too far, I do want to make a note that I did not read the USENIX paper in its entirety. I did a pretty thorough skim, and read the parts that seemed pertinent. On the script server page you are outlining a method to assure that your defensive scripts are only sent to verified requesters. Presumably, this is to ensure that scripts are only loaded into the browser, and only on pages that are intended by the script author. If those goals can be met, any secure data can be encapsulated - effectively securing it from any other malicious JS that might be running on the page. I don't see how such a goal could possibly be completed. Your defensive server code uses the following method to confirm the origin: // Browser origin does not match claimed origin if(getenv('HTTP_ORIGIN') != $org['origin'] || strlen($c = $_POST['challenge']) != 64) { die(header("HTTP/1.1 403 Access denied")); } It is relying on the HTTP_ORIGIN header to confirm that the request is coming from the correct origin. However, like any other HTTP Header, the HTTP_ORIGIN header can be spoofed. Presumably, some malicious javascript could keep an eye out for any scripts called from the defensive server. It could then call home (JSONP?) to a server that spoofs HTTP_ORIGIN, and get a stripped down version of the scripts. The malicious JS would now have access to your secret data. Even all of that is likely over complex. What is stopping the malicious JS from loading the defensive scripts via XHR, stripping out the encapsulation, and then eval()ing it? Again, there's parts of this system that I don't understand, and probably some large mistakes in my logic here. I'd just like to have someone smarter than me point them out :)