Re: ISSUE-124 CP 2

Julian Reschke wrote:
> On 10.11.2010 22:09, Ian Hickson wrote:
>> ...
>> Security
>> --------
>>
>> The "noreferrer" feature is primarily intended for Web mail applications;
>> without some mechanism to remove the Referer: header from requests, a
>> third party could find out any information that is contained in the 
>> URL of
>> the mail app, such as in some cases the user's e-mail address, or at a
>> minimum the identity of their mail provider. (Without "noreferrer", such
>> sites have to use a variety of hacks that essentially depend on bugs in
>> browsers.) However, this use case doesn't apply to content that is made
>> available using the<link>  element. In fact, the Referer: header included
>> in requests made from<link>  elements (and other elements like<img>  that
>> are out of scope for this issue) is used _as_ a security feature to
>> prevent unauthorised reuse of content such as style sheets (and images).
>> By making it trivial to drop such headers, we would be making it much
>> harder to protect against such unauthorised content re-use.
> 
> How so? Page author adds "noreferrer", linked resource stops to work. 
> This is by design. If it hurts, don't do it.

A non-trivial percentage of users never send a Referer header (due to 
browser configuration or privacy-enhancing firewalls etc), so the usual 
approach to prevent hotlinking is to reject any requests with a present 
but incorrect Referer, and accept any with a correct or absent Referer. 
That avoids hurting Refererless users, but still works to prevent 
hotlinking since it breaks the hotlinking page for a vast majority of users.

noreferrer will make hotlinked requests indistinguishable from 
legitimate requests from users that block Referer. The only way to 
prevent hotlinking will then be to block all requests that lack Referer, 
which will hurt some legitimate users too.

-- 
Philip Taylor
pjt47@cam.ac.uk

Received on Thursday, 11 November 2010 11:37:16 UTC