W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: XMLHttpRequest Object feedback

From: Jim Ley <jim@jibbering.com>
Date: Thu, 6 Apr 2006 22:58:02 +0100
Message-ID: <003d01c659c5$30d03a60$817ba8c0@Snufkin>
To: <public-webapi@w3.org>

"Mark Nottingham" <mnot@mnot.net>
>> >> The Referer header MUST be set, and MUST NOT be overridable; once
>> >> cross-site XHR is available, sites will want to use it for
>> >> security, logging, etc.
>> >
>> > I don't agree with this, a user agent MUST be allowed to anonymise
>> > browsing, tracking users is not a suitable reason for changing this
>> > behaviour.
>
> Referer isn't generally used for user tracking; perhaps you're  thinking 
> of cookies?

referer would be very often used for user tracking, if xmlhttprequest was a 
MUST on send it.

> Many, many sites use the Referer as a first-level defense against 
> content-stealing.

> This works because site B has no control over the Referer that site A 
> sends. It does not work perfectly (you have to account for browsers  that 
> don't send referer), but it works well enough, because third  parties 
> can't control how your browser sends Referer headers. If you  give 
> programmatic control of the Referer to site B, you allow them to  bypass 
> such mechanisms.

Except of course you only allow them if there's some hypothetical cross 
domain XHR, something which doesn't exist, and then usefully there's a way 
of taking an XHR stream and converting it to an image or video stream, again 
something that doesn't exist.

> Most browsers today (the only exception I've seen yet is Mozilla)  send 
> Referer from XMLHttpRequest; by explicitly disallowing it from  being 
> automatically set, you're diverging from the current model for  XHR, as 
> well as diverging from the model for normal browser operation.

I don't want to specifically disallow it, I don't want it to be MUST, nor do 
I see a particular reason for it not to be overridable - a browser may want 
to not allow it to be overridable  without specific user agreement outside 
of the same domain for such reasons, but I don't see the reason for 
disallowing it from overriding within the same domain - given that any cross 
domain is with the explicit agreement of the user in all implementations 
today, I don't see the problem with any of them setting it, indeed I have 
many use cases for it.

The most prominent being the same Accessibility Testing assistant mentioned 
elsewhere.

Cheers,

Jim. 
Received on Thursday, 6 April 2006 21:59:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:54 GMT