- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 26 Feb 2008 02:16:50 -0800
- To: Collin Jackson <collinj@cs.stanford.edu>
- Cc: Anne van Kesteren <annevk@opera.com>, Adam Barth <abarth@cs.stanford.edu>, public-appformats@w3.org
Collin Jackson wrote: > It would be helpful to include some discussion of mixed content > handling for cross-site requests, perhaps in the Security > Considerations section. > > Mixed content warnings are typically issued by browsers when an HTTPS > page issues a request for some non-HTTPS content, e.g. <script > src="http://some.site/foo.js"></script>. When a web site tries to make > a cross-site XMLHttpRequest from an HTTPS page to a non-HTTPS page, > several user agent behaviors are possible: > 1) Block the request > 2) Treat the request as "mixed content" and display a warning in the > user interface if appropriate > 3) Allow the request > > If the site is careless, non-HTTPS requests could compromise the > integrity of the user's session. For example, a site could make a > cross-site XMLHttpRequest to itself over a plain HTTP connection and > inject that content into its page without validating it. However, > certain types of non-HTTPS requests may be safe for HTTPS pages. For > example, if the site is already doing client-side hashing to verify > the integrity of the received content, it may be safe and efficient to > make the request over plain HTTP instead of HTTPS. > > Currently, Firefox seems to be implementing (3). Is this behavior by > design? Do other implementors plan to match this behavior? I think in general a UA should warn the user that a connection is about to be made over a non-https connection and give the user the option to abort the request. This should apply equally to all requests, from CSS stylesheets and plugins to xmlhttprequests and iframes. Though I could definitely see a point in allowing this to be configurable, so that for example the default behavior is to simply change the "lock icon", but have the option to ask the user any time such a request happens. The reason firefox doesn't do this is simply that we don't have a good enough code architecture that we can do that. So it's not by design, but rather by the lack of being able to do better. Not sure if this needs to be mentioned in the access-control spec, but it doesn't hurt I suppose. In general I don't think these requests should be treated any differently from any other requests though. / Jonas
Received on Tuesday, 26 February 2008 10:17:25 UTC