The Mozilla docs on JavaScript security give a hint of hope that signed scripts will work around the cross-domain script exclusions that all good browsers enforce. But an item at DevArticles.com throws water on the idea:

Signed scripts are primarily useful in an intranet environment; they’re not so useful on the Web in general. To see why this is, consider that even though you can authenticate the origin of a signed script on the Web, there’s still no reason to trust the creator. If you encounter a script signed by your company’s IT department, you can probably trust it without much risk. However, you’d have no reason to think that a party you don’t know—for example, a random company on the Web—is at all trustworthy. So they signed their JavaScript—that doesn’t mean it doesn’t try to do something malicious! And if it did, most users would have no way of knowing.

In short, most browsers will pop up a scary looking security window asking the user what he or she want to do, and the chances of the user hitting the button marked “no, I don’t dare allow cross-domain XMLHTTPRequest calls” are at least 50-50. And, even if they weren’t, who would tolerate that message appearing regularly?

tags: cross domain, cross domain script exclusion, cross domain scripting, internet security, intranet environment, javascript, javascript security, mozilla, security, security components, signed script, signed scripts, web scripting, web security, xdomain, xmlhttprequest

I have plans to apply AJAX to our library catalog but I’m running into a problem where I can’t do XMLHttpRequest events to servers other than the one I loaded the main webpage from. Mozilla calls it the “same origin policy,” everyone else calls it a cross-domain script exclusion, or something like that.

Some Mozilla folks are working on a standard to address the problem, but it could be quite a while before browser support is common enough to build for it.

So Plan A was to use simple AJAX with XMLHTTPRequest. Plan B comes from this crazy suggestion at Apple’s developer site: Remote Scripting with IFRAME. It looks like different functions are subject to different restrictions, so the theory is that a JavaSctript loaded in a page in a hidden IFRAME can call functions from the parent page and do pretty much everything we’ve come to expect of XMLHTTPRequest. Here’s an example they offer.

Crazy as it is it works, and it gets around some cross-domain script exclusions for some browsers, but it still gets trapped by Mozilla.

tags: ajax, apple, browser security, browsers, cross domain, cross domain script exclusion, frustration, iframe, javascript, mozilla, remote scripting, web application, web applications, xdomain, xmlhttprequest