On Tue, May 28, 2013 at 7:07 AM, Hallvord Reiar Michaelsen Steen <[email protected]> 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
