Re: XMLHttpRequest Object feedback

> >> 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?

I agree that end users should be allowed to "turn Referer off", as is  
the option in some browsers today, but allowing code to set the value  
of the Referer is a very different thing, and a significant  
divergence from current practice.

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

For example, site A hosts images (whether they be weather maps or  
porn) for use in site A's content. If site B directly links to those  
images, it places a burden on site A's servers, which they may or may  
not want to accept. Site A can control this by examining the Referer  
header; if it contains a URI from site B, they can choose not to  
serve it. If the browser is configured not to send any referers, it  
can make a separate choice as to whether or not to allow the browser  
to view the image.

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.

Additionally, site A might want to track referers for auditing, etc.;  
if Referer isn't set by default, they'll probably require people to  
use cookies, or different URLs for the same content -- neither being  
very Web-friendly.

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.

So, I'm fine with something like "The Referer header SHOULD be set,  
and MUST NOT be overridable"; if the user wants to configure their  
browser not to send the Referer header, they should certainly be  
allowed to. However, the developer (site B in the example above) must  
not be given control over it in any condition.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

Received on Thursday, 6 April 2006 21:49:59 UTC