W3C home > Mailing lists > Public > public-appformats@w3.org > September 2007

[access-control] Referer-Root HTTP header

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 20 Sep 2007 16:23:44 +0200
To: "Ian Hickson" <ian@hixie.ch>, "Jonas Sicking" <jonas@sicking.cc>
Cc: "WAF WG (public)" <public-appformats@w3.org>
Message-ID: <op.tyyh9uua64w2qv@annevk-t60.oslo.opera.com>

On Wed, 01 Aug 2007 02:24:06 +0200, Ian Hickson <ian@hixie.ch> wrote:
>>> Isn't Referer disabled by some third-party software now and then? Such
>>> as antivirus software? Another reason is probably that Referer-Root
>>> contains the exact format needed for the access check. We could use
>>> that in the access-control document probably.
>>
>> This seems like a loosing battle that I don't see a reason to fight. If
>> the user (by installing software or through corporate policies) disables
>> the Referer header, why should we try to circumvent them? That seems
>> just likely to piss them off and then add Referer-Root to their blocking
>> list.
>
> Referer is blocked for privacy reasons (e.g. including personal data in
> the URL). Referer-Root is supposed to be safe from this, by only  
> including
> host/domain information.
>
>
>> If the sites want to use the Referer header and it has been blocked the
>> site can simply deny the request. Non-idea for the end-user, but by
>> their own choice.
>
> Referer is also blocked when going from https:// to http://, for the same
> reasons as above, and we want Referer-Root available then too.

I've added Referer-Root to the specification for now. Let me know if this  
is ok.

http://dev.w3.org/2006/waf/access-control/Overview.html#access1


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Thursday, 20 September 2007 14:24:23 GMT

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