W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: Cross-Site Requests, Users, UI (and What We're Trying to Fix)

From: Jon Ferraiolo <jferrai@us.ibm.com>
Date: Thu, 3 Jul 2008 15:27:01 -0700
To: arun@mozilla.com
Cc: public-webapps@w3.org, public-webapps-request@w3.org, sunavad@windows.microsoft.com, zhenbin.xu@microsoft.com
Message-ID: <OF6DE24C76.E8F81B37-ON8825747B.007A6D2A-8825747B.007B52F7@us.ibm.com>

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

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



             Arun Ranganathan                                              
             >                                                          To 
             Sent by:                  public-webapps@w3.org,              
             public-webapps-re         sunavad@windows.microsoft.com,      
             quest@w3.org              zhenbin.xu@microsoft.com            
             07/03/08 12:49 PM                                     Subject 
                                       Cross-Site Requests, Users, UI (and 
                                       What We're Trying to Fix)           
             Please respond to                                             


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:
[2] Straw Person Proposal for Site Security Policy:

(image/gif attachment: graycol.gif)

(image/gif attachment: pic29544.gif)

(image/gif attachment: ecblank.gif)

Received on Thursday, 3 July 2008 22:30:19 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC