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
[Bug 19831] Investigate overrideMimeType()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19831 Hallvord R. M. Steen hallv...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #14 from Hallvord R. M. Steen hallv...@opera.com --- As we largely agree that what the spec says is a reasonable idea, I'll WONTFIX this and we'll cross our fingers that there won't be much compat fallout.. -- You are receiving this mail because: You are on the CC list for the bug.
