Re: Re: Re: [XHR] anonymous flag
On Thu, May 30, 2013 at 1:30 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: So creating a new tri-state property in the XHR spec should also simplify integration with the Fetch spec. Agreed. The question is, if we take it as a given that we're going to get a new API (that uses futures, deals with tainted requests, etc.) is it worth expanding the older API too? -- http://annevankesteren.nl/
Re: Re: Re: [XHR] anonymous flag
OK then - Anne and others, what do you think about creating a new tri-state xhr.credentialsPolicy property and discouraging usage of xhr.withCredentials ? I think I'd prefer removing the constructor flag and leaving new features to the API for Fetch. Sorry, I don't understand what you meant by this sentence. Fetch already has the required underpinnings for this tri-state flag: http://fetch.spec.whatwg.org/#concept-request-omit-credentials-mode A request has an associated omit credentials mode, which is one of always, CORS, and never. which maps exactly to credentialsPolicy: omit credentials mode: always == credentialsPolicy: never (naming can be discussed, withCredentials='never' would be more intuitive but as we're not redefining withCredentials.. Maybe credentialsPolicy = 'nocredentials' ?) omit credentials mode: CORS == credentialsPolicy: 'samedomain' omit credentials mode: never == credentialsPolicy: 'always' So creating a new tri-state property in the XHR spec should also simplify integration with the Fetch spec. Also, we still need to nail down the details of withCredentials. Questions raised in http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0499.html have gone without conclusive answers. I'm afraid I have no idea what the answers are.. -- Hallvord R. M. Steen Core tester, Opera Software
Re: Re: Re: Re: Re: [XHR] anonymous flag
On Tue, May 28, 2013 at 7:07 AM, Hallvord Reiar Michaelsen Steen hallv...@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
Re: Re: Re: [XHR] anonymous flag
[Minor edit: fixed your true/false typo] * 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. I agree (naturally) - now, just to be very clear: your needs are met if the API lets you control *credentials* - right? Does Caja currently attempt to suppress Referer: and/or Origin: headers? Do you consider it a requirement to be able to do so? * 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 defaulting to false 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). It sounds like making withCredentials a tri-state thing (i.e. with values 'samedomain', 'always', 'never') would work better for you :) - depending of course on how you respond to the above question, that is.. -- Hallvord R. M. Steen Core tester, Opera Software
Re: Re: Re: [XHR] anonymous flag
On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: [Minor edit: fixed your true/false typo] * 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. I agree (naturally) - now, just to be very clear: your needs are met if the API lets you control *credentials* - right? Does Caja currently attempt to suppress Referer: and/or Origin: headers? Do you consider it a requirement to be able to do so? Given that many services do (mistakenly or not) use Origin and/or Referer to make security choices, all these headers along with the cookie header ought to be considered credentials. Caja itself is a pure html, css and js rewriter and isn't always in a position to suppress headers without either awesome browser APIs like the one under discussion or with the help of a header stripping proxy. * 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 defaulting to false 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). It sounds like making withCredentials a tri-state thing (i.e. with values 'samedomain', 'always', 'never') would work better for you :) - depending of course on how you respond to the above question, that is.. +1. I do not have a strong opinion on what the API ought to be -- just that the feature is a necessary one. That said using two boolean flags (withCredentials and anon) to represent what is at least currently a tri-state value does (as you point out) run the risk of confusing developers who set the flags to conflicting values. -- Hallvord R. M. Steen Core tester, Opera Software
Re: Re: Re: Re: [XHR] anonymous flag
On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: Given that many services do (mistakenly or not) use Origin and/or Referer to make security choices, all these headers along with the cookie header ought to be considered credentials. Can you give any specific examples of services that use *and* rely on Origin and/or Referer to make security choices? For example if there is some backend code hosted on GitHub that I could consider to understand this issue better? It might also help if you're able to point me to some documentation on how AppScript and Sites work exactly. My understanding is that you run untrusted scripts inside a trusted context (sandboxed), and need to make sure these scripts can not 1) load sensitive data from the origin server 2) cause side effects on the origin server Your origin server obviously needs to verify incoming requests, using any or all of * Cookies (ambient) * Tokens * Origin: / Referer: headers (ambient) and that you make sure untrusted scripts that want to make same-origin requests use a cross-origin proxy to omit cookies and make sure these requests are thus not verified as trusted. Is this accurate? Now, if you have any service that's *only* verifying requests by Origin: / Referer: I'm pretty sure your service has a glaring security hole..? If suppressing Origin/Referer is a requirement for Caja, can you sketch some realistic demo where an otherwise safe service becomes unsafe when this feature is missing? I do not have a strong opinion on what the API ought to be -- just that the feature is a necessary one. And I fully accept that for Cookie/HTTP auth/SSL session credentials, but 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? That said using two boolean flags (withCredentials and anon) to represent what is at least currently a tri-state value does (as you point out) run the risk of confusing developers who set the flags to conflicting values. To be fair: as the spec is written, it's not supposed to be possible to set them to conflicting values. Implementations may of course be buggy.. I hope you don't mind me going on and on about this.. I think we may still have time to improve the spec here and make implementations support Caja's use cases better, so your input is very useful. -- Hallvord R. M. Steen Core tester, Opera Software
Re: Re: Re: [XHR] anonymous flag
Making a boolean a tri-state with a default depending on an external variable is also super confusing. To whom? It seems confusing to anyone who reads the value. Good point. What would it return in the various situations? I.e. before and after .open() has been called, and if .open() was called with a cross-origin URL or not. Simplest possibility seems to be undefined if not set, true or false respectively if it was set. Of course this doesn't reflect whether credentials will be sent in the request or not - but that doesn't really happen today either, we don't automagically make it return true for same-origin and false for cross-origin requests, so it's not much of a change. Most capability detection I've seen uses the sensible 'withCredentials' in xhr form which will still work. -- Hallvord R. M. Steen Core tester, Opera Software