- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 20 Mar 2013 09:54:08 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WHATWG <whatwg@whatwg.org>
On Tue, Mar 19, 2013 at 8:08 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, Mar 19, 2013 at 6:30 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> I don't think that that is a particularly convincing argument since there is
>> no confused deputy problem here, and if a website is making security
>> decisions based on referrer headers even when there are no other identifying
>> signals, then that website is a lost cause.
>
> Not if the referring URL was a capability, which I think might have
> been the point.
I don't understand what that means. Could you explain?
>> In other words, I see no new attack vectors being introduced, but I do see
>> additional value, if we keep the referrer.
>
> You do know there are efforts to making Referer obsolete within
> Mozilla so to leak less information about the user?
My argument isn't to force having a referrer here. My argument is to
follow the same policies for referrer as for other requests.
I don't think keeping the referrer anonymous XHR requests is going to
materially change the ability to adjust these policies in general.
That said, allowing both anonymous and non-anonymous requests to do
xhr.setRequestHeader("referer", "") might be a good idea. I.e. being
able to set it explicitly to the empty string.
/ Jonas
Received on Wednesday, 20 March 2013 16:55:07 UTC