Hi Arun, This looks like a promising direction to me. At OpenAjax Alliance, there is a lot of interest from security-minded folks for something like this ([1]). On our wiki, various people made suggestions about how to address these sorts of issues, but each of the previous proposals did not seem to address the problem at a more fundamental level. The Mozilla approach looks much better than the others, although I'll bet there are lots of issues to work through.
One question that comes up right away: Is there a reason why the whitelist information is available only via HTTP headers (versus markup)? So that the info doesn't appear in View Source? (But wouldn't it still be viewable via Firebug?) Jon [1] http://www.openajax.org/runtime/wiki/Better_Security_for_Cross-site_Scripts Arun Ranganathan <[EMAIL PROTECTED] > To Sent by: public-webapps@w3.org, public-webapps-re [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] cc 07/03/08 12:49 PM Subject Cross-Site Requests, Users, UI (and What We're Trying to Fix) Please respond to [EMAIL PROTECTED] All, At the recent F2F discussions in Redmond covering XMLHttpRequest (Level 2) and Access Control, the question of user involvement came up more than once. This discussion raised issues about whether or not the user should be informed by a user interface mechanism in the browser that a cross-site request was taking place. In general, discussion about *notifying the user* is part of a larger discussion about enabling sites to exchange *user-private data* via browser-based APIs such as postMessage and XMLHttpRequest with Access Control. Within Mozilla, we had several discussions about private data exchanges and the pros and cons of a user notification mechanism. Opinions within Mozilla vary. Often, given the nature of our open community and open participation model, we have to agree to disagree. Some hold the opinion that obtaining private data through a cross-site transaction, even with a mitigation mechanism such as Access Control, creates security or privacy scenarios that are unfavorable to end users. These same parties hold that at the very least, the user should have a user interface mechanism to stop the transaction. Others, including myself, hold the opinion that it is better to fundamentally *improve* existing cross-site access mechanisms, which certainly do not inform the user today [1], and to encourage developers to use safer APIs to build applications that engage in cross-site transactions. Moreover, it is desirable to introduce a mechanism that allows for "stricter" script inclusion, including inline scripts and maintaining lists of domains that are safe to script scr="" from [2]. The way forward might be to: 1. introduce new mechanisms to do what developers do already[1], but allow them to be done safer, and to 2. "clean up" unsafe legacy mechanisms[2] as best as possible. While user interface mechanisms may help to generally inform the user and customize their web experience (e.g. stopping third party Cookies, etc.), "STOP | CONTINUE" type messages affiliated with APIs such as XMLHttpRequest (with AC) may be misleading in this context, since sites that wish to exchange data can use any number of mechanisms[1] on the web today and not inform the user. Of course, it is generally good behavior for sites that store user-private data to have privacy policies and inform the user about any sharing with other sites. -- A* [1] A (Not Exhaustive) Listing of Cross Site Mechanisms: http://www.arunranga.com/articles/browser-cross-site.html [2] Straw Person Proposal for Site Security Policy: http://people.mozilla.com/~bsterne/site-security-policy/
<<inline: graycol.gif>>
<<inline: pic29544.gif>>
<<inline: ecblank.gif>>
