- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 28 May 2013 13:01:13 -0700
- To: Hallvord Reiar Michaelsen Steen <hallvord@opera.com>
- Cc: ?? Jasvir Nagra <jasvir@google.com>, Anne van Kesteren <annevk@annevk.nl>, Julian Aubourg <j@ubourg.net>, Jungkee Song <jungkees@gmail.com>, John Kemp <john@jkemp.net>, nathan <nathan@webr3.org>, "art.barstow" <art.barstow@nokia.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Ian Hickson <ian@hixie.ch>, "Tab Atkins Jr." <jackalmage@gmail.com>, w3c <w3c@adambarth.com>, ojan <ojan@chromium.org>, Dirk Pranke <dpranke@chromium.org>, mjs <mjs@apple.com>, Tyler Close <tyler.close@gmail.com>, public-webapps <public-webapps@w3.org>, Charles McCathie Nevile <chaals@yandex-team.ru>, "Mark S. Miller" <erights@google.com>
On Tue, May 28, 2013 at 7:07 AM, Hallvord Reiar Michaelsen Steen
<hallvord@opera.com> wrote:
> I wrote:
>
>> I would like to see some real code evidence that omitting Origin:
>> and Referer: is necessary too. In theory sites might use them as
>> "credentials" as you say, but in practise I don't see how that can
>> work and be safe on the web.
>>
>
>> If we ship XHR with an "anonymous" flag removing Origin: and Referer:
>> and call it a security feature, wouldn't that *encourage* sites to
>> validate requests by Origin: and Referer:? Aren't we basically pushing
>> snake oil security measures if we do so?
>
>
>
> I hereby propose that we drop the {anonymous:true} constructor argument and the "anonymous flag", and instead modify withCredentials to take three values: "samedomain" (default), "always" and "never". For backwards compatibility with earlier versions of the spec, setting withCredentials=true maps to "always" and withCredentials=false maps to "samedomain".
>
>
> This seems easier to understand, easier to implement, and handles all use cases of practical significance.
I'm opposed to this change. Trying to modify a boolean value into a
tristate can't be done fully backwards compatibly. Specifically, I
don't see a way to define this new behavior in such a way that reading
from withCredentials behaves in a backwards compatible way. At least
not while keeping the API sane.
I'd instead prefer to define a new property.
/ Jonas
Received on Tuesday, 28 May 2013 20:02:11 UTC