Re: Re: [XHR] anonymous flag

On Wed, May 22, 2013 at 7:27 AM, ๏̯͡๏ Jasvir Nagra <>wrote:

> * If we had a better way of controlling the option to deny sending
> credentials in a way that kept compatibility with legacy webpages (eg. a
> tristate flag like you suggest in [6]), I agree it would be better than to
> have two different flags which may be confusing to developers and which may
> disagree with each other.
> * In Google AppScript and on Google Sites, we execute a code on the same
> domain sandboxed using Caja.  In this case, Caja  relies on withCredentials

Typo: Caja relies on withCredentials defaulting to false.

> defaulting to true and prevents sandboxed guest code from setting it to
> true.  In this way, we're able to work around the difficulties posed by the
> API that you point out.  We are nevertheless forced to either proxy or deny
> requests to the same origin since the CORS anon flag appears not be
> reliably supported on all browsers (and withCredentials does not apply to
> same-origin).  The test for same origin is an error prone blacklisting
> test. We look forward to all browsers providing the anon feature reliably
> to avoid expensive proxying.
> * Irrespective of the difficulty of using the API correctly, we do need to
> have the option to deny credentials to the same-origin.
> jas
> On Tue, May 21, 2013 at 6:30 PM, Mark S. Miller <>wrote:
>> Let's please find some time to discuss this *today* if at all possible.
>> I'm sure there will be several agenda items I don't need to be at, and
>> there's always lunch. I would like us to be able to say that Caja, Sites,
>> and Google AppScript use and need to use the UMP-enabling features of CORS.
>> Is that true? If not, I'd like to see how close to that we can come.
>> ---------- Forwarded message ----------
>> From: Hallvord Reiar Michaelsen Steen <>
>> Date: Tue, May 21, 2013 at 1:41 PM
>> Subject: Re: Re: [XHR] anonymous flag
>> To: Charles McCathie Nevile <>, public-webapps <
>>>, Jonas Sicking <>,
>> Cc: Anne van Kesteren <>, Jungkee Song <
>>>, Julian Aubourg <>
>> Anne wrote:
>> > I don't really feel it's responsible to remove this feature at this
>> > point without anyone involved in the original discussion speaking up.
>> Hi all,
>> you were involved in a discussion [1] regarding UMP and CORS back in
>> 2010. I know, it's a while ago, and apparently you had already been
>> discussing this for *quite* a while. However, as the saying goes: no good
>> deed goes unpunished, and I'd like wider feedback on an issue I've been
>> discussing with Anne - so here's another chance to exercise those
>> arguments. My apologies :-o..
>> I've been working on the XHR test suite, and thus been looking at the
>> spec from a JS developer's perspective. From this perspective, I found that
>> the withCredentials / anonymous flag features were somewhat confusing, to
>> be more specific it was hard to figure out what the point of the anonymous
>> flag really was. Some very close reading of the spec helped me figure out
>> that the anonymous flag would:
>> * Disable Origin: and Referer: headers
>> * Send same-origin requests as if they were cross-origin: require
>> preflights where CORS requests require preflights, and the same-origin
>> server must opt-in with Access-Control-Allow-Origin and such.
>> Now, I read through the old thread [1] - all of it, the UMP spec and some
>> other related stuff, but still couldn't quite figure out what use cases
>> this was meant to solve - so I questioned why we should have the anonymous
>> flag at all in [2], [3] and [4]. (Sorry for referencing only my arguments,
>> the interleaved E-mails are easy to find from there).
>> So far in the discussion, I still think we should drop the "anonymous
>> flag" feature from the spec. Some more thoughts beyond the arguments in the
>> referenced E-mails:
>> * On the web, the most widely used authorization models are cookies and
>> SSL sessions. Authority is rarely if ever defined by Origin and/or Referer
>> - and rightly so, since they can easily be faked in server-to-server
>> requests. Some sites have traditionally whitelisted certain sites based on
>> Referer to avoid "hotlinking" of images, but hacking around such measures
>> is hardly a use case we should try to cater for.
>> Hence, I don't even see much of a theoretical benefit to suppressing
>> Origin.
>> * On the web, we usually value security-in-depth, i.e. several layers of
>> security checks. The UMP model seemed to argue strongly in favour of a
>> single point of failure - a token in the URL or in the body of a POST
>> request. It seems to me that most services that need securing would want to
>> also check Origin, check cookies and/or SSL data. On the surface this is an
>> argument *for* the anonymous flag: given the assumption that valuable
>> services do layered security, having credentials dropped in requests that
>> may be risky is a Good Thing (TM). However, the problem is we put the
>> burden on developers to *set* the anonymous flag, to foresee what requests
>> might be risky and take precautions, to opt-in to a mode where even
>> same-origin requests become much more cumbersome to complete and where
>> their *own* layered security measures will fail. This feature is IMHO very
>> hard to use correctly, and can
>> easily cause unexpected and hard to understand failure modes if used
>> incorrectly.
>> * If we can't easily explain to authors what a feature is for, it won't
>> get used.
>> * Having both withCredentials and anonymous flag is confusing and can
>> give a false sense of security as explained in [6].
>> My preferred solution (which may be a little too "magic") is to turn
>> withCredentials into a sort of tri-state flag, where setting
>> withCredentials=false disables using cookies/HTTP Auth/existing SSL
>> sessions on both same-origin and cross-origin requests, setting
>> withCredentials=true enables it for both, and not setting it will leave the
>> default behaviour to use authentication on same-origin and omit it for
>> cross-origin requests. (Then drop the "anonymous" flag and ignore any
>> requests for being able to suppress Referer: and Origin: (unless documented
>> by use cases we want to support).)
>> Another option might be to drop anonymous flag, "deprecate"
>> withCredentials and define a new property called sendCredentials, taking
>> values "sameorigin", "always" and "never", with "sameorigin" being the
>> default value. Too bad I'm 2-3 years late with that suggestion, I think it
>> would have been clearer.
>> (Obviously, if we think existing content using withCredentials is written
>> in a way that would let us get away with redefining it to being a string,
>> use values "sameorigin", "always" and "never" and throw in a small hack
>> translating true when set to "always", that would be totally sweet :-D.)
>> Further, I think that as an extra security precaution, the spec should
>> make it absolutely clear that if a CORS-request where withCredentials is
>> *not* set to true/always gets redirected to a same-origin URL, credentials
>> must *not* be sent while requesting the redirect target. This should close
>> one of the existing potential holes and make XHR and CORS a tad more safe
>> by default.
>> Now, from my practical-JS-author perspective there may be things I'm
>> missing. Maybe to do with server implementation details or typical
>> intranet/internet boundary behaviours. I fully agree with Anne that it
>> would be good to have further input from you all while considering removing
>> the anonymous flag. If you can convince me that we need the anonymous flag,
>> we don't have to edit the spec to remove it - yay, less work for us editors
>> ;-) - so please discuss..
>> [1]
>> [2]
>> [3]
>> [4]
>> [5]
>> [6]
>> --
>> Hallvord R. M. Steen
>> Core tester, Opera Software
>> --
>>     Cheers,
>>     --MarkM

Received on Wednesday, 22 May 2013 14:50:20 UTC