Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 10:02 PM, Ian Hickson wrote: > On Wed, 12 May 2010, Tyler Close wrote: >> >> So HTML is not vulnerable to Cross-Site Scripting, C++ is not vulnerable >> to buffer overflows and so CORS is not vulnerable to Confused Deputy. > > Correct. > As some (at least me) might be confused by what you're saying here, are you saying that "C++ isn't vulnerable to buffer overflows, rather *some programs* written in C++ are vulnerable to buffer overflows"? And, hence, some usages of CORS aren't vulnerable to buffer overflows and so you can say that CORS itself is not, either? Or are you saying something stronger, and I'm still not following you? Like MarkM, I perhaps am not understanding the "Web standards" manner of using the word "vulnerable" and so it would be helpful if you could elaborate. To continue the analogy, there is an essential distinction between C++'s vulnerability to buffer overflows and (Java, Python, ML, etc.) total lack of vulnerability. To say that C++ is not subject to buffer overflows but rather individual programs are at fault is to lose sight of that essential distinction. Much as Tyler is attempting to distinguish between APIs that use ambient authority (and hence, are "vulnerable", even if some usages are safe) and APIs where that simply cannot happen. Regardless of the above, I agree 100% that it is more fruitful to focus on actual examples so we can be completely clear about this ... -- Dirk
Re: UMP / CORS: Implementor Interest
Hi Ian, On May 13, 2010, at 1:02 AM, Ian Hickson wrote: > On Wed, 12 May 2010, Tyler Close wrote: [...] > > You are using the word "vulnerable" in a manner inconsistent with its > meaning in the Web standards community. I think the specific vulnerability is that a server is vulnerable to a malicious or incorrectly-configured client passing on a malicious request in any model where the server depends on the client "doing the right thing" with an identifier passed from the malicious request. [...] > >> It is a strange security model that says the client must completely >> validate the request before submitting it. > > It's how all the technologies on the Web so far have been secured. While > it may be academically strange, it is the only security model Web authors > are familiar with, so to them it isn't strange at all. XSS, XSRF, SQL > injection -- all these classes of problems are addressed by validating > data in the request before acting on it or passing it on to the next > system. You may not like this kind of design, but it's what authors are > most used to. Just because we are used to it, doesn't mean we shouldn't seek to improve the model in order to remove vulnerabilities. Doing so may change the model -- but in ways we all benefit from and appreciate. Removing XSRF and clickjacking from the developer's lexicon seems like a worthy goal - doesn't it? > > >> Yes, well, that's what I'm trying to do. By refusing to admit that tools >> contribute to bugs in any way, you are doing the opposite. > > To be blunt: browser vendors have said they are implementing CORS, and > that UMP isn't enough. Continuing to argue against this isn't working. If > you want CORS replaced with something else, you need to find something > that will convince browser vendors; repeating your claims that the CORS > technology is vulnerable is merely distancing you further from the rest of > the working group and is more likely to make any further advice you may > have get ignored as well. The (current) browsers are not the only clients, and both UMP and CORS are attempts to work on the entire Web. The specific vulnerability that is important is whether it is possible for a client to be duped into sending a request on behalf of a malicious server to an unsuspecting server. Should Web servers really have to depend on whether a complex client is written correctly (and not maliciously) in order to ensure that a request from a third-party is authentic? Regards, - johnk
Re: UMP / CORS: Implementor Interest
On Thu, May 13, 2010 at 3:48 AM, Maciej Stachowiak wrote: > > On May 13, 2010, at 3:05 AM, Julian Reschke wrote: > >> On 12.05.2010 22:39, Nathan wrote: >>> Devdatta wrote: > As for the "should CORS exist" discussion, I'll bow out of those until > we're starting to move towards officially adopting a WG decision one > way or another, or genuinely new information is provided which would > affect such a decision (for the record, I don't think I've seen any > new information provided since last fall's TPAC). exactly -- I don't see this thread getting anywhere. >>> >>> Vendors & Spec writers, >>> >>> What would be really nice is if you gave us server admins, application >>> server-side developers and data publishers a say in this. >>> >>> Thus I'll propose a new header: >>> >>> Allow-XHR = "Allow-XHR" ":" Allow-XHR-v >>> Allow-XHR-v = "none" | "negotiate" | "all" >>> >>> "none" defines no XHR access >>> >>> "negotiate" defines the UA should negotiate CORS or UMP headers (leave >>> that up to you guys to decide what's best ;) >>> >>> "all" defines that the UA should process the XHR request as a normal >>> client HTTP request leaving all information + headers intact. >>> ... >> >> From the side line: I hear that people were worried about having to add new >> response headers just for CORS & friends. Was it ever discussed to send >> these response headers only based on something in the *request*? > > That's already how CORS works, essentially. You don't need to send the > Access-Control-Allow-Origin header or other headers, unless you see a request > with a non-same origin Origin header. The no-credentials subset of CORS is a > bit weaker. It sends "Origin: null", which could also be triggered by > something like traversing a link. UMP doesn't provide for this at all - there > is no required header in a UMP request that can distinguish it from any other > request. The presence or absence of a Cookie header could be used for this micro optimization in UMP: no Cookie, include the Access-Control-Allow-Origin header; otherwise don't. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: CORS suggestions [Was: Re: UMP / CORS: Implementor Interest]
On Thu, May 13, 2010 at 6:39 AM, Arthur Barstow wrote: > On May 12, 2010, at 2:42 PM, ext Jonas Sicking wrote: > >> If so, I'd really like to see the chairs move forward with making the >> WG make some sort of formal decision on weather CORS should be >> published or not. Repeating the same discussion over and over is not >> good use your time or mine. > > There is sufficient interest in CORS such that we should continue to work on > it. As such, I don't think any type of "formal decision" re publication is > needed. > > Although this and other recent and related threads have indeed re-hashed > some previous discussions, among some of the suggestions made are: > > * CORS' security considerations section needs improvements > > http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0625.html > http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0630.html > > * Need security analysis e.g. with multi-party deployments; "test the > security properties of CORS" (e.g. versus UMP) > > http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0645.html > > * Need usage informatin for the app developer and server admin; when is CORS > safe to use; which is easier to use; guidelines for not "falling prey to > attacks with CORS" > > http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0543.html > http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0646.html > http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0648.html > > * CORS needs text about Confused Deputy > > http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0612.html > http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0648.html > > Is anyone willing to contribute to the above? > I will happily contribute to this and to whatever work is necessary to merge UMP and CORS into a single spec (plus additional non-normative documents), if that's helpful. -- Dirk
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 6:41 PM, Tyler Close wrote: > On Wed, May 12, 2010 at 5:36 PM, Dirk Pranke wrote: >> On Wed, May 12, 2010 at 5:15 PM, Tyler Close wrote: >>> On Wed, May 12, 2010 at 5:07 PM, Adam Barth wrote: On Wed, May 12, 2010 at 4:56 PM, Tyler Close wrote: > Both Adam and Dirk understood correctly. Ideally, I'd like an actual > CORS example to work on, since I'd have to make analogies with > postMessage(), and I've already made a ton of analogies, apparently to > little effect. If people don't fully appreciate the relationship > between based CSRF and CORS based Confused Deputy, then we need > an actual CORS application. > > Out of curiosity, who are the 3 parties involved in the facebook chat > example? The little chat widget in the corner of the facebook page > looks like a same origin application. Facebook uses a lot of different domains for different purposes. I don't have a complete count, but at least a dozen. The chat feature itself uses a bunch, possibly to get around various connection limits in browsers. >>> >>> This doesn't seem like a good example then, since the attacker would >>> have to be facebook itself. For robustness, I personally consider >>> these scenarios when designing an application, but people on this list >>> might not find it compelling. They might also argue that no attempt >>> was made to protect against such a vulnerability. >>> Keep in mind that the browser's notion of an origin is often much smaller than a single application, which is part of the reason web developers are so keen on CORS. Many of them plan to use it only to talk to trusted hosts without having to use goofy things like JSONP. >>> >>> Enabling this scenario is a fine thing, but it's not the scenario we >>> should be using to test the security properties of CORS. UMP also >>> enables communication between fully trusted participants. >> >> It seems like a fine scenario to me. We know people want to use CORS >> for this purpose because it makes their code easier and cleaner (both >> of which are nice security things in and of themselves). If both CORS >> and UMP are secure for this use case, then an interesting question is, >> which is easier to use? This is particularly relevant insofar as if >> the existing JSONP-based solution uses cookies, since CORS would >> support this but UMP wouldn't (meaning the degree of rework in the app >> necessary to support the code would be higher). >> >> Note that I am not saying that this should be the only scenario to be >> reviewed, but you shouldn't just pick and choose the cases that best >> fit your hypothesis. > > Over the course of this discussion, I've taken every use-case, with > every arbitrary constraint that anyone wants to add and shown a > corresponding UMP solution, so it is grossly unfair to accuse me of > picking and choosing cases. > > For this particular discussion, we were explicitly looking for an > example of a Confused Deputy vulnerability in an actual CORS > application. Such a thing doesn't exist in a scenario with only 2 > parties and no attacker. When testing security properties, you need an > attacker. I apologize, I thought your intent was to do a security review of CORS, which in my mind would show what situations it can be used safely and what situations it can't, not just show the latter. The two-party situation is interesting because it is a situation that cannot be solved today without CORS or UMP. So, the point is that CORS can safely enable a class of scenarios that are not possible otherwise. This is a non-trivial point given the current discussion. Besides, I thought part of the point of the argument is that sites that are often considered to be trusted aren't, because of the possibility of SQL injection, XSS, etc. > > All that said, if you want to compare the usability of CORS and UMP in > a 2 party interaction between fully trusted participants, we can do > that. Go ahead and sketch out the challenge problem and corresponding > CORS solution. > I will send something shortly. -- Dirk
Last Word-ism (was: Re: UMP / CORS: Implementor Interest)
On Wed, May 12, 2010 at 10:02 PM, Ian Hickson wrote: > On Wed, 12 May 2010, Tyler Close wrote: > > > > So HTML is not vulnerable to Cross-Site Scripting, C++ is not vulnerable > > to buffer overflows and so CORS is not vulnerable to Confused Deputy. > > Correct. > > > > As explained above, CORS with credentials is intrinsically vulnerable to > > Confused Deputy. The use of credentials forces the developer to consider > > Confused Deputy vulnerabilities. > > You are using the word "vulnerable" in a manner inconsistent with its > meaning in the Web standards community. > > > > > It's just as possible to make bad designs using UMP than with CORS. > > > > It's rare that a tool makes bad design impossible. Are you saying that's > > the metric for comparing the security of two tools? So long as bad > > design is possible, the two tools are equivalent? > > You seem to be arguing that as long as bad design is possible, a tool > shouldn't be made available at all! [1] > > [1] > http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0604.html > > > > > (I would argue that UMP actually makes it more likely that designs > > > will have poor security characteristics since it ends up being easier > > > to ask for the user's credentials directly than doing the right thing. > > > With CORS, on the other hand, it's easier to use the user's existing > > > session, so it's less likely that people will ask for credentials > > > inappropriately.) > > > > But you haven't considered the dangers that come from reusing the user's > > existing session. That's an inherently dangerous thing to do, but you > > seem to ignore the problem and so come to the conclusion you want. > > It is not an inherently dangerous thing to do, that's hyperbole. It is > certainly possible to use this tool wrongly, e.g. by executing actions on > the behalf of another origin, but is anyone suggesting doing that? > > It would be helpful if we could focus on concrete use cases, so that we > could document them and add offer them to Anne to add to the CORS spec. > > > > > What use cases would you like examples for? Let's write them up and > > > give them to Anne to the introduction section. > > > > I want to see CORS try to develop something like the Security > > Considerations section in UMP with simple, clear choices for application > > developers to consider. I want this advice to be feasible to follow and > > to provide a robust defense against Confuse Deputy problems. I doubt > > such advice can be provided for CORS. > > I'm interested in providing authors with concrete examples based on > real-world use cases. What use cases are you concerned about? I see no use > cases in the section to which you refer, only abstract advice: > > http://dev.w3.org/2006/waf/UMP/#security > > > > Confused Deputy attacks cannot be fixed by escaping data. There may be > > no static test that can be done to validate an identifier. > > Then don't use identifiers of this nature. > > > > It is a strange security model that says the client must completely > > validate the request before submitting it. > > It's how all the technologies on the Web so far have been secured. While > it may be academically strange, it is the only security model Web authors > are familiar with, so to them it isn't strange at all. XSS, XSRF, SQL > injection -- all these classes of problems are addressed by validating > data in the request before acting on it or passing it on to the next > system. You may not like this kind of design, but it's what authors are > most used to. > > > > Yes, well, that's what I'm trying to do. By refusing to admit that tools > > contribute to bugs in any way, you are doing the opposite. > > To be blunt: browser vendors have said they are implementing CORS, and > that UMP isn't enough. Continuing to argue against this isn't working. If > you want CORS replaced with something else, you need to find something > that will convince browser vendors; repeating your claims that the CORS > technology is vulnerable is merely distancing you further from the rest of > the working group and is more likely to make any further advice you may > have get ignored as well. > Hi Ian, I detect genuine concern in your last statement above, so I'm sure the following observation does not indicate any malicious intent. Please do not take it otherwise. I think what is going on is only that good debaters can fall into rhetorical habits that are more effective than they are legitimate. Responding in kind to your concern, I'd like to alert you to the possibility that you may be doing that. You (and many others here) are placing Tyler in a no win bind. You are repeating fallacies that have already been repeated dozens of times in this thread, and that Tyler has already responded to dozens of times. When you repeat them yet again, if Tyler responds yet again, you and many others on in this forum accuse him of repeating old arguments. Should Tyler not respond, then the fallacies rest on the
CORS suggestions [Was: Re: UMP / CORS: Implementor Interest]
On May 12, 2010, at 2:42 PM, ext Jonas Sicking wrote: If so, I'd really like to see the chairs move forward with making the WG make some sort of formal decision on weather CORS should be published or not. Repeating the same discussion over and over is not good use your time or mine. There is sufficient interest in CORS such that we should continue to work on it. As such, I don't think any type of "formal decision" re publication is needed. Although this and other recent and related threads have indeed re- hashed some previous discussions, among some of the suggestions made are: * CORS' security considerations section needs improvements http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/ 0625.html http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/ 0630.html * Need security analysis e.g. with multi-party deployments; "test the security properties of CORS" (e.g. versus UMP) http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/ 0645.html * Need usage informatin for the app developer and server admin; when is CORS safe to use; which is easier to use; guidelines for not "falling prey to attacks with CORS" http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/ 0543.html http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/ 0646.html http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/ 0648.html * CORS needs text about Confused Deputy http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/ 0612.html http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/ 0648.html Is anyone willing to contribute to the above? -Art Barstow
Re: UMP / CORS: Implementor Interest
Maciej Stachowiak wrote: On May 13, 2010, at 3:05 AM, Julian Reschke wrote: On 12.05.2010 22:39, Nathan wrote: Devdatta wrote: As for the "should CORS exist" discussion, I'll bow out of those until we're starting to move towards officially adopting a WG decision one way or another, or genuinely new information is provided which would affect such a decision (for the record, I don't think I've seen any new information provided since last fall's TPAC). exactly -- I don't see this thread getting anywhere. Vendors & Spec writers, What would be really nice is if you gave us server admins, application server-side developers and data publishers a say in this. Thus I'll propose a new header: Allow-XHR = "Allow-XHR" ":" Allow-XHR-v Allow-XHR-v = "none" | "negotiate" | "all" "none" defines no XHR access "negotiate" defines the UA should negotiate CORS or UMP headers (leave that up to you guys to decide what's best ;) "all" defines that the UA should process the XHR request as a normal client HTTP request leaving all information + headers intact. ... From the side line: I hear that people were worried about having to add new response headers just for CORS & friends. Was it ever discussed to send these response headers only based on something in the *request*? That's already how CORS works, essentially. You don't need to send the Access-Control-Allow-Origin header or other headers, unless you see a request with a non-same origin Origin header. The no-credentials subset of CORS is a bit weaker. It sends "Origin: null", which could also be triggered by something like traversing a link. UMP doesn't provide for this at all - there is no required header in a UMP request that can distinguish it from any other request. (Regarding the proposal you quoted, I don't understand how the new header is materially different from CORS/UMP, which are both use opt-in response headers that allow cross-origin access.) The original issue is that CORS doesn't as yet allow for opt-in headers, Maciej Stachowiak earlier suggested (amongst renaming all the other headers): new header to expose more response headers ==> Expose-Headers (or Expose-Response-Headers) UMP does cater for this. The specific issue I need to get around (as an app developer and not a vendor) - note: not spam, clarifying to save you good busy people from trawling this huge thread - is: I've (amongst others) have adopted a new Web Access Control & SSL auth* model, and under this model HTTPS conflicts with the same origin rules for XHR. I spoke to TimBL about it, who said to adopt CORS, but under closer inspection I've found the headers needed for the model he proposes (and for REST) are not allowed in the current draft of CORS. Namely Link and Location. Whilst the above quoted is overkill, the (now over mentioned by me) Expose-Headers suggestion from Maciej Stachowiak or UMPs Uniform-Headers would both solve the problem :) Regardless of the UMP/CORS thing, I (along with most of the people doing Read-Write-Web / Linked Data / FOAF+SSL / REST) would value a header opt-in solution being in both drafts; that is, it's critical to the web of data & UK/US Government Linked Data efforts moving forwards. Best, Nathan
Re: UMP / CORS: Implementor Interest
On May 13, 2010, at 3:05 AM, Julian Reschke wrote: > On 12.05.2010 22:39, Nathan wrote: >> Devdatta wrote: As for the "should CORS exist" discussion, I'll bow out of those until we're starting to move towards officially adopting a WG decision one way or another, or genuinely new information is provided which would affect such a decision (for the record, I don't think I've seen any new information provided since last fall's TPAC). >>> >>> exactly -- I don't see this thread getting anywhere. >> >> Vendors & Spec writers, >> >> What would be really nice is if you gave us server admins, application >> server-side developers and data publishers a say in this. >> >> Thus I'll propose a new header: >> >> Allow-XHR = "Allow-XHR" ":" Allow-XHR-v >> Allow-XHR-v = "none" | "negotiate" | "all" >> >> "none" defines no XHR access >> >> "negotiate" defines the UA should negotiate CORS or UMP headers (leave >> that up to you guys to decide what's best ;) >> >> "all" defines that the UA should process the XHR request as a normal >> client HTTP request leaving all information + headers intact. >> ... > > From the side line: I hear that people were worried about having to add new > response headers just for CORS & friends. Was it ever discussed to send these > response headers only based on something in the *request*? That's already how CORS works, essentially. You don't need to send the Access-Control-Allow-Origin header or other headers, unless you see a request with a non-same origin Origin header. The no-credentials subset of CORS is a bit weaker. It sends "Origin: null", which could also be triggered by something like traversing a link. UMP doesn't provide for this at all - there is no required header in a UMP request that can distinguish it from any other request. (Regarding the proposal you quoted, I don't understand how the new header is materially different from CORS/UMP, which are both use opt-in response headers that allow cross-origin access.) Regards, Maciej
Re: UMP / CORS: Implementor Interest
On 12.05.2010 22:39, Nathan wrote: Devdatta wrote: As for the "should CORS exist" discussion, I'll bow out of those until we're starting to move towards officially adopting a WG decision one way or another, or genuinely new information is provided which would affect such a decision (for the record, I don't think I've seen any new information provided since last fall's TPAC). exactly -- I don't see this thread getting anywhere. Vendors & Spec writers, What would be really nice is if you gave us server admins, application server-side developers and data publishers a say in this. Thus I'll propose a new header: Allow-XHR = "Allow-XHR" ":" Allow-XHR-v Allow-XHR-v = "none" | "negotiate" | "all" "none" defines no XHR access "negotiate" defines the UA should negotiate CORS or UMP headers (leave that up to you guys to decide what's best ;) "all" defines that the UA should process the XHR request as a normal client HTTP request leaving all information + headers intact. ... From the side line: I hear that people were worried about having to add new response headers just for CORS & friends. Was it ever discussed to send these response headers only based on something in the *request*? Best regards, Julian
Re: UMP / CORS: Implementor Interest
On Wed, 12 May 2010, Tyler Close wrote: > > So HTML is not vulnerable to Cross-Site Scripting, C++ is not vulnerable > to buffer overflows and so CORS is not vulnerable to Confused Deputy. Correct. > As explained above, CORS with credentials is intrinsically vulnerable to > Confused Deputy. The use of credentials forces the developer to consider > Confused Deputy vulnerabilities. You are using the word "vulnerable" in a manner inconsistent with its meaning in the Web standards community. > > It's just as possible to make bad designs using UMP than with CORS. > > It's rare that a tool makes bad design impossible. Are you saying that's > the metric for comparing the security of two tools? So long as bad > design is possible, the two tools are equivalent? You seem to be arguing that as long as bad design is possible, a tool shouldn't be made available at all! [1] [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0604.html > > (I would argue that UMP actually makes it more likely that designs > > will have poor security characteristics since it ends up being easier > > to ask for the user's credentials directly than doing the right thing. > > With CORS, on the other hand, it's easier to use the user's existing > > session, so it's less likely that people will ask for credentials > > inappropriately.) > > But you haven't considered the dangers that come from reusing the user's > existing session. That's an inherently dangerous thing to do, but you > seem to ignore the problem and so come to the conclusion you want. It is not an inherently dangerous thing to do, that's hyperbole. It is certainly possible to use this tool wrongly, e.g. by executing actions on the behalf of another origin, but is anyone suggesting doing that? It would be helpful if we could focus on concrete use cases, so that we could document them and add offer them to Anne to add to the CORS spec. > > What use cases would you like examples for? Let's write them up and > > give them to Anne to the introduction section. > > I want to see CORS try to develop something like the Security > Considerations section in UMP with simple, clear choices for application > developers to consider. I want this advice to be feasible to follow and > to provide a robust defense against Confuse Deputy problems. I doubt > such advice can be provided for CORS. I'm interested in providing authors with concrete examples based on real-world use cases. What use cases are you concerned about? I see no use cases in the section to which you refer, only abstract advice: http://dev.w3.org/2006/waf/UMP/#security > Confused Deputy attacks cannot be fixed by escaping data. There may be > no static test that can be done to validate an identifier. Then don't use identifiers of this nature. > It is a strange security model that says the client must completely > validate the request before submitting it. It's how all the technologies on the Web so far have been secured. While it may be academically strange, it is the only security model Web authors are familiar with, so to them it isn't strange at all. XSS, XSRF, SQL injection -- all these classes of problems are addressed by validating data in the request before acting on it or passing it on to the next system. You may not like this kind of design, but it's what authors are most used to. > Yes, well, that's what I'm trying to do. By refusing to admit that tools > contribute to bugs in any way, you are doing the opposite. To be blunt: browser vendors have said they are implementing CORS, and that UMP isn't enough. Continuing to argue against this isn't working. If you want CORS replaced with something else, you need to find something that will convince browser vendors; repeating your claims that the CORS technology is vulnerable is merely distancing you further from the rest of the working group and is more likely to make any further advice you may have get ignored as well. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 6:33 PM, Ian Hickson wrote: > On Wed, 12 May 2010, Tyler Close wrote: >> > >> >> It is also not a question of opinion, but fact. CORS uses ambient >> >> authority for access control in 3 party scenarios. CORS is therefore >> >> vulnerable to Confused Deputy. >> > >> > That's like saying that HTML uses markup and is therefore vulnerable >> > to markup injection. It's a vast oversimplification and overstatement >> > of the problem. >> >> Is it really? XSS is a major problem. HTML provides no facility for >> dealing with XSS and practically invites it. It's hard to deal with this >> situation now since HTML is so widely deployed. CORS invites Confused >> Deputy problems but is not yet widely deployed. We can still do >> something about it. > > HTML's use of markup is not a vulnerability. > CORS's use of ambient authority is not a vulnerability. > > Sure, both can be used in vulnerable ways, but they are not themselves > vulnerabilities. So HTML is not vulnerable to Cross-Site Scripting, C++ is not vulnerable to buffer overflows and so CORS is not vulnerable to Confused Deputy. There's something very Alice in Wonderland about all this Humpty Dumpty talk and accusations of nonsense. If there are special precautions that must be taken to avoid a problem, then you are vulnerable to that problem. From a security perspective we are interested in what precautions a technology requires developers to take and whether or not it's feasible to apply those precautions. Direct memory management forces C++ developers to consider what kind of library, technique or verifier they'll use to protect themselves against memory access errors. Automatic sending of credentials forces CORS developers to consider how they'll protect themselves against Confused Deputy problems. The requirement for a defense is inherent in the design of the tool. Using UMP you can build an app without use of credentials and so without needing to consider Confused Deputy vulnerabilities. >> > It is quite possible to write perfectly safe n-party apps. >> >> It is also quite possible to stand on your head while riding a bicycle. >> What's your point? > > My point is that you are arguing that one design is less good than > another, but you are using words that make it sound like you are arguing > that one design is actually intrinsicly vulnerable. As explained above, CORS with credentials is intrinsically vulnerable to Confused Deputy. The use of credentials forces the developer to consider Confused Deputy vulnerabilities. > It's just as possible > to make bad designs using UMP than with CORS. It's rare that a tool makes bad design impossible. Are you saying that's the metric for comparing the security of two tools? So long as bad design is possible, the two tools are equivalent? > (I would argue that UMP > actually makes it more likely that designs will have poor security > characteristics since it ends up being easier to ask for the user's > credentials directly than doing the right thing. With CORS, on the other > hand, it's easier to use the user's existing session, so it's less likely > that people will ask for credentials inappropriately.) But you haven't considered the dangers that come from reusing the user's existing session. That's an inherently dangerous thing to do, but you seem to ignore the problem and so come to the conclusion you want. >> No one has laid out a clear strategy for developers to follow to use >> CORS safely and shown how to apply it to expected use cases. > > What use cases would you like examples for? Let's write them up and give > them to Anne to the introduction section. I want to see CORS try to develop something like the Security Considerations section in UMP with simple, clear choices for application developers to consider. I want this advice to be feasible to follow and to provide a robust defense against Confuse Deputy problems. I doubt such advice can be provided for CORS. >> The CORS spec doesn't even mention Confused Deputy problems. > > I'm sure Anne would be happy to include suitable text if you provide it. > However, such text has to be accurate, and not make false claims like > saying that there is a security vulnerability where there is only the > potential for one when the feature is misused. CORS doesn't even say yet how to use it safely, so what does it mean to misuse it? We may also have a different perspective on what it means to be candid about the problems facing developers. >> >> > It is certainly possible to mis-use CORS in insecure ways, but then >> >> > it's also possible to mis-use UMP in insecure ways. >> >> You could justify any kind of security weakness with that kind of logic. >> Nuclear waste can be used in insecure ways, but then so can hammers. > > No. There is a _massive_ difference between features that _may_ be > misused, and features that _cannot be used safely_. For example, if XHR > let you read data from any site without any sort of server opt-in,
Re: UMP / CORS: Implementor Interest
Ian Hickson wrote: On Wed, 12 May 2010, Tyler Close wrote: We've gone through several scenarios on this list where this validation is not feasible. On the chromium list, I recently explained how it is not possible to implement a generic AtomPub client that does this validation: http://groups.google.com/a/chromium.org/group/chromium-dev/msg/afda9a4d1d1a4fcb I don't think using AtomPub is necessarily a good idea. AtomPub was not designed for use with CORS. If you're going to use technologies inappropriately then sure, you'll have security problems. but you can't use any RESTful with CORS because it strips Location, Content-Location etc Perfectly secure to have /admin/ accessing /data/ or HTTP through to HTTPS for POST etc I agree CORS is needed, but the imho the UMP headers [1] really needed added (if not just the Uniform-Headers [1] http://dev.w3.org/2006/waf/UMP/#response-header-filtering Best, Nathan
Re: UMP / CORS: Implementor Interest
On Wed, 12 May 2010, Tyler Close wrote: > > > >> It is also not a question of opinion, but fact. CORS uses ambient > >> authority for access control in 3 party scenarios. CORS is therefore > >> vulnerable to Confused Deputy. > > > > That's like saying that HTML uses markup and is therefore vulnerable > > to markup injection. It's a vast oversimplification and overstatement > > of the problem. > > Is it really? XSS is a major problem. HTML provides no facility for > dealing with XSS and practically invites it. It's hard to deal with this > situation now since HTML is so widely deployed. CORS invites Confused > Deputy problems but is not yet widely deployed. We can still do > something about it. HTML's use of markup is not a vulnerability. CORS's use of ambient authority is not a vulnerability. Sure, both can be used in vulnerable ways, but they are not themselves vulnerabilities. > > It is quite possible to write perfectly safe n-party apps. > > It is also quite possible to stand on your head while riding a bicycle. > What's your point? My point is that you are arguing that one design is less good than another, but you are using words that make it sound like you are arguing that one design is actually intrinsicly vulnerable. It's just as possible to make bad designs using UMP than with CORS. (I would argue that UMP actually makes it more likely that designs will have poor security characteristics since it ends up being easier to ask for the user's credentials directly than doing the right thing. With CORS, on the other hand, it's easier to use the user's existing session, so it's less likely that people will ask for credentials inappropriately.) > No one has laid out a clear strategy for developers to follow to use > CORS safely and shown how to apply it to expected use cases. What use cases would you like examples for? Let's write them up and give them to Anne to the introduction section. > The CORS spec doesn't even mention Confused Deputy problems. I'm sure Anne would be happy to include suitable text if you provide it. However, such text has to be accurate, and not make false claims like saying that there is a security vulnerability where there is only the potential for one when the feature is misused. > >> > It is certainly possible to mis-use CORS in insecure ways, but then > >> > it's also possible to mis-use UMP in insecure ways. > > You could justify any kind of security weakness with that kind of logic. > Nuclear waste can be used in insecure ways, but then so can hammers. No. There is a _massive_ difference between features that _may_ be misused, and features that _cannot be used safely_. For example, if XHR let you read data from any site without any sort of server opt-in, that would be a real security vulnerability, and could not be defended by saying "it's possible to mis-use it". It is possible to use CORS safely. > We've gone through several scenarios on this list where this validation > is not feasible. On the chromium list, I recently explained how it is > not possible to implement a generic AtomPub client that does this > validation: > > http://groups.google.com/a/chromium.org/group/chromium-dev/msg/afda9a4d1d1a4fcb I don't think using AtomPub is necessarily a good idea. AtomPub was not designed for use with CORS. If you're going to use technologies inappropriately then sure, you'll have security problems. > Others on this list have agreed that doing this checking is not always > possible. It's possible to design systems that can't be made secure, whether using CORS or UMP. But there the vulnerability is with that software, not with the underlying technology. On Wed, 12 May 2010, Dirk Pranke wrote: > > > > There's clearly not complete consensus since at least I disagree. > > I'm trying to understand what you mean by this. Are you saying that CORS > doesn't ever have Confused Deputy vulnerabilities? Or that it didn't > create new ones? Or that the vulnerabilities exist but aren't "subtle > but severe"? I'm saying that CORS doesn't ever have Confused Deputy vulnerabilities, it's software that misuses CORS that has them; just like HTML doesn't ever have markup injection vulnerabilities, it's the software that embeds user content without verifying it that has those. The guidelines for not falling prey to these attacks with CORS are pretty simple: don't do things on behalf of other origins, or include data from other origins without verifying the data. It's actually the same conceptual problem as markup injection -- you have to validate the data that you're given (e.g. escaping it) before infusing it with your authority. You have to design your systems from the ground up to be secure, but that's nothing new. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 5:36 PM, Dirk Pranke wrote: > On Wed, May 12, 2010 at 5:15 PM, Tyler Close wrote: >> On Wed, May 12, 2010 at 5:07 PM, Adam Barth wrote: >>> On Wed, May 12, 2010 at 4:56 PM, Tyler Close wrote: Both Adam and Dirk understood correctly. Ideally, I'd like an actual CORS example to work on, since I'd have to make analogies with postMessage(), and I've already made a ton of analogies, apparently to little effect. If people don't fully appreciate the relationship between based CSRF and CORS based Confused Deputy, then we need an actual CORS application. Out of curiosity, who are the 3 parties involved in the facebook chat example? The little chat widget in the corner of the facebook page looks like a same origin application. >>> >>> Facebook uses a lot of different domains for different purposes. I >>> don't have a complete count, but at least a dozen. The chat feature >>> itself uses a bunch, possibly to get around various connection limits >>> in browsers. >> >> This doesn't seem like a good example then, since the attacker would >> have to be facebook itself. For robustness, I personally consider >> these scenarios when designing an application, but people on this list >> might not find it compelling. They might also argue that no attempt >> was made to protect against such a vulnerability. >> >>> Keep in mind that the browser's notion of an origin is often much >>> smaller than a single application, which is part of the reason web >>> developers are so keen on CORS. Many of them plan to use it only to >>> talk to trusted hosts without having to use goofy things like JSONP. >> >> Enabling this scenario is a fine thing, but it's not the scenario we >> should be using to test the security properties of CORS. UMP also >> enables communication between fully trusted participants. > > It seems like a fine scenario to me. We know people want to use CORS > for this purpose because it makes their code easier and cleaner (both > of which are nice security things in and of themselves). If both CORS > and UMP are secure for this use case, then an interesting question is, > which is easier to use? This is particularly relevant insofar as if > the existing JSONP-based solution uses cookies, since CORS would > support this but UMP wouldn't (meaning the degree of rework in the app > necessary to support the code would be higher). > > Note that I am not saying that this should be the only scenario to be > reviewed, but you shouldn't just pick and choose the cases that best > fit your hypothesis. Over the course of this discussion, I've taken every use-case, with every arbitrary constraint that anyone wants to add and shown a corresponding UMP solution, so it is grossly unfair to accuse me of picking and choosing cases. For this particular discussion, we were explicitly looking for an example of a Confused Deputy vulnerability in an actual CORS application. Such a thing doesn't exist in a scenario with only 2 parties and no attacker. When testing security properties, you need an attacker. All that said, if you want to compare the usability of CORS and UMP in a 2 party interaction between fully trusted participants, we can do that. Go ahead and sketch out the challenge problem and corresponding CORS solution. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 5:15 PM, Tyler Close wrote: > On Wed, May 12, 2010 at 5:07 PM, Adam Barth wrote: >> On Wed, May 12, 2010 at 4:56 PM, Tyler Close wrote: >>> On Wed, May 12, 2010 at 4:45 PM, Adam Barth wrote: On Wed, May 12, 2010 at 4:38 PM, Dirk Pranke wrote: > On Wed, May 12, 2010 at 4:06 PM, Adam Barth wrote: >> On Wed, May 12, 2010 at 3:16 PM, Tyler Close >> wrote: >>> On Wed, May 12, 2010 at 1:38 PM, Jonas Sicking wrote: On Wed, May 12, 2010 at 1:31 PM, Tyler Close wrote: > On Wed, May 12, 2010 at 1:13 PM, Jonas Sicking > wrote: >> On Wed, May 12, 2010 at 12:38 PM, Devdatta >> wrote: >>> While most of the discussion in this thread is just repeats of >>> previous discussions, I think Tyler makes a good (and new) point in >>> that the current CORS draft still has no mention of the possible >>> security problems that Tyler talks about. The current draft's >>> security >>> section >>> >>> http://dev.w3.org/2006/waf/access-control/#security >>> >>> is ridiculous considering the amount of discussion that has taken >>> place on this issue on this mailing list. >>> >>> Before going to rec, I believe Anne needs to substantially improve >>> this section - based on stuff from maybe Maciej's presentation - >>> which >>> I found really informative. He could also cite UMP as a possible >>> option for those worried about security. >> >> I agree that the security section in CORS needs to be improved. >> >> As for the "should CORS exist" discussion, I'll bow out of those >> until >> we're starting to move towards officially adopting a WG decision one >> way or another, or genuinely new information is provided which would >> affect such a decision (for the record, I don't think I've seen any >> new information provided since last fall's TPAC). > > A smart guy once told me that "You can't tell people anything", > meaning they have to experience it for themselves before they really > get it. Has Mozilla tried to build anything non-trivial using CORS > where cookies + Origin are the access control mechanism? If so, I'll > do a security review of it and we'll see what we learn. Not to my knowledge, no. I believe we use CORS for tinderboxpushlog [1], however since that is only dealing with public data I don't believe it uses cookies or Origin headers. >>> >>> Does anyone have something? >> >> At the risk of getting myself involved in this discussion again, you >> might consider doing a security analysis of Facebook Chat. Although >> Facebook Chat uses postMessage, it uses both cookies and postMessage's >> origin property for authentication, so it might be a system of the >> kind you're interested in analyzing. >> > > I think (although I'm not certain) that Tyler is asking partially to > figure out where a non-anonymous CORS request is used in the real > world. If he isn't, then I am :) > > Given that a major (but not the only) claim of the need to adopt CORS > with support for cookies and the Origin header is that it is in fact > already implemented and shipping, it would be good to see how it's > being used. If we can't find any examples of it being used (in the > non-anonymous case, at least), then the argument against us having to > keep it would hold less water. If we can find it being used, then we > can see both how we would handle the case with UMP, and whether or not > the CORS usage is in fact secure. Oh, I misunderstood. I thought he wanted to do a security review to show that there was a confused deputy causing problems. >>> >>> Both Adam and Dirk understood correctly. Ideally, I'd like an actual >>> CORS example to work on, since I'd have to make analogies with >>> postMessage(), and I've already made a ton of analogies, apparently to >>> little effect. If people don't fully appreciate the relationship >>> between based CSRF and CORS based Confused Deputy, then we need >>> an actual CORS application. >>> >>> Out of curiosity, who are the 3 parties involved in the facebook chat >>> example? The little chat widget in the corner of the facebook page >>> looks like a same origin application. >> >> Facebook uses a lot of different domains for different purposes. I >> don't have a complete count, but at least a dozen. The chat feature >> itself uses a bunch, possibly to get around various connection limits >> in browsers. > > This doesn't seem like a good example then, since the attacker would > have to be facebook itself. For robustness, I personally consider > these scenarios when designing an application, but people on this list
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 5:07 PM, Adam Barth wrote: > On Wed, May 12, 2010 at 4:56 PM, Tyler Close wrote: >> On Wed, May 12, 2010 at 4:45 PM, Adam Barth wrote: >>> On Wed, May 12, 2010 at 4:38 PM, Dirk Pranke wrote: On Wed, May 12, 2010 at 4:06 PM, Adam Barth wrote: > On Wed, May 12, 2010 at 3:16 PM, Tyler Close > wrote: >> On Wed, May 12, 2010 at 1:38 PM, Jonas Sicking wrote: >>> On Wed, May 12, 2010 at 1:31 PM, Tyler Close >>> wrote: On Wed, May 12, 2010 at 1:13 PM, Jonas Sicking wrote: > On Wed, May 12, 2010 at 12:38 PM, Devdatta > wrote: >> While most of the discussion in this thread is just repeats of >> previous discussions, I think Tyler makes a good (and new) point in >> that the current CORS draft still has no mention of the possible >> security problems that Tyler talks about. The current draft's >> security >> section >> >> http://dev.w3.org/2006/waf/access-control/#security >> >> is ridiculous considering the amount of discussion that has taken >> place on this issue on this mailing list. >> >> Before going to rec, I believe Anne needs to substantially improve >> this section - based on stuff from maybe Maciej's presentation - >> which >> I found really informative. He could also cite UMP as a possible >> option for those worried about security. > > I agree that the security section in CORS needs to be improved. > > As for the "should CORS exist" discussion, I'll bow out of those until > we're starting to move towards officially adopting a WG decision one > way or another, or genuinely new information is provided which would > affect such a decision (for the record, I don't think I've seen any > new information provided since last fall's TPAC). A smart guy once told me that "You can't tell people anything", meaning they have to experience it for themselves before they really get it. Has Mozilla tried to build anything non-trivial using CORS where cookies + Origin are the access control mechanism? If so, I'll do a security review of it and we'll see what we learn. >>> >>> Not to my knowledge, no. I believe we use CORS for tinderboxpushlog >>> [1], however since that is only dealing with public data I don't >>> believe it uses cookies or Origin headers. >> >> Does anyone have something? > > At the risk of getting myself involved in this discussion again, you > might consider doing a security analysis of Facebook Chat. Although > Facebook Chat uses postMessage, it uses both cookies and postMessage's > origin property for authentication, so it might be a system of the > kind you're interested in analyzing. > I think (although I'm not certain) that Tyler is asking partially to figure out where a non-anonymous CORS request is used in the real world. If he isn't, then I am :) Given that a major (but not the only) claim of the need to adopt CORS with support for cookies and the Origin header is that it is in fact already implemented and shipping, it would be good to see how it's being used. If we can't find any examples of it being used (in the non-anonymous case, at least), then the argument against us having to keep it would hold less water. If we can find it being used, then we can see both how we would handle the case with UMP, and whether or not the CORS usage is in fact secure. >>> >>> Oh, I misunderstood. I thought he wanted to do a security review to >>> show that there was a confused deputy causing problems. >> >> Both Adam and Dirk understood correctly. Ideally, I'd like an actual >> CORS example to work on, since I'd have to make analogies with >> postMessage(), and I've already made a ton of analogies, apparently to >> little effect. If people don't fully appreciate the relationship >> between based CSRF and CORS based Confused Deputy, then we need >> an actual CORS application. >> >> Out of curiosity, who are the 3 parties involved in the facebook chat >> example? The little chat widget in the corner of the facebook page >> looks like a same origin application. > > Facebook uses a lot of different domains for different purposes. I > don't have a complete count, but at least a dozen. The chat feature > itself uses a bunch, possibly to get around various connection limits > in browsers. This doesn't seem like a good example then, since the attacker would have to be facebook itself. For robustness, I personally consider these scenarios when designing an application, but people on this list might not find it compelling. They might also argue that no attempt was made to protect against such a vulnerability. > Keep in mind that the browser's notion of
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 4:56 PM, Tyler Close wrote: > On Wed, May 12, 2010 at 4:45 PM, Adam Barth wrote: >> On Wed, May 12, 2010 at 4:38 PM, Dirk Pranke wrote: >>> On Wed, May 12, 2010 at 4:06 PM, Adam Barth wrote: On Wed, May 12, 2010 at 3:16 PM, Tyler Close wrote: > On Wed, May 12, 2010 at 1:38 PM, Jonas Sicking wrote: >> On Wed, May 12, 2010 at 1:31 PM, Tyler Close >> wrote: >>> On Wed, May 12, 2010 at 1:13 PM, Jonas Sicking wrote: On Wed, May 12, 2010 at 12:38 PM, Devdatta wrote: > While most of the discussion in this thread is just repeats of > previous discussions, I think Tyler makes a good (and new) point in > that the current CORS draft still has no mention of the possible > security problems that Tyler talks about. The current draft's security > section > > http://dev.w3.org/2006/waf/access-control/#security > > is ridiculous considering the amount of discussion that has taken > place on this issue on this mailing list. > > Before going to rec, I believe Anne needs to substantially improve > this section - based on stuff from maybe Maciej's presentation - which > I found really informative. He could also cite UMP as a possible > option for those worried about security. I agree that the security section in CORS needs to be improved. As for the "should CORS exist" discussion, I'll bow out of those until we're starting to move towards officially adopting a WG decision one way or another, or genuinely new information is provided which would affect such a decision (for the record, I don't think I've seen any new information provided since last fall's TPAC). >>> >>> A smart guy once told me that "You can't tell people anything", >>> meaning they have to experience it for themselves before they really >>> get it. Has Mozilla tried to build anything non-trivial using CORS >>> where cookies + Origin are the access control mechanism? If so, I'll >>> do a security review of it and we'll see what we learn. >> >> Not to my knowledge, no. I believe we use CORS for tinderboxpushlog >> [1], however since that is only dealing with public data I don't >> believe it uses cookies or Origin headers. > > Does anyone have something? At the risk of getting myself involved in this discussion again, you might consider doing a security analysis of Facebook Chat. Although Facebook Chat uses postMessage, it uses both cookies and postMessage's origin property for authentication, so it might be a system of the kind you're interested in analyzing. >>> >>> I think (although I'm not certain) that Tyler is asking partially to >>> figure out where a non-anonymous CORS request is used in the real >>> world. If he isn't, then I am :) >>> >>> Given that a major (but not the only) claim of the need to adopt CORS >>> with support for cookies and the Origin header is that it is in fact >>> already implemented and shipping, it would be good to see how it's >>> being used. If we can't find any examples of it being used (in the >>> non-anonymous case, at least), then the argument against us having to >>> keep it would hold less water. If we can find it being used, then we >>> can see both how we would handle the case with UMP, and whether or not >>> the CORS usage is in fact secure. >> >> Oh, I misunderstood. I thought he wanted to do a security review to >> show that there was a confused deputy causing problems. > > Both Adam and Dirk understood correctly. Ideally, I'd like an actual > CORS example to work on, since I'd have to make analogies with > postMessage(), and I've already made a ton of analogies, apparently to > little effect. If people don't fully appreciate the relationship > between based CSRF and CORS based Confused Deputy, then we need > an actual CORS application. > > Out of curiosity, who are the 3 parties involved in the facebook chat > example? The little chat widget in the corner of the facebook page > looks like a same origin application. Facebook uses a lot of different domains for different purposes. I don't have a complete count, but at least a dozen. The chat feature itself uses a bunch, possibly to get around various connection limits in browsers. Keep in mind that the browser's notion of an origin is often much smaller than a single application, which is part of the reason web developers are so keen on CORS. Many of them plan to use it only to talk to trusted hosts without having to use goofy things like JSONP. Adam
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 4:45 PM, Adam Barth wrote: > On Wed, May 12, 2010 at 4:38 PM, Dirk Pranke wrote: >> On Wed, May 12, 2010 at 4:06 PM, Adam Barth wrote: >>> On Wed, May 12, 2010 at 3:16 PM, Tyler Close wrote: On Wed, May 12, 2010 at 1:38 PM, Jonas Sicking wrote: > On Wed, May 12, 2010 at 1:31 PM, Tyler Close > wrote: >> On Wed, May 12, 2010 at 1:13 PM, Jonas Sicking wrote: >>> On Wed, May 12, 2010 at 12:38 PM, Devdatta wrote: While most of the discussion in this thread is just repeats of previous discussions, I think Tyler makes a good (and new) point in that the current CORS draft still has no mention of the possible security problems that Tyler talks about. The current draft's security section http://dev.w3.org/2006/waf/access-control/#security is ridiculous considering the amount of discussion that has taken place on this issue on this mailing list. Before going to rec, I believe Anne needs to substantially improve this section - based on stuff from maybe Maciej's presentation - which I found really informative. He could also cite UMP as a possible option for those worried about security. >>> >>> I agree that the security section in CORS needs to be improved. >>> >>> As for the "should CORS exist" discussion, I'll bow out of those until >>> we're starting to move towards officially adopting a WG decision one >>> way or another, or genuinely new information is provided which would >>> affect such a decision (for the record, I don't think I've seen any >>> new information provided since last fall's TPAC). >> >> A smart guy once told me that "You can't tell people anything", >> meaning they have to experience it for themselves before they really >> get it. Has Mozilla tried to build anything non-trivial using CORS >> where cookies + Origin are the access control mechanism? If so, I'll >> do a security review of it and we'll see what we learn. > > Not to my knowledge, no. I believe we use CORS for tinderboxpushlog > [1], however since that is only dealing with public data I don't > believe it uses cookies or Origin headers. Does anyone have something? >>> >>> At the risk of getting myself involved in this discussion again, you >>> might consider doing a security analysis of Facebook Chat. Although >>> Facebook Chat uses postMessage, it uses both cookies and postMessage's >>> origin property for authentication, so it might be a system of the >>> kind you're interested in analyzing. >>> >> >> I think (although I'm not certain) that Tyler is asking partially to >> figure out where a non-anonymous CORS request is used in the real >> world. If he isn't, then I am :) >> >> Given that a major (but not the only) claim of the need to adopt CORS >> with support for cookies and the Origin header is that it is in fact >> already implemented and shipping, it would be good to see how it's >> being used. If we can't find any examples of it being used (in the >> non-anonymous case, at least), then the argument against us having to >> keep it would hold less water. If we can find it being used, then we >> can see both how we would handle the case with UMP, and whether or not >> the CORS usage is in fact secure. > > Oh, I misunderstood. I thought he wanted to do a security review to > show that there was a confused deputy causing problems. Both Adam and Dirk understood correctly. Ideally, I'd like an actual CORS example to work on, since I'd have to make analogies with postMessage(), and I've already made a ton of analogies, apparently to little effect. If people don't fully appreciate the relationship between based CSRF and CORS based Confused Deputy, then we need an actual CORS application. Out of curiosity, who are the 3 parties involved in the facebook chat example? The little chat widget in the corner of the facebook page looks like a same origin application. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 4:45 PM, Adam Barth wrote: > On Wed, May 12, 2010 at 4:38 PM, Dirk Pranke wrote: >> On Wed, May 12, 2010 at 4:06 PM, Adam Barth wrote: >>> On Wed, May 12, 2010 at 3:16 PM, Tyler Close wrote: On Wed, May 12, 2010 at 1:38 PM, Jonas Sicking wrote: > On Wed, May 12, 2010 at 1:31 PM, Tyler Close > wrote: >> On Wed, May 12, 2010 at 1:13 PM, Jonas Sicking wrote: >>> On Wed, May 12, 2010 at 12:38 PM, Devdatta wrote: While most of the discussion in this thread is just repeats of previous discussions, I think Tyler makes a good (and new) point in that the current CORS draft still has no mention of the possible security problems that Tyler talks about. The current draft's security section http://dev.w3.org/2006/waf/access-control/#security is ridiculous considering the amount of discussion that has taken place on this issue on this mailing list. Before going to rec, I believe Anne needs to substantially improve this section - based on stuff from maybe Maciej's presentation - which I found really informative. He could also cite UMP as a possible option for those worried about security. >>> >>> I agree that the security section in CORS needs to be improved. >>> >>> As for the "should CORS exist" discussion, I'll bow out of those until >>> we're starting to move towards officially adopting a WG decision one >>> way or another, or genuinely new information is provided which would >>> affect such a decision (for the record, I don't think I've seen any >>> new information provided since last fall's TPAC). >> >> A smart guy once told me that "You can't tell people anything", >> meaning they have to experience it for themselves before they really >> get it. Has Mozilla tried to build anything non-trivial using CORS >> where cookies + Origin are the access control mechanism? If so, I'll >> do a security review of it and we'll see what we learn. > > Not to my knowledge, no. I believe we use CORS for tinderboxpushlog > [1], however since that is only dealing with public data I don't > believe it uses cookies or Origin headers. Does anyone have something? >>> >>> At the risk of getting myself involved in this discussion again, you >>> might consider doing a security analysis of Facebook Chat. Although >>> Facebook Chat uses postMessage, it uses both cookies and postMessage's >>> origin property for authentication, so it might be a system of the >>> kind you're interested in analyzing. >>> >> >> I think (although I'm not certain) that Tyler is asking partially to >> figure out where a non-anonymous CORS request is used in the real >> world. If he isn't, then I am :) >> >> Given that a major (but not the only) claim of the need to adopt CORS >> with support for cookies and the Origin header is that it is in fact >> already implemented and shipping, it would be good to see how it's >> being used. If we can't find any examples of it being used (in the >> non-anonymous case, at least), then the argument against us having to >> keep it would hold less water. If we can find it being used, then we >> can see both how we would handle the case with UMP, and whether or not >> the CORS usage is in fact secure. > > Oh, I misunderstood. I thought he wanted to do a security review to > show that there was a confused deputy causing problems. > I think that's part of the same thing (the "whether or not the CORS usage is in fact secure part" of my note). -- Dirk
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 4:38 PM, Dirk Pranke wrote: > On Wed, May 12, 2010 at 4:06 PM, Adam Barth wrote: >> On Wed, May 12, 2010 at 3:16 PM, Tyler Close wrote: >>> On Wed, May 12, 2010 at 1:38 PM, Jonas Sicking wrote: On Wed, May 12, 2010 at 1:31 PM, Tyler Close wrote: > On Wed, May 12, 2010 at 1:13 PM, Jonas Sicking wrote: >> On Wed, May 12, 2010 at 12:38 PM, Devdatta wrote: >>> While most of the discussion in this thread is just repeats of >>> previous discussions, I think Tyler makes a good (and new) point in >>> that the current CORS draft still has no mention of the possible >>> security problems that Tyler talks about. The current draft's security >>> section >>> >>> http://dev.w3.org/2006/waf/access-control/#security >>> >>> is ridiculous considering the amount of discussion that has taken >>> place on this issue on this mailing list. >>> >>> Before going to rec, I believe Anne needs to substantially improve >>> this section - based on stuff from maybe Maciej's presentation - which >>> I found really informative. He could also cite UMP as a possible >>> option for those worried about security. >> >> I agree that the security section in CORS needs to be improved. >> >> As for the "should CORS exist" discussion, I'll bow out of those until >> we're starting to move towards officially adopting a WG decision one >> way or another, or genuinely new information is provided which would >> affect such a decision (for the record, I don't think I've seen any >> new information provided since last fall's TPAC). > > A smart guy once told me that "You can't tell people anything", > meaning they have to experience it for themselves before they really > get it. Has Mozilla tried to build anything non-trivial using CORS > where cookies + Origin are the access control mechanism? If so, I'll > do a security review of it and we'll see what we learn. Not to my knowledge, no. I believe we use CORS for tinderboxpushlog [1], however since that is only dealing with public data I don't believe it uses cookies or Origin headers. >>> >>> Does anyone have something? >> >> At the risk of getting myself involved in this discussion again, you >> might consider doing a security analysis of Facebook Chat. Although >> Facebook Chat uses postMessage, it uses both cookies and postMessage's >> origin property for authentication, so it might be a system of the >> kind you're interested in analyzing. >> > > I think (although I'm not certain) that Tyler is asking partially to > figure out where a non-anonymous CORS request is used in the real > world. If he isn't, then I am :) > > Given that a major (but not the only) claim of the need to adopt CORS > with support for cookies and the Origin header is that it is in fact > already implemented and shipping, it would be good to see how it's > being used. If we can't find any examples of it being used (in the > non-anonymous case, at least), then the argument against us having to > keep it would hold less water. If we can find it being used, then we > can see both how we would handle the case with UMP, and whether or not > the CORS usage is in fact secure. Oh, I misunderstood. I thought he wanted to do a security review to show that there was a confused deputy causing problems. Adam
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 4:06 PM, Adam Barth wrote: > On Wed, May 12, 2010 at 3:16 PM, Tyler Close wrote: >> On Wed, May 12, 2010 at 1:38 PM, Jonas Sicking wrote: >>> On Wed, May 12, 2010 at 1:31 PM, Tyler Close wrote: On Wed, May 12, 2010 at 1:13 PM, Jonas Sicking wrote: > On Wed, May 12, 2010 at 12:38 PM, Devdatta wrote: >> While most of the discussion in this thread is just repeats of >> previous discussions, I think Tyler makes a good (and new) point in >> that the current CORS draft still has no mention of the possible >> security problems that Tyler talks about. The current draft's security >> section >> >> http://dev.w3.org/2006/waf/access-control/#security >> >> is ridiculous considering the amount of discussion that has taken >> place on this issue on this mailing list. >> >> Before going to rec, I believe Anne needs to substantially improve >> this section - based on stuff from maybe Maciej's presentation - which >> I found really informative. He could also cite UMP as a possible >> option for those worried about security. > > I agree that the security section in CORS needs to be improved. > > As for the "should CORS exist" discussion, I'll bow out of those until > we're starting to move towards officially adopting a WG decision one > way or another, or genuinely new information is provided which would > affect such a decision (for the record, I don't think I've seen any > new information provided since last fall's TPAC). A smart guy once told me that "You can't tell people anything", meaning they have to experience it for themselves before they really get it. Has Mozilla tried to build anything non-trivial using CORS where cookies + Origin are the access control mechanism? If so, I'll do a security review of it and we'll see what we learn. >>> >>> Not to my knowledge, no. I believe we use CORS for tinderboxpushlog >>> [1], however since that is only dealing with public data I don't >>> believe it uses cookies or Origin headers. >> >> Does anyone have something? > > At the risk of getting myself involved in this discussion again, you > might consider doing a security analysis of Facebook Chat. Although > Facebook Chat uses postMessage, it uses both cookies and postMessage's > origin property for authentication, so it might be a system of the > kind you're interested in analyzing. > I think (although I'm not certain) that Tyler is asking partially to figure out where a non-anonymous CORS request is used in the real world. If he isn't, then I am :) Given that a major (but not the only) claim of the need to adopt CORS with support for cookies and the Origin header is that it is in fact already implemented and shipping, it would be good to see how it's being used. If we can't find any examples of it being used (in the non-anonymous case, at least), then the argument against us having to keep it would hold less water. If we can find it being used, then we can see both how we would handle the case with UMP, and whether or not the CORS usage is in fact secure. -- Dirk
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 3:16 PM, Tyler Close wrote: > On Wed, May 12, 2010 at 1:38 PM, Jonas Sicking wrote: >> On Wed, May 12, 2010 at 1:31 PM, Tyler Close wrote: >>> On Wed, May 12, 2010 at 1:13 PM, Jonas Sicking wrote: On Wed, May 12, 2010 at 12:38 PM, Devdatta wrote: > While most of the discussion in this thread is just repeats of > previous discussions, I think Tyler makes a good (and new) point in > that the current CORS draft still has no mention of the possible > security problems that Tyler talks about. The current draft's security > section > > http://dev.w3.org/2006/waf/access-control/#security > > is ridiculous considering the amount of discussion that has taken > place on this issue on this mailing list. > > Before going to rec, I believe Anne needs to substantially improve > this section - based on stuff from maybe Maciej's presentation - which > I found really informative. He could also cite UMP as a possible > option for those worried about security. I agree that the security section in CORS needs to be improved. As for the "should CORS exist" discussion, I'll bow out of those until we're starting to move towards officially adopting a WG decision one way or another, or genuinely new information is provided which would affect such a decision (for the record, I don't think I've seen any new information provided since last fall's TPAC). >>> >>> A smart guy once told me that "You can't tell people anything", >>> meaning they have to experience it for themselves before they really >>> get it. Has Mozilla tried to build anything non-trivial using CORS >>> where cookies + Origin are the access control mechanism? If so, I'll >>> do a security review of it and we'll see what we learn. >> >> Not to my knowledge, no. I believe we use CORS for tinderboxpushlog >> [1], however since that is only dealing with public data I don't >> believe it uses cookies or Origin headers. > > Does anyone have something? At the risk of getting myself involved in this discussion again, you might consider doing a security analysis of Facebook Chat. Although Facebook Chat uses postMessage, it uses both cookies and postMessage's origin property for authentication, so it might be a system of the kind you're interested in analyzing. Adam
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 1:38 PM, Jonas Sicking wrote: > On Wed, May 12, 2010 at 1:31 PM, Tyler Close wrote: >> On Wed, May 12, 2010 at 1:13 PM, Jonas Sicking wrote: >>> On Wed, May 12, 2010 at 12:38 PM, Devdatta wrote: While most of the discussion in this thread is just repeats of previous discussions, I think Tyler makes a good (and new) point in that the current CORS draft still has no mention of the possible security problems that Tyler talks about. The current draft's security section http://dev.w3.org/2006/waf/access-control/#security is ridiculous considering the amount of discussion that has taken place on this issue on this mailing list. Before going to rec, I believe Anne needs to substantially improve this section - based on stuff from maybe Maciej's presentation - which I found really informative. He could also cite UMP as a possible option for those worried about security. >>> >>> I agree that the security section in CORS needs to be improved. >>> >>> As for the "should CORS exist" discussion, I'll bow out of those until >>> we're starting to move towards officially adopting a WG decision one >>> way or another, or genuinely new information is provided which would >>> affect such a decision (for the record, I don't think I've seen any >>> new information provided since last fall's TPAC). >> >> A smart guy once told me that "You can't tell people anything", >> meaning they have to experience it for themselves before they really >> get it. Has Mozilla tried to build anything non-trivial using CORS >> where cookies + Origin are the access control mechanism? If so, I'll >> do a security review of it and we'll see what we learn. > > Not to my knowledge, no. I believe we use CORS for tinderboxpushlog > [1], however since that is only dealing with public data I don't > believe it uses cookies or Origin headers. Does anyone have something? --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
Devdatta wrote: As for the "should CORS exist" discussion, I'll bow out of those until we're starting to move towards officially adopting a WG decision one way or another, or genuinely new information is provided which would affect such a decision (for the record, I don't think I've seen any new information provided since last fall's TPAC). exactly -- I don't see this thread getting anywhere. Vendors & Spec writers, What would be really nice is if you gave us server admins, application server-side developers and data publishers a say in this. Thus I'll propose a new header: Allow-XHR = "Allow-XHR" ":" Allow-XHR-v Allow-XHR-v = "none" | "negotiate" | "all" "none" defines no XHR access "negotiate" defines the UA should negotiate CORS or UMP headers (leave that up to you guys to decide what's best ;) "all" defines that the UA should process the XHR request as a normal client HTTP request leaving all information + headers intact. Best, Nathan
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 1:31 PM, Tyler Close wrote: > On Wed, May 12, 2010 at 1:13 PM, Jonas Sicking wrote: >> On Wed, May 12, 2010 at 12:38 PM, Devdatta wrote: >>> While most of the discussion in this thread is just repeats of >>> previous discussions, I think Tyler makes a good (and new) point in >>> that the current CORS draft still has no mention of the possible >>> security problems that Tyler talks about. The current draft's security >>> section >>> >>> http://dev.w3.org/2006/waf/access-control/#security >>> >>> is ridiculous considering the amount of discussion that has taken >>> place on this issue on this mailing list. >>> >>> Before going to rec, I believe Anne needs to substantially improve >>> this section - based on stuff from maybe Maciej's presentation - which >>> I found really informative. He could also cite UMP as a possible >>> option for those worried about security. >> >> I agree that the security section in CORS needs to be improved. >> >> As for the "should CORS exist" discussion, I'll bow out of those until >> we're starting to move towards officially adopting a WG decision one >> way or another, or genuinely new information is provided which would >> affect such a decision (for the record, I don't think I've seen any >> new information provided since last fall's TPAC). > > A smart guy once told me that "You can't tell people anything", > meaning they have to experience it for themselves before they really > get it. Has Mozilla tried to build anything non-trivial using CORS > where cookies + Origin are the access control mechanism? If so, I'll > do a security review of it and we'll see what we learn. Not to my knowledge, no. I believe we use CORS for tinderboxpushlog [1], however since that is only dealing with public data I don't believe it uses cookies or Origin headers. Feel free to review it anyway. [1] http://tests.themasta.com/tinderboxpushlog/ / Jonas
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 1:13 PM, Jonas Sicking wrote: > On Wed, May 12, 2010 at 12:38 PM, Devdatta wrote: >> While most of the discussion in this thread is just repeats of >> previous discussions, I think Tyler makes a good (and new) point in >> that the current CORS draft still has no mention of the possible >> security problems that Tyler talks about. The current draft's security >> section >> >> http://dev.w3.org/2006/waf/access-control/#security >> >> is ridiculous considering the amount of discussion that has taken >> place on this issue on this mailing list. >> >> Before going to rec, I believe Anne needs to substantially improve >> this section - based on stuff from maybe Maciej's presentation - which >> I found really informative. He could also cite UMP as a possible >> option for those worried about security. > > I agree that the security section in CORS needs to be improved. > > As for the "should CORS exist" discussion, I'll bow out of those until > we're starting to move towards officially adopting a WG decision one > way or another, or genuinely new information is provided which would > affect such a decision (for the record, I don't think I've seen any > new information provided since last fall's TPAC). A smart guy once told me that "You can't tell people anything", meaning they have to experience it for themselves before they really get it. Has Mozilla tried to build anything non-trivial using CORS where cookies + Origin are the access control mechanism? If so, I'll do a security review of it and we'll see what we learn. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
> As for the "should CORS exist" discussion, I'll bow out of those until > we're starting to move towards officially adopting a WG decision one > way or another, or genuinely new information is provided which would > affect such a decision (for the record, I don't think I've seen any > new information provided since last fall's TPAC). exactly -- I don't see this thread getting anywhere. cheers devdatta On 12 May 2010 13:13, Jonas Sicking wrote: > On Wed, May 12, 2010 at 12:38 PM, Devdatta wrote: >> While most of the discussion in this thread is just repeats of >> previous discussions, I think Tyler makes a good (and new) point in >> that the current CORS draft still has no mention of the possible >> security problems that Tyler talks about. The current draft's security >> section >> >> http://dev.w3.org/2006/waf/access-control/#security >> >> is ridiculous considering the amount of discussion that has taken >> place on this issue on this mailing list. >> >> Before going to rec, I believe Anne needs to substantially improve >> this section - based on stuff from maybe Maciej's presentation - which >> I found really informative. He could also cite UMP as a possible >> option for those worried about security. > > I agree that the security section in CORS needs to be improved. > > As for the "should CORS exist" discussion, I'll bow out of those until > we're starting to move towards officially adopting a WG decision one > way or another, or genuinely new information is provided which would > affect such a decision (for the record, I don't think I've seen any > new information provided since last fall's TPAC). > > / Jonas >
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 12:38 PM, Devdatta wrote: > While most of the discussion in this thread is just repeats of > previous discussions, I think Tyler makes a good (and new) point in > that the current CORS draft still has no mention of the possible > security problems that Tyler talks about. The current draft's security > section > > http://dev.w3.org/2006/waf/access-control/#security > > is ridiculous considering the amount of discussion that has taken > place on this issue on this mailing list. > > Before going to rec, I believe Anne needs to substantially improve > this section - based on stuff from maybe Maciej's presentation - which > I found really informative. He could also cite UMP as a possible > option for those worried about security. I agree that the security section in CORS needs to be improved. As for the "should CORS exist" discussion, I'll bow out of those until we're starting to move towards officially adopting a WG decision one way or another, or genuinely new information is provided which would affect such a decision (for the record, I don't think I've seen any new information provided since last fall's TPAC). / Jonas
Re: UMP / CORS: Implementor Interest
While most of the discussion in this thread is just repeats of
previous discussions, I think Tyler makes a good (and new) point in
that the current CORS draft still has no mention of the possible
security problems that Tyler talks about. The current draft's security
section
http://dev.w3.org/2006/waf/access-control/#security
is ridiculous considering the amount of discussion that has taken
place on this issue on this mailing list.
Before going to rec, I believe Anne needs to substantially improve
this section - based on stuff from maybe Maciej's presentation - which
I found really informative. He could also cite UMP as a possible
option for those worried about security.
Cheers
devdatta
On 12 May 2010 12:26, Tyler Close wrote:
> On Wed, May 12, 2010 at 11:17 AM, Jonas Sicking wrote:
>> On Wed, May 12, 2010 at 9:01 AM, Tyler Close wrote:
>>> On Tue, May 11, 2010 at 5:15 PM, Ian Hickson wrote:
On Tue, 11 May 2010, Tyler Close wrote:
>
> CORS introduces subtle but severe Confused Deputy vulnerabilities
I don't think everyone is convinced that this is the case.
>>>
>>> AFAICT, there is consensus that CORS has Confused Deputy
>>> vulnerabilities. I can pull up email quotes from almost everyone
>>> involved in the conversation.
>>>
>>> It is also not a question of opinion, but fact. CORS uses ambient
>>> authority for access control in 3 party scenarios. CORS is therefore
>>> vulnerable to Confused Deputy.
>>
>> First I should note that I have no idea what this argument is trying
>> to result in. Is this an attempt at preventing CORS from going to REC?
>> Or are we just rat holing old discussions?
>>
>> That said, I feel like I don't want to let the above claim go
>> unanswered. Like Ian, I think you are oversimplifying the situation. I
>> would argue that UMP risks resulting in the same confused deputy
>> problems as CORS in the same complex scenarios where CORS risks
>> confused deputy problems.
>>
>> With an UMP based web application it seems like a big risk that people
>> will create APIs like:
>>
>> function fetchResource(uri, successCallback) {
>> req = new UMPOrWhateverWellCallItRequest();
>> uri += "&securityToken=" + gSecurityToken;
>> req.open("GET", uri);
>> req.send();
>> req.onload = function() { successCallback(req.responseText) };
>> }
>>
>> Such code risks suffering from the exact same confused deputy problems
>> as CORS.
>
> To paraphrase: "Developers might build something that is broken in the
> following way; therefore, we should give them something that is
> already broken in that way."
>
>> My concern with UMP is that it takes no responsibility for
>> the security model and instead puts all responsibility on web sites.
>
> The UMP spec does go to significant lengths to show developers how to
> do things the right way and why. The Security Considerations section
> provides a straightforward model for safely using UMP. CORS has
> nothing similar.
>
>> I'm not convinced this will result in increased security on the web,
>> just the ability for UAs to hide behind arguments like "it's not our
>> fault that the website has a bug".
>
> The best we can do is provide good tools and show people how to use
> them. CORS is a tool with known problems and no instructions on safe
> use.
>
>> I don't see why we couldn't just give websites the ability to use
>> either security model and stop wasting time reiterating old
>> discussions.
>
> I just don't understand why we want to deploy a broken security model.
>
> --Tyler
>
> --
> "Waterken News: Capability security on the Web"
> http://waterken.sourceforge.net/recent.html
>
>
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 11:17 AM, Jonas Sicking wrote:
> On Wed, May 12, 2010 at 9:01 AM, Tyler Close wrote:
>> On Tue, May 11, 2010 at 5:15 PM, Ian Hickson wrote:
>>> On Tue, 11 May 2010, Tyler Close wrote:
CORS introduces subtle but severe Confused Deputy vulnerabilities
>>>
>>> I don't think everyone is convinced that this is the case.
>>
>> AFAICT, there is consensus that CORS has Confused Deputy
>> vulnerabilities. I can pull up email quotes from almost everyone
>> involved in the conversation.
>>
>> It is also not a question of opinion, but fact. CORS uses ambient
>> authority for access control in 3 party scenarios. CORS is therefore
>> vulnerable to Confused Deputy.
>
> First I should note that I have no idea what this argument is trying
> to result in. Is this an attempt at preventing CORS from going to REC?
> Or are we just rat holing old discussions?
>
> That said, I feel like I don't want to let the above claim go
> unanswered. Like Ian, I think you are oversimplifying the situation. I
> would argue that UMP risks resulting in the same confused deputy
> problems as CORS in the same complex scenarios where CORS risks
> confused deputy problems.
>
> With an UMP based web application it seems like a big risk that people
> will create APIs like:
>
> function fetchResource(uri, successCallback) {
> req = new UMPOrWhateverWellCallItRequest();
> uri += "&securityToken=" + gSecurityToken;
> req.open("GET", uri);
> req.send();
> req.onload = function() { successCallback(req.responseText) };
> }
>
> Such code risks suffering from the exact same confused deputy problems
> as CORS.
To paraphrase: "Developers might build something that is broken in the
following way; therefore, we should give them something that is
already broken in that way."
> My concern with UMP is that it takes no responsibility for
> the security model and instead puts all responsibility on web sites.
The UMP spec does go to significant lengths to show developers how to
do things the right way and why. The Security Considerations section
provides a straightforward model for safely using UMP. CORS has
nothing similar.
> I'm not convinced this will result in increased security on the web,
> just the ability for UAs to hide behind arguments like "it's not our
> fault that the website has a bug".
The best we can do is provide good tools and show people how to use
them. CORS is a tool with known problems and no instructions on safe
use.
> I don't see why we couldn't just give websites the ability to use
> either security model and stop wasting time reiterating old
> discussions.
I just don't understand why we want to deploy a broken security model.
--Tyler
--
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 11:42 AM, Jonas Sicking wrote: > On Wed, May 12, 2010 at 11:35 AM, Tyler Close wrote: >> On Wed, May 12, 2010 at 11:21 AM, Ojan Vafai wrote: >>> On Wed, May 12, 2010 at 9:01 AM, Tyler Close wrote: In the general case, including many common cases, doing this validation is not feasible. The CORS specification should not be allowed to proceed through standardization without providing developers a robust solution to this problem. CORS is a new protocol and the WG has been made aware of the security issue before applications have become widely dependent upon it. The WG cannot responsibly proceed with CORS as is. >>> >>> Clearly there is a fundamental philosophical difference here. The end result >>> is pretty clear: >>> 1. Every implementor except Caja is implementing CORS and prefers a unified >>> CORS/UMP spec. >> >> IE does not currently implement the disputed sections of CORS. I don't >> know what their plans are. Without IE support, the disputed sections >> of CORS are not a viable option for developers. > > Really? As far as I know IE sends the "Origin" header which as I > understood it was a major source of the confused deputy problem and a > big reason for drafting the UMP spec? Yes, IE does implement one disputed feature. I'm just pointing out that much of the disputed text is not widely deployed, despite claims to the contrary. >>> Realistically, UMP's only hope of actually getting wide adoption is if it's >>> part of the CORS spec. Can you focus on improving CORS so that it addresses >>> your concerns as much as realistically possible? >> >> UMP has had that effect on CORS and I'll continue to pursue this. I >> also want to see the bad stuff removed. > > If so, I'd really like to see the chairs move forward with making the > WG make some sort of formal decision on weather CORS should be > published or not. Repeating the same discussion over and over is not > good use your time or mine. I certainly agree that this has consumed way more time than I would like. I remain baffled that it's such a hard point to make. The purpose of CORS is to enable 3 party scenarios. Use of ambient authority in 3 party scenarios creates Confused Deputy vulnerabilities. Even simple scenarios are vulnerable if one of the parties is an attacker. I've shown how to use UMP instead for every use case anyone has brought up. At this point, my only guess is that I'm arguing against sunk cost. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 11:35 AM, Tyler Close wrote: > On Wed, May 12, 2010 at 11:21 AM, Ojan Vafai wrote: >> On Wed, May 12, 2010 at 9:01 AM, Tyler Close wrote: >>> >>> In the general case, including many common cases, doing this >>> validation is not feasible. The CORS specification should not be >>> allowed to proceed through standardization without providing >>> developers a robust solution to this problem. >>> >>> CORS is a new protocol and the WG has been made aware of the security >>> issue before applications have become widely dependent upon it. The WG >>> cannot responsibly proceed with CORS as is. >> >> Clearly there is a fundamental philosophical difference here. The end result >> is pretty clear: >> 1. Every implementor except Caja is implementing CORS and prefers a unified >> CORS/UMP spec. > > IE does not currently implement the disputed sections of CORS. I don't > know what their plans are. Without IE support, the disputed sections > of CORS are not a viable option for developers. Really? As far as I know IE sends the "Origin" header which as I understood it was a major source of the confused deputy problem and a big reason for drafting the UMP spec? >> Realistically, UMP's only hope of actually getting wide adoption is if it's >> part of the CORS spec. Can you focus on improving CORS so that it addresses >> your concerns as much as realistically possible? > > UMP has had that effect on CORS and I'll continue to pursue this. I > also want to see the bad stuff removed. If so, I'd really like to see the chairs move forward with making the WG make some sort of formal decision on weather CORS should be published or not. Repeating the same discussion over and over is not good use your time or mine. / Jonas
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 11:21 AM, Ojan Vafai wrote: > On Wed, May 12, 2010 at 9:01 AM, Tyler Close wrote: >> >> In the general case, including many common cases, doing this >> validation is not feasible. The CORS specification should not be >> allowed to proceed through standardization without providing >> developers a robust solution to this problem. >> >> CORS is a new protocol and the WG has been made aware of the security >> issue before applications have become widely dependent upon it. The WG >> cannot responsibly proceed with CORS as is. > > Clearly there is a fundamental philosophical difference here. The end result > is pretty clear: > 1. Every implementor except Caja is implementing CORS and prefers a unified > CORS/UMP spec. IE does not currently implement the disputed sections of CORS. I don't know what their plans are. Without IE support, the disputed sections of CORS are not a viable option for developers. Caja and similar technologies are unable to implement full CORS. It's not just that they don't want to. > 2. Some implementors are unwilling to implement a separate UMP spec. So CORS normatively claims to implement UMP and uses its algorithmic spec to show how. > The same arguments have been hashed out multiple times. The above is not > going to change by talking through them again. > Blocking the CORS spec on principle is meaningless at this point. Even if > the spec were not officially standardized. It's shipping in browsers. It's > not going to be taken back. Again, the disputed sections of CORS are not yet widely deployed (no IE) and so are not yet widely adopted by developers. > Realistically, UMP's only hope of actually getting wide adoption is if it's > part of the CORS spec. Can you focus on improving CORS so that it addresses > your concerns as much as realistically possible? UMP has had that effect on CORS and I'll continue to pursue this. I also want to see the bad stuff removed. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 9:01 AM, Tyler Close wrote: > In the general case, including many common cases, doing this > validation is not feasible. The CORS specification should not be > allowed to proceed through standardization without providing > developers a robust solution to this problem. > > CORS is a new protocol and the WG has been made aware of the security > issue before applications have become widely dependent upon it. The WG > cannot responsibly proceed with CORS as is. Clearly there is a fundamental philosophical difference here. The end result is pretty clear: 1. Every implementor except Caja is implementing CORS and prefers a unified CORS/UMP spec. 2. Some implementors are unwilling to implement a separate UMP spec. The same arguments have been hashed out multiple times. The above is not going to change by talking through them again. Blocking the CORS spec on principle is meaningless at this point. Even if the spec were not officially standardized. It's shipping in browsers. It's not going to be taken back. Realistically, UMP's only hope of actually getting wide adoption is if it's part of the CORS spec. Can you focus on improving CORS so that it addresses your concerns as much as realistically possible? Ojan
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 9:01 AM, Tyler Close wrote:
> On Tue, May 11, 2010 at 5:15 PM, Ian Hickson wrote:
>> On Tue, 11 May 2010, Tyler Close wrote:
>>>
>>> CORS introduces subtle but severe Confused Deputy vulnerabilities
>>
>> I don't think everyone is convinced that this is the case.
>
> AFAICT, there is consensus that CORS has Confused Deputy
> vulnerabilities. I can pull up email quotes from almost everyone
> involved in the conversation.
>
> It is also not a question of opinion, but fact. CORS uses ambient
> authority for access control in 3 party scenarios. CORS is therefore
> vulnerable to Confused Deputy.
First I should note that I have no idea what this argument is trying
to result in. Is this an attempt at preventing CORS from going to REC?
Or are we just rat holing old discussions?
That said, I feel like I don't want to let the above claim go
unanswered. Like Ian, I think you are oversimplifying the situation. I
would argue that UMP risks resulting in the same confused deputy
problems as CORS in the same complex scenarios where CORS risks
confused deputy problems.
With an UMP based web application it seems like a big risk that people
will create APIs like:
function fetchResource(uri, successCallback) {
req = new UMPOrWhateverWellCallItRequest();
uri += "&securityToken=" + gSecurityToken;
req.open("GET", uri);
req.send();
req.onload = function() { successCallback(req.responseText) };
}
Such code risks suffering from the exact same confused deputy problems
as CORS. My concern with UMP is that it takes no responsibility for
the security model and instead puts all responsibility on web sites.
I'm not convinced this will result in increased security on the web,
just the ability for UAs to hide behind arguments like "it's not our
fault that the website has a bug".
I don't see why we couldn't just give websites the ability to use
either security model and stop wasting time reiterating old
discussions.
/ Jonas
Re: UMP / CORS: Implementor Interest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/12/2010 11:39 AM, Ian Hickson wrote: > On Wed, 12 May 2010, Tyler Close wrote: >> On Tue, May 11, 2010 at 5:15 PM, Ian Hickson wrote: >>> On Tue, 11 May 2010, Tyler Close wrote: CORS introduces subtle but severe Confused Deputy vulnerabilities >>> >>> I don't think everyone is convinced that this is the case. >> >> AFAICT, there is consensus that CORS has Confused Deputy >> vulnerabilities. I can pull up email quotes from almost everyone >> involved in the conversation. > > There's clearly not complete consensus since at least I disagree. > > FWIW, I also disagree that CORS creates inappropriate unconfused deputy vulnerabilities. CORS provides a totally sufficient pathway for secure use. >> It is also not a question of opinion, but fact. CORS uses ambient >> authority for access control in 3 party scenarios. CORS is therefore >> vulnerable to Confused Deputy. > > That's like saying that HTML uses markup and is therefore vulnerable to > markup injection. It's a vast oversimplification and overstatement of the > problem. It is quite possible to write perfectly safe n-party apps. Adding to this, saying that CORS uses ambient authority doesn't make sense, CORS itself can't assign authority, owners of resources assign authority. Any reasonable usage of CORS by resource owners would not rely on interpreting headers in a way that assigns ambient authority. - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvq7T4ACgkQ9VpNnHc4zAzPBgCdF5LmRSQ0dJDXUD1D1zbwSpFB p8EAoKAdayHrhHUc11Y4DUtLatxGjwO3 =NBOT -END PGP SIGNATURE-
Re: UMP / CORS: Implementor Interest
On Wed, May 12, 2010 at 10:39 AM, Ian Hickson wrote: > On Wed, 12 May 2010, Tyler Close wrote: >> On Tue, May 11, 2010 at 5:15 PM, Ian Hickson wrote: >> > On Tue, 11 May 2010, Tyler Close wrote: >> >> >> >> CORS introduces subtle but severe Confused Deputy vulnerabilities >> > >> > I don't think everyone is convinced that this is the case. >> >> AFAICT, there is consensus that CORS has Confused Deputy >> vulnerabilities. I can pull up email quotes from almost everyone >> involved in the conversation. > > There's clearly not complete consensus since at least I disagree. > > >> It is also not a question of opinion, but fact. CORS uses ambient >> authority for access control in 3 party scenarios. CORS is therefore >> vulnerable to Confused Deputy. > > That's like saying that HTML uses markup and is therefore vulnerable to > markup injection. It's a vast oversimplification and overstatement of the > problem. Is it really? XSS is a major problem. HTML provides no facility for dealing with XSS and practically invites it. It's hard to deal with this situation now since HTML is so widely deployed. CORS invites Confused Deputy problems but is not yet widely deployed. We can still do something about it. > It is quite possible to write perfectly safe n-party apps. It is also quite possible to stand on your head while riding a bicycle. What's your point? No one has laid out a clear strategy for developers to follow to use CORS safely and shown how to apply it to expected use cases. The CORS spec doesn't even mention Confused Deputy problems. >> > It is certainly possible to mis-use CORS in insecure ways, but then >> > it's also possible to mis-use UMP in insecure ways. You could justify any kind of security weakness with that kind of logic. Nuclear waste can be used in insecure ways, but then so can hammers. >> > As far as I can >> > tell, confused deputy vulnerabilities only occur with CORS if you use >> > it in inappropriate ways, such as sharing identifiers amongst >> > different origins without properly validating that they aren't >> > spoofing each other. >> >> In the general case, including many common cases, doing this validation >> is not feasible. > > That's nonsense. We've gone through several scenarios on this list where this validation is not feasible. On the chromium list, I recently explained how it is not possible to implement a generic AtomPub client that does this validation: http://groups.google.com/a/chromium.org/group/chromium-dev/msg/afda9a4d1d1a4fcb Others on this list have agreed that doing this checking is not always possible. > You have to make sure you don't rely on identifiers to > confer authority, but that's just a matter of good design. It's the exact opposite. Using ambient authority with non-authority-bearing identifiers creates Confuse Deputy vulnerabilities. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Wed, 12 May 2010, Tyler Close wrote: > On Tue, May 11, 2010 at 5:15 PM, Ian Hickson wrote: > > On Tue, 11 May 2010, Tyler Close wrote: > >> > >> CORS introduces subtle but severe Confused Deputy vulnerabilities > > > > I don't think everyone is convinced that this is the case. > > AFAICT, there is consensus that CORS has Confused Deputy > vulnerabilities. I can pull up email quotes from almost everyone > involved in the conversation. There's clearly not complete consensus since at least I disagree. > It is also not a question of opinion, but fact. CORS uses ambient > authority for access control in 3 party scenarios. CORS is therefore > vulnerable to Confused Deputy. That's like saying that HTML uses markup and is therefore vulnerable to markup injection. It's a vast oversimplification and overstatement of the problem. It is quite possible to write perfectly safe n-party apps. > > It is certainly possible to mis-use CORS in insecure ways, but then > > it's also possible to mis-use UMP in insecure ways. As far as I can > > tell, confused deputy vulnerabilities only occur with CORS if you use > > it in inappropriate ways, such as sharing identifiers amongst > > different origins without properly validating that they aren't > > spoofing each other. > > In the general case, including many common cases, doing this validation > is not feasible. That's nonsense. You have to make sure you don't rely on identifiers to confer authority, but that's just a matter of good design. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: UMP / CORS: Implementor Interest
On Tue, May 11, 2010 at 5:15 PM, Ian Hickson wrote: > On Tue, 11 May 2010, Tyler Close wrote: >> >> CORS introduces subtle but severe Confused Deputy vulnerabilities > > I don't think everyone is convinced that this is the case. AFAICT, there is consensus that CORS has Confused Deputy vulnerabilities. I can pull up email quotes from almost everyone involved in the conversation. It is also not a question of opinion, but fact. CORS uses ambient authority for access control in 3 party scenarios. CORS is therefore vulnerable to Confused Deputy. > It is certainly > possible to mis-use CORS in insecure ways, but then it's also possible to > mis-use UMP in insecure ways. As far as I can tell, confused deputy > vulnerabilities only occur with CORS if you use it in inappropriate ways, > such as sharing identifiers amongst different origins without properly > validating that they aren't spoofing each other. In the general case, including many common cases, doing this validation is not feasible. The CORS specification should not be allowed to proceed through standardization without providing developers a robust solution to this problem. CORS is a new protocol and the WG has been made aware of the security issue before applications have become widely dependent upon it. The WG cannot responsibly proceed with CORS as is. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
Since the other points in this thread have already been addressed by others, I thought I'd just add my thoughts on this issue (renaming and response header filtering). On Tue, 11 May 2010 20:17:17 +0200, Tyler Close wrote: On Tue, May 11, 2010 at 10:54 AM, Anne van Kesteren wrote: I think we first need to figure out whether we want to rename headers or not, before any draft goes to Last Call, especially if UMP wants to remain a subset of some sorts. AFAICT, your renaming proposal does not cover this section of CORS. I think the two efforts can proceed in parallel. I look forward to your feedback on this topic. Renaming would effect how the response header is named. Keeping consistency in the header names is important. If we decide to rename headers it would most likely be named CORS-Expose-Headers and otherwise it would most likely be named Access-Control-Expose-Headers. Renaming also affects UMP in another way, namely the name of the Access-Control-Allow-Origin header. -- Anne van Kesteren http://annevankesteren.nl/
Re: UMP / CORS: Implementor Interest
On Tue, May 11, 2010 at 3:16 PM, Maciej Stachowiak wrote: > On May 11, 2010, at 1:57 PM, Jonas Sicking wrote: >> On Tue, May 11, 2010 at 1:34 PM, Dirk Pranke wrote: >>> On Tue, May 11, 2010 at 12:01 PM, Tyler Close >>> wrote: On Tue, May 11, 2010 at 11:41 AM, Ojan Vafai wrote: > What is the difference between an "authoring guide" and a > "specification for > web developers"? The difference is whether or not the normative statements in UMP actually are normative for a CORS implementation. This comes down to whether or not a developer reading UMP can trust what it says, or must he also read the CORS spec. > The key point of making this distinction is that > implementors should be able to look solely at the combined spec. No, the key point is to relieve developers of the burden of reading and understanding CORS. The CORS spec takes on the burden of restating UMP in its own algorithmic way so that an implementor can read only CORS. >>> >>> If figuring out how to have two specs is too much hassle, you could >>> probably get 90%+ of what people are looking for by putting all of the >>> normative stuff in the CORS spec and writing an informational note >>> describing UMP that only discusses the subset of CORS needed for UMP. >> >> That is exactly what I propose. I'd also call the informational UMP >> note developer documentation, and make it easier to read for >> developers than what a spec could ever be. But that's less important >> if people feel otherwise. > > The approach suggested by Dirk and Jonas seems sensible to me. Yeah, me too. That's what I meant by my comment above. Two documents for two audiences, each tailored to best suit its audience. Adam
Re: UMP / CORS: Implementor Interest
On Tue, 11 May 2010, Tyler Close wrote: > > CORS introduces subtle but severe Confused Deputy vulnerabilities I don't think everyone is convinced that this is the case. It is certainly possible to mis-use CORS in insecure ways, but then it's also possible to mis-use UMP in insecure ways. As far as I can tell, confused deputy vulnerabilities only occur with CORS if you use it in inappropriate ways, such as sharing identifiers amongst different origins without properly validating that they aren't spoofing each other. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: UMP / CORS: Implementor Interest
On May 11, 2010, at 1:57 PM, Jonas Sicking wrote: On Tue, May 11, 2010 at 1:34 PM, Dirk Pranke wrote: On Tue, May 11, 2010 at 12:01 PM, Tyler Close wrote: On Tue, May 11, 2010 at 11:41 AM, Ojan Vafai wrote: What is the difference between an "authoring guide" and a "specification for web developers"? The difference is whether or not the normative statements in UMP actually are normative for a CORS implementation. This comes down to whether or not a developer reading UMP can trust what it says, or must he also read the CORS spec. The key point of making this distinction is that implementors should be able to look solely at the combined spec. No, the key point is to relieve developers of the burden of reading and understanding CORS. The CORS spec takes on the burden of restating UMP in its own algorithmic way so that an implementor can read only CORS. If figuring out how to have two specs is too much hassle, you could probably get 90%+ of what people are looking for by putting all of the normative stuff in the CORS spec and writing an informational note describing UMP that only discusses the subset of CORS needed for UMP. That is exactly what I propose. I'd also call the informational UMP note developer documentation, and make it easier to read for developers than what a spec could ever be. But that's less important if people feel otherwise. The approach suggested by Dirk and Jonas seems sensible to me. Regards, Maciej
Re: UMP / CORS: Implementor Interest
On Tue, May 11, 2010 at 1:34 PM, Dirk Pranke wrote: > On Tue, May 11, 2010 at 12:01 PM, Tyler Close wrote: >> On Tue, May 11, 2010 at 11:41 AM, Ojan Vafai wrote: >>> What is the difference between an "authoring guide" and a "specification for >>> web developers"? >> >> The difference is whether or not the normative statements in UMP >> actually are normative for a CORS implementation. This comes down to >> whether or not a developer reading UMP can trust what it says, or must >> he also read the CORS spec. >> >>> The key point of making this distinction is that >>> implementors should be able to look solely at the combined spec. >> >> No, the key point is to relieve developers of the burden of reading >> and understanding CORS. The CORS spec takes on the burden of restating >> UMP in its own algorithmic way so that an implementor can read only >> CORS. > > If figuring out how to have two specs is too much hassle, you could > probably get 90%+ of what people are looking for by putting all of the > normative stuff in the CORS spec and writing an informational note > describing UMP that only discusses the subset of CORS needed for UMP. That is exactly what I propose. I'd also call the informational UMP note developer documentation, and make it easier to read for developers than what a spec could ever be. But that's less important if people feel otherwise. / Jonas
Re: UMP / CORS: Implementor Interest
On Tue, May 11, 2010 at 12:01 PM, Tyler Close wrote: > On Tue, May 11, 2010 at 11:41 AM, Ojan Vafai wrote: >> What is the difference between an "authoring guide" and a "specification for >> web developers"? > > The difference is whether or not the normative statements in UMP > actually are normative for a CORS implementation. This comes down to > whether or not a developer reading UMP can trust what it says, or must > he also read the CORS spec. > >> The key point of making this distinction is that >> implementors should be able to look solely at the combined spec. > > No, the key point is to relieve developers of the burden of reading > and understanding CORS. The CORS spec takes on the burden of restating > UMP in its own algorithmic way so that an implementor can read only > CORS. If figuring out how to have two specs is too much hassle, you could probably get 90%+ of what people are looking for by putting all of the normative stuff in the CORS spec and writing an informational note describing UMP that only discusses the subset of CORS needed for UMP. User agent implementors will have to read the CORS spec regardless of whether or not UMP is in it or a different spec, so creating two specs doesn't help much. And, as others have noted, service developers and web authors don't really tend to need to read the specs, so an article would probably be sufficient. -- Dirk
Re: UMP / CORS: Implementor Interest
On Tue, May 11, 2010 at 12:36 PM, Arthur Barstow wrote: > Jonas, Anne, Tlyer, All, > > On May 11, 2010, at 3:08 PM, ext Jonas Sicking wrote: > >> Personally I would prefer to see the "UMP model" be specced as part of >> the CORS spec, mostly to avoid inevitable differences between two >> specs trying to specify the same thing. And creating an authoring >> guide specifically for the UMP security model to help authors that >> want to just use UMP. > > Yes, I would also prefer that. Are there any technical reason(s) this can't > be done? CORS introduces subtle but severe Confused Deputy vulnerabilities which should prevent it from being standardized. Some believe/hope these vulnerabilities can be mitigated, but the suggested techniques are not well explained yet, will be overly constraining and will not work in many common cases. So far, the CORS document does not even explain these problems, let alone offer convincing solutions. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
Jonas, Anne, Tlyer, All, On May 11, 2010, at 3:08 PM, ext Jonas Sicking wrote: Personally I would prefer to see the "UMP model" be specced as part of the CORS spec, mostly to avoid inevitable differences between two specs trying to specify the same thing. And creating an authoring guide specifically for the UMP security model to help authors that want to just use UMP. Yes, I would also prefer that. Are there any technical reason(s) this can't be done? -Art Barstow Specs make for bad developer documentation anyway.
Re: UMP / CORS: Implementor Interest
On Tue, May 11, 2010 at 12:01 PM, Tyler Close wrote: > On Tue, May 11, 2010 at 11:41 AM, Ojan Vafai wrote: >> What is the difference between an "authoring guide" and a "specification for >> web developers"? > > The difference is whether or not the normative statements in UMP > actually are normative for a CORS implementation. This comes down to > whether or not a developer reading UMP can trust what it says, or must > he also read the CORS spec. My experience is that author almost never read specs, sometimes read developer docs (the good authors do), and mostly just tries to see how UAs behave. Ultimately UA behavior is what matters to them anyway. / Jonas
Re: UMP / CORS: Implementor Interest
On Tue, May 11, 2010 at 10:48 AM, Tyler Close wrote: > Firefox, Chrome and Caja have now all declared an interest in > implementing UMP. Opera and Safari have both declared an interest in > implementing the functionality defined in UMP under the name CORS. I > think it's clear that UMP has sufficient implementor interest to > proceed along the standardization path. For what it's worth, nobody has or can speak for all of Firefox. Personally I would prefer to see the "UMP model" be specced as part of the CORS spec, mostly to avoid inevitable differences between two specs trying to specify the same thing. And creating an authoring guide specifically for the UMP security model to help authors that want to just use UMP. Specs make for bad developer documentation anyway. / Jonas
Re: UMP / CORS: Implementor Interest
On Tue, May 11, 2010 at 11:41 AM, Ojan Vafai wrote: > What is the difference between an "authoring guide" and a "specification for > web developers"? The difference is whether or not the normative statements in UMP actually are normative for a CORS implementation. This comes down to whether or not a developer reading UMP can trust what it says, or must he also read the CORS spec. > The key point of making this distinction is that > implementors should be able to look solely at the combined spec. No, the key point is to relieve developers of the burden of reading and understanding CORS. The CORS spec takes on the burden of restating UMP in its own algorithmic way so that an implementor can read only CORS. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Tue, May 11, 2010 at 11:17 AM, Tyler Close wrote: > On Tue, May 11, 2010 at 10:54 AM, Anne van Kesteren > wrote: > > On Tue, 11 May 2010 19:48:57 +0200, Tyler Close > wrote: > >> Firefox, Chrome and Caja have now all declared an interest in > >> implementing UMP. Opera and Safari have both declared an interest in > >> implementing the functionality defined in UMP under the name CORS. I > I would put Chrome in the same camp as Opera and Safari based off the chromium-dev thread. Although, I think the distinction might lie in the misunderstanding below. > >> In the discussion on chromium-dev, Adam Barth wrote: > >> > >> """ > >> Putting these together, it looks like we want a separate UMP > >> specification for web developers and a combined CORS+UMP specification > >> for user agent implementors. Consequently, I think it makes sense for > >> the working group to publish UMP separately from CORS but have all the > >> user agent conformance requirements in the combined CORS+UMP document. > >> """ > > >> I think this is a satisfactory compromise and conclusion to the > >> current debate. Anne, are you willing to adopt this strategy? If so, I > >> think there needs to be a normative statement in the CORS spec that > >> identifies the algorithms and corresponding inputs that implement UMP. > > > > I don't understand. As far as I can tell Adam suggests making UMP an > > authoring guide. > > I read Adam as saying the UMP specification should be published. The > words "authoring guide" don't appear. I believe his reference to a > benefit for web developers refers to an opinion expressed earlier in > the thread that the UMP specification is more easily understood by web > developers. > What is the difference between an "authoring guide" and a "specification for web developers"? The key point of making this distinction is that implementors should be able to look solely at the combined spec. Ojan
Re: UMP / CORS: Implementor Interest
On Tue, 11 May 2010 19:48:57 +0200, Tyler Close wrote: Firefox, Chrome and Caja have now all declared an interest in implementing UMP. Opera and Safari have both declared an interest in implementing the functionality defined in UMP under the name CORS. I think it's clear that UMP has sufficient implementor interest to proceed along the standardization path. In the discussion on chromium-dev, Adam Barth wrote: """ Putting these together, it looks like we want a separate UMP specification for web developers and a combined CORS+UMP specification for user agent implementors. Consequently, I think it makes sense for the working group to publish UMP separately from CORS but have all the user agent conformance requirements in the combined CORS+UMP document. """ See: http://groups.google.com/a/chromium.org/group/chromium-dev/msg/4793e08f8ec98914?hl=en_US I think this is a satisfactory compromise and conclusion to the current debate. Anne, are you willing to adopt this strategy? If so, I think there needs to be a normative statement in the CORS spec that identifies the algorithms and corresponding inputs that implement UMP. I don't understand. As far as I can tell Adam suggests making UMP an authoring guide. Why would CORS need to normatively depend on it? Before sending UMP to Last Call, we need a CORS and UMP agreement on response header filtering. We need to reconcile the following two sections: http://dev.w3.org/2006/waf/access-control/#handling-a-response-to-a-cross-origin-re and http://dev.w3.org/2006/waf/UMP/#response-header-filtering Remaining subset issues around caching and credentials can be addressed with editorial changes to CORS. I'll provide more detail in a later email, assuming we've reached a compromise. I think we first need to figure out whether we want to rename headers or not, before any draft goes to Last Call, especially if UMP wants to remain a subset of some sorts. -- Anne van Kesteren http://annevankesteren.nl/
Re: UMP / CORS: Implementor Interest
On Tue, May 11, 2010 at 10:54 AM, Anne van Kesteren wrote: > On Tue, 11 May 2010 19:48:57 +0200, Tyler Close > wrote: >> >> Firefox, Chrome and Caja have now all declared an interest in >> implementing UMP. Opera and Safari have both declared an interest in >> implementing the functionality defined in UMP under the name CORS. I >> think it's clear that UMP has sufficient implementor interest to >> proceed along the standardization path. >> >> In the discussion on chromium-dev, Adam Barth wrote: >> >> """ >> Putting these together, it looks like we want a separate UMP >> specification for web developers and a combined CORS+UMP specification >> for user agent implementors. Consequently, I think it makes sense for >> the working group to publish UMP separately from CORS but have all the >> user agent conformance requirements in the combined CORS+UMP document. >> """ >> >> See: >> >> >> http://groups.google.com/a/chromium.org/group/chromium-dev/msg/4793e08f8ec98914?hl=en_US >> >> I think this is a satisfactory compromise and conclusion to the >> current debate. Anne, are you willing to adopt this strategy? If so, I >> think there needs to be a normative statement in the CORS spec that >> identifies the algorithms and corresponding inputs that implement UMP. > > I don't understand. As far as I can tell Adam suggests making UMP an > authoring guide. I read Adam as saying the UMP specification should be published. The words "authoring guide" don't appear. I believe his reference to a benefit for web developers refers to an opinion expressed earlier in the thread that the UMP specification is more easily understood by web developers. > Why would CORS need to normatively depend on it? For developers to be able to rely on the normative statements made in UMP when using a CORS implementation, CORS must normatively claim to be implementing UMP. >> Before sending UMP to Last Call, we need a CORS and UMP agreement on >> response header filtering. We need to reconcile the following two >> sections: >> >> >> http://dev.w3.org/2006/waf/access-control/#handling-a-response-to-a-cross-origin-re >> >> and >> >> http://dev.w3.org/2006/waf/UMP/#response-header-filtering >> >> Remaining subset issues around caching and credentials can be >> addressed with editorial changes to CORS. I'll provide more detail in >> a later email, assuming we've reached a compromise. > > I think we first need to figure out whether we want to rename headers or > not, before any draft goes to Last Call, especially if UMP wants to remain a > subset of some sorts. AFAICT, your renaming proposal does not cover this section of CORS. I think the two efforts can proceed in parallel. I look forward to your feedback on this topic. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
Firefox, Chrome and Caja have now all declared an interest in implementing UMP. Opera and Safari have both declared an interest in implementing the functionality defined in UMP under the name CORS. I think it's clear that UMP has sufficient implementor interest to proceed along the standardization path. In the discussion on chromium-dev, Adam Barth wrote: """ Putting these together, it looks like we want a separate UMP specification for web developers and a combined CORS+UMP specification for user agent implementors. Consequently, I think it makes sense for the working group to publish UMP separately from CORS but have all the user agent conformance requirements in the combined CORS+UMP document. """ See: http://groups.google.com/a/chromium.org/group/chromium-dev/msg/4793e08f8ec98914?hl=en_US I think this is a satisfactory compromise and conclusion to the current debate. Anne, are you willing to adopt this strategy? If so, I think there needs to be a normative statement in the CORS spec that identifies the algorithms and corresponding inputs that implement UMP. Before sending UMP to Last Call, we need a CORS and UMP agreement on response header filtering. We need to reconcile the following two sections: http://dev.w3.org/2006/waf/access-control/#handling-a-response-to-a-cross-origin-re and http://dev.w3.org/2006/waf/UMP/#response-header-filtering Remaining subset issues around caching and credentials can be addressed with editorial changes to CORS. I'll provide more detail in a later email, assuming we've reached a compromise. --Tyler On Mon, Apr 19, 2010 at 12:43 AM, Anne van Kesteren wrote: > Hopefully it helps calling out attention to this in a separate thread. > > In http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0043.html > Maciej states Apple has no interest in implementing UMP from the UMP > specification. (I believe this means that a CORS defined subset that roughly > matches UMP is fine.) They want to retain their CORS support. > > For Opera I can say we are planning on supporting on CORS in due course and > have no plans on implementing UMP from the UMP specification. > > It would be nice if the three other major implementors (i.e. Google, > Mozilla, and Microsoft) also stated their interest for both specifications, > especially including whether removing their current level of CORS support is > considered an option. > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > > -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
XML is also a misnomer. And HTTP is confusing since it also works over https. At least we agree on Request. On Apr 21, 2010 12:24 PM, "Maciej Stachowiak" wrote: On Apr 21, 2010, at 8:57 AM, Anne van Kesteren wrote: > On Wed, 21 Apr 2010 23:37:54 +0900, Mark S... I agree that "Anonymous" or "Anon" is more clear as to the purpose than "Uniform". I understand why UMP uses that term but I don't think it will be obvious to authors reading code. Regards, Maciej
Re: UMP / CORS: Implementor Interest
On Mon, Apr 19, 2010 at 11:45 AM, Adam Barth wrote: > On Mon, Apr 19, 2010 at 12:43 AM, Anne van Kesteren wrote: >> Hopefully it helps calling out attention to this in a separate thread. >> >> In http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0043.html >> Maciej states Apple has no interest in implementing UMP from the UMP >> specification. (I believe this means that a CORS defined subset that roughly >> matches UMP is fine.) They want to retain their CORS support. >> >> For Opera I can say we are planning on supporting on CORS in due course and >> have no plans on implementing UMP from the UMP specification. >> >> It would be nice if the three other major implementors (i.e. Google, >> Mozilla, and Microsoft) also stated their interest for both specifications, >> especially including whether removing their current level of CORS support is >> considered an option. > > I've forwarded your question to chromium-dev: > > http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/4ffa158e71ec4613# Here's a sample response for those not subscribed to chromium-dev: [[ A couple things to note for background sake: 1) It is our goal that Chrome and Safari should not diverge in web platform behavior. 2) Maciej is a very influential member of the WebKit and web standards communities. Therefore, I think Maciej would need to be convinced before Chrome would ship UMP. I confess that I don't have a good enough understanding of UMP vs CORS yet to comment intelligently on the subject. I need to do some reading and educate myself better. Having read some of what has been linked from this thread, I still feel that I am missing some background information. ]] http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/4ffa158e71ec4613/0399f434e4016426?lnk=raot#0399f434e4016426 Kind regards, Adam
Re: UMP / CORS: Implementor Interest
On Thu, Apr 22, 2010 at 4:33 PM, Mark S. Miller wrote: > [...] Caja parses a sanitized subset of HTML HTML5's tag soup algorithm. > Sorry. I meant Caja parses a sanitized subset of HTML *using* HTML5's tag soup algorithm. Fortunately, the typo has little bearing on the overall point. -- Cheers, --MarkM
Re: UMP / CORS: Implementor Interest
On Mon, Apr 19, 2010 at 12:43 AM, Anne van Kesteren wrote: > Hopefully it helps calling out attention to this in a separate thread. > > In > http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0043.htmlMaciej > states Apple has no interest in implementing UMP from the UMP > specification. (I believe this means that a CORS defined subset that roughly > matches UMP is fine.) They want to retain their CORS support. > > For Opera I can say we are planning on supporting on CORS in due course and > have no plans on implementing UMP from the UMP specification. > > It would be nice if the three other major implementors (i.e. Google, > Mozilla, and Microsoft) also stated their interest for both specifications, > especially including whether removing their current level of CORS support is > considered an option. > Caja does plan to implement UMP and not CORS. Caja is a user agent built as a virtual browser-in-browser, translating from the subset of future web standards it accepts (e.g., a subset of ES5/strict) into the subset of future web standards supported by current browsers (e.g., a subset of ES3). Caja accepts not just JavaScript of course -- Caja parses a sanitized subset of HTML HTML5's tag soup algorithm. Since Caja helps protect the Yahoo! home page, in some quantitative sense it is a larger user agent than Safari, Opera, or Chrome. Caja intermediates the dereferencing of all URLs through a container-supplied URL translation policy. Say cajoled code inlined on a page running on site X makes a cross-origin request to a server addressed as site Y. Caja does support all Yahoo! A-grade browsers including IE6. To emulate the cross-origin request on IE6, obviously, our only choice is to relay the request through the X server. Since the X server has no access to the browser's cookies for site Y, obviously, we cannot emulate the CSRF vulnerabilities of full CORS even if we wanted to. UniformRequests can be faithfully relayed through intermediaries. Full CORS cannot. Thus, UniformRequests have a better incremental transition story for software that can be deployed today. > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > > -- Cheers, --MarkM
Re: UMP / CORS: Implementor Interest
Consolidating replies a bit... On Apr 22, 2010, at 11:29 AM, Dirk Pranke wrote: Here's some new directions ... ContextFreeRequest StatelessRequest SessionlessRequest All HTTP requests are stateless, and sessionless could mean many things, so I'm not keen on those. ContextFree is a good suggestion. or, since we're really talking about cookies here ... CookielessRequest CookieFreeRequest SugarFreeRequest IncognitoRequest(playing off of Chrome's "Incognito" mode, which doesn't use your browser's normal cookie store) Cookies are not the only issue. Another key difference is not sending headers that identify the site making the request (e.g. Origin or Referer). Secondary issues are other forms of client authentication such as HTTP authentication and SSL client certificates. Those are not very commonly used on public Web sites, but they need to be excluded for the proposed API to be secure. On Apr 22, 2010, at 11:37 AM, Tab Atkins Jr. wrote: Count me as one web developer who won't miss the annoying and inaccurate "XH" from any future "R"s. I think that dropping them now won't be very confusing (the Request part has always been the meaningful one for me), and it then opens the door for future types of Requests to just share in the Request name, not the full baggage-laden XHR name. If we do drop the "XH" that gives us the freedom to be a little more verbose in the rest of the name, if we so choose. Regards, Maciej
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 6:45 PM, Maciej Stachowiak wrote: >> "XML" is also a misnomer. And "Http" is confusing as well, since these >> requests can (and should) generally be carried over https. At least we agree >> on "Request" ;). > > I agree, but (a) that ship has sailed; and (b) dropping those from the name > only in the anonymous/uniform/whatever version would probably be more > confusing than helpful, at least if the API ends up being roughly similar. > XMLHttpRequest has brand value, and it's worth building on author awareness > even if the X and the H are more historical than meaningful at this point. Count me as one web developer who won't miss the annoying and inaccurate "XH" from any future "R"s. I think that dropping them now won't be very confusing (the Request part has always been the meaningful one for me), and it then opens the door for future types of Requests to just share in the Request name, not the full baggage-laden XHR name. In other words, assuming confusion from a sample of one doesn't seem too valid. Establishing precedent with two, though, makes it significantly more difficult to ever do anything better in the future. We're stuck with XHR as the name for vanilla XHR stuff. We don't need to perpetuate its inaccuracies and capitalization inconsistencies into future types of Requests. ~TJ
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 11:39 PM, Maciej Stachowiak wrote: > > On Apr 21, 2010, at 11:11 PM, Anne van Kesteren wrote: > > On Thu, 22 Apr 2010 14:36:50 +0900, Adam Barth wrote: > > Unfortunately "ambient" doesn't have any good antonyms: > > http://www.synonym.com/antonym/ambient/ > > Simon suggested XMLHttpRequestNoContext in #whatwg. Seems relatively clear > and works nicely with indexes and autocomplete. > > > Other ideas (also suffix variants instead of prefix variants): > - GuestXMLHttpRequest > Suggested by Mark originally. We now envision more use cases than guest > code, however, "guest" is also the traditional name for an unprivileged > account. > - UnprivilegedXMLHttpRequest (or abbreviate to NoPrivs) > - NoAuthorityXMLHttpRequest (or abbreviate to NoAuth, though that may seem > like "no authentication") > - NoCredentialsXMLHttpRequest (or abbreviate to NoCred) > Can anyone else think of ideas? I tried to mentally fill in sentences like, > "I don't want to do this as root, I want to use a/an ___ account" or "I > don't want to be logged into site X, I want to be when I visit it." > Regards, > Maciej > Here's some new directions ... ContextFreeRequest StatelessRequest SessionlessRequest or, since we're really talking about cookies here ... CookielessRequest CookieFreeRequest SugarFreeRequest IncognitoRequest(playing off of Chrome's "Incognito" mode, which doesn't use your browser's normal cookie store) -- Dirk
Re: UMP / CORS: Implementor Interest
On Thu, Apr 22, 2010 at 11:00 AM, Maciej Stachowiak wrote: > > On Apr 22, 2010, at 10:27 AM, Mark S. Miller wrote: > > On Wed, Apr 21, 2010 at 11:47 PM, Maciej Stachowiak wrote: > >> That being said, I'm totally open to a name that conveys the same meaning >> with less perceived ambiguity. I just don't think "Uniform" is it. It >> doesn't get across the main idea very well at all. We need a phrase that >> says "the browser won't automatically add any credentials, identifying >> information or ambient authority". >> > > > I think you need to consider the larger anticipated rhetorical context. > > > As an API designer, I'm interested in optimizing for programmers reading > and writing the code, not purveyors of rhetoric. I'm not sure if the > statement below is a quote of some existing or proposed spec text, but > certainly the tone is not appropriate to put in a technical specification. > I was not suggesting those paragraphs be put in any spec text, or indeed in any document from the w3c. I completely agree that the tone is inappropriate. My point is that such text is likely representative of the discussions that we should expect developers to have (and btw, of points I will be making in such discussions), so the concept of Uniformity may not remain as foreign as you are currently assuming. No matter what term we choose, its meaning will need to be explained to developers by multiple channels, many of them unofficial and outside the jurisdiction of the w3c. Outside the w3c, many developers to not consider yet more of the same business as usual to be an acceptable approach to web security. They would welcome a simple, sound and understandable alternative. Within the w3c, by choosing the right terms, we help seed these external discussions so that the path to saner practices can be more rapidly appreciated. > > - Maciej > > Something like: > > "Browser security is crap. It is based on a bad theory badly executed. The > Same Origin Policy led to a proliferation of ACL mechanisms in the browser > -- four at last count. These endless ACL epicycles have not yet been > adequate to protect us from CSRF and Clickjacking, so some see the solution > in elaborating the SOP with yet another ACL epicycle, the Origin header. > > Fortunately, the original web architecture contains the seeds of its own > success -- the concept for Uniformity, as embraced by the URL and URI. > Extended from designators to the messages sent to those designators, we get > the Uniform Messaging Policy as a simple, clean, sound, and understandable > alternative to the failed Same Origin Policy. > > Messages sent to using the XMLHttpRequest constructor are still governed by > the Same Origin Policy. To escape the madness and use the Uniform Messaging > Policy, use the UniformRequest constructor instead." > > > -- Cheers, --MarkM
Re: UMP / CORS: Implementor Interest
On Apr 22, 2010, at 10:27 AM, Mark S. Miller wrote: On Wed, Apr 21, 2010 at 11:47 PM, Maciej Stachowiak wrote: That being said, I'm totally open to a name that conveys the same meaning with less perceived ambiguity. I just don't think "Uniform" is it. It doesn't get across the main idea very well at all. We need a phrase that says "the browser won't automatically add any credentials, identifying information or ambient authority". I think you need to consider the larger anticipated rhetorical context. As an API designer, I'm interested in optimizing for programmers reading and writing the code, not purveyors of rhetoric. I'm not sure if the statement below is a quote of some existing or proposed spec text, but certainly the tone is not appropriate to put in a technical specification. - Maciej Something like: "Browser security is crap. It is based on a bad theory badly executed. The Same Origin Policy led to a proliferation of ACL mechanisms in the browser -- four at last count. These endless ACL epicycles have not yet been adequate to protect us from CSRF and Clickjacking, so some see the solution in elaborating the SOP with yet another ACL epicycle, the Origin header. Fortunately, the original web architecture contains the seeds of its own success -- the concept for Uniformity, as embraced by the URL and URI. Extended from designators to the messages sent to those designators, we get the Uniform Messaging Policy as a simple, clean, sound, and understandable alternative to the failed Same Origin Policy. Messages sent to using the XMLHttpRequest constructor are still governed by the Same Origin Policy. To escape the madness and use the Uniform Messaging Policy, use the UniformRequest constructor instead."
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 11:47 PM, Maciej Stachowiak wrote: > That being said, I'm totally open to a name that conveys the same meaning > with less perceived ambiguity. I just don't think "Uniform" is it. It > doesn't get across the main idea very well at all. We need a phrase that > says "the browser won't automatically add any credentials, identifying > information or ambient authority". > I think you need to consider the larger anticipated rhetorical context. Something like: "Browser security is crap. It is based on a bad theory badly executed. The Same Origin Policy led to a proliferation of ACL mechanisms in the browser -- four at last count. These endless ACL epicycles have not yet been adequate to protect us from CSRF and Clickjacking, so some see the solution in elaborating the SOP with yet another ACL epicycle, the Origin header. Fortunately, the original web architecture contains the seeds of its own success -- the concept for Uniformity, as embraced by the URL and URI. Extended from designators to the messages sent to those designators, we get the Uniform Messaging Policy as a simple, clean, sound, and understandable alternative to the failed Same Origin Policy. Messages sent to using the XMLHttpRequest constructor are still governed by the Same Origin Policy. To escape the madness and use the Uniform Messaging Policy, use the UniformRequest constructor instead."
Re: UMP / CORS: Implementor Interest
On Thu, 22 Apr 2010 02:39:31 +0900, Tyler Close wrote: On Tue, Apr 20, 2010 at 10:07 PM, Anne van Kesteren wrote: Because I've yet to receive detailed feedback / proposals on CORS on what needs changing. In another thread Maciej asked you whether you would like to file the appropriate bugs and the he would do so if you did not get around to it. I have not seen much since. The email you refer to listed several specific problems with CORS. As you've noted, Maciej agreed these were problems. Now you're telling us that as editor for the WG you have decided to ignore this detailed feedback because it is not yet filed as official Issues against CORS. I'm not planning on ignoring anything. Why would I bring it up in the first place if I was? Instead, you are choosing to ignore UMP and press ahead trying to gain implementer support for the mechanism defined in CORS, even though you know there are agreed problems with it. I've already stated I'm willing to fix those problems. See also: http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0106.html http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0107.html A different approach, would be to recognize the value of all the work and analysis the WG has put into UMP and so explore how CORS could reference and leverage this work. I am happy to collaborate with you on this task if you'd like to make the attempt. I don't think making CORS depend on UMP makes sense. See also: http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0245.html -- Anne van Kesteren http://annevankesteren.nl/
Re: UMP / CORS: Implementor Interest
On Apr 21, 2010, at 8:29 PM, Mark S. Miller wrote: Thanks, the Tor example is clarifying. Tor attempts to actually provide anonymity, by attempting to hide all information that might be inadvertently identifying, like IP address, traffic patterns, or other side channels. The threat model includes an attacker that may be trying to identify the user despite the absence of any purposely included identifying information. UniformRequests provide no such protection, and so should not seem to promise such. Since authorizing decisions only rely on overt information, prevention of CSRF-like vulnerabilities need only be concerned about overt information. Suppressing side channels is *much* harder. Considering the Tor example, would you agree that the possibility of explicitly including identifying information in message content does not invalidate the term "anonymous"? Side channels are an interesting issue, but separate from the original issue you raised of explicitly added identifying information. I tend to think that side channels also do not disqualify the word "anonymous". For example, it's common (or at least stereotypical) for employers or public places of business to have an "anonymous comment box". However, typically when someone leaves a comment their fingerprints will be all over the piece of paper, so in theory it could be traced back to them. But we don't generally think this invalidates the use of the word "anonymous". Similarly, it's common for blogs to allow anonymous comments (although some make a point of explicitly saying that they "don't allow anonymous comments", in almost those exact words). But "anonymous" comment systems take no measures to hide side-channel fingerprints, such as the IP address from which the commenter is posting. Thus, I conclude that in normal use and even in the context of information technology, the common meaning of the term anonymous can be applied to systems that do not prevent identification through side channels. I think this addresses both of your objections so far to the term "Anonymous". That being said, I'm totally open to a name that conveys the same meaning with less perceived ambiguity. I just don't think "Uniform" is it. It doesn't get across the main idea very well at all. We need a phrase that says "the browser won't automatically add any credentials, identifying information or ambient authority". Regards, Maciej
Re: UMP / CORS: Implementor Interest
On Apr 21, 2010, at 11:11 PM, Anne van Kesteren wrote: On Thu, 22 Apr 2010 14:36:50 +0900, Adam Barth wrote: Unfortunately "ambient" doesn't have any good antonyms: http://www.synonym.com/antonym/ambient/ Simon suggested XMLHttpRequestNoContext in #whatwg. Seems relatively clear and works nicely with indexes and autocomplete. Other ideas (also suffix variants instead of prefix variants): - GuestXMLHttpRequest Suggested by Mark originally. We now envision more use cases than guest code, however, "guest" is also the traditional name for an unprivileged account. - UnprivilegedXMLHttpRequest (or abbreviate to NoPrivs) - NoAuthorityXMLHttpRequest (or abbreviate to NoAuth, though that may seem like "no authentication") - NoCredentialsXMLHttpRequest (or abbreviate to NoCred) Can anyone else think of ideas? I tried to mentally fill in sentences like, "I don't want to do this as root, I want to use a/an ___ account" or "I don't want to be logged into site X, I want to be when I visit it." Regards, Maciej
Re: UMP / CORS: Implementor Interest
On Thu, 22 Apr 2010 14:36:50 +0900, Adam Barth wrote: Unfortunately "ambient" doesn't have any good antonyms: http://www.synonym.com/antonym/ambient/ Simon suggested XMLHttpRequestNoContext in #whatwg. Seems relatively clear and works nicely with indexes and autocomplete. -- Anne van Kesteren http://annevankesteren.nl/
Re: UMP / CORS: Implementor Interest
Unfortunately "ambient" doesn't have any good antonyms: http://www.synonym.com/antonym/ambient/ Adam On Wed, Apr 21, 2010 at 8:29 PM, Mark S. Miller wrote: > On Wed, Apr 21, 2010 at 7:40 PM, Maciej Stachowiak wrote: >> >> I'm not trying to draw a bright line here between categories of software, >> rather I am looking into the reason this proposed API would exist. The >> purpose is to avoid passively including any credentials that would identify >> the user, identify the requesting site, or otherwise convey ambient >> authority. Right? So what's a good word to express that? Maybe "Anonymous" >> is not the best word to capture that concept, but "Uniform" does not seem to >> capture it either. I don't think most people would make the leap that >> "Uniform" means, "please, browser, don't add any credentials". Whereas I >> think "Anonymous" does convey that intent. There may be an even better >> words, but I think "Anonymous" is a really good fit. >> Consider Tor. Tor calls itself "a distributed, anonymous network", and >> most would agree that is a fair label. However, no one assumes that Tor will >> prevent you from typing your real name or other indentifying information >> into a Web page, or stop you from uploading a file that includes a PGP >> signature. What it does try to do is ensure that such information is not >> conveyed to anyone passively. That seems to match the intent of UMP (and the >> UMP-like subset of CORS) - no identifying information is passively added, >> but the sender is free to explicitly add it themselves. > > Thanks, the Tor example is clarifying. Tor attempts to actually provide > anonymity, by attempting to hide all information that might be inadvertently > identifying, like IP address, traffic patterns, or other side channels. The > threat model includes an attacker that may be trying to identify the user > despite the absence of any purposely included identifying information. > UniformRequests provide no such protection, and so should not seem to > promise such. Since authorizing decisions only rely on overt information, > prevention of CSRF-like vulnerabilities need only be concerned about overt > information. Suppressing side channels is *much* harder. > Q: "I sent my messages using AnonXmlHttpRequest. How did the secret police > know I was a dissident?" > A: "The name 'AnonXmlHttpRequest' was chosen to clarify the security > property it provides: absence of CSRF-like vulnerabilities. Why did you > think it provided anonymity?" > > >> >> This Working Group also did not agree to standardize [JSONRequest and >> XDR], though both were proposed. We have no say in what names third parties >> use in nonstandard APIs. >> In addition, they both of these APIs gratuitously different from >> XMLHttpRequest in ways other than security policy. I would suggest that we >> not do that with the proposed new constructor. > > On that we agree. > >> >> Regards, >> Maciej >> >> > > > > -- > Cheers, > --MarkM >
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 7:40 PM, Maciej Stachowiak wrote: > I'm not trying to draw a bright line here between categories of software, > rather I am looking into the reason this proposed API would exist. The > purpose is to avoid passively including any credentials that would identify > the user, identify the requesting site, or otherwise convey ambient > authority. Right? So what's a good word to express that? Maybe "Anonymous" > is not the best word to capture that concept, but "Uniform" does not seem to > capture it either. I don't think most people would make the leap that > "Uniform" means, "please, browser, don't add any credentials". Whereas I > think "Anonymous" does convey that intent. There may be an even better > words, but I think "Anonymous" is a really good fit. > > Consider Tor. Tor calls itself "a distributed, anonymous network", and most > would agree that is a fair label. However, no one assumes that Tor will > prevent you from typing your real name or other indentifying information > into a Web page, or stop you from uploading a file that includes a PGP > signature. What it does try to do is ensure that such information is not > conveyed to anyone passively. That seems to match the intent of UMP (and the > UMP-like subset of CORS) - no identifying information is passively added, > but the sender is free to explicitly add it themselves. > > Thanks, the Tor example is clarifying. Tor attempts to actually provide anonymity, by attempting to hide all information that might be inadvertently identifying, like IP address, traffic patterns, or other side channels. The threat model includes an attacker that may be trying to identify the user despite the absence of any purposely included identifying information. UniformRequests provide no such protection, and so should not seem to promise such. Since authorizing decisions only rely on overt information, prevention of CSRF-like vulnerabilities need only be concerned about overt information. Suppressing side channels is *much* harder. Q: "I sent my messages using AnonXmlHttpRequest. How did the secret police know I was a dissident?" A: "The name 'AnonXmlHttpRequest' was chosen to clarify the security property it provides: absence of CSRF-like vulnerabilities. Why did you think it provided anonymity?" > This Working Group also did not agree to standardize [JSONRequest and XDR], > though both were proposed. We have no say in what names third parties use in > nonstandard APIs. > > In addition, they both of these APIs gratuitously different from > XMLHttpRequest in ways other than security policy. I would suggest that we > not do that with the proposed new constructor. > On that we agree. > > > Regards, > Maciej > > > > -- Cheers, --MarkM
Re: UMP / CORS: Implementor Interest
On Apr 21, 2010, at 7:09 PM, Mark S. Miller wrote: On Wed, Apr 21, 2010 at 6:45 PM, Maciej Stachowiak wrote: On Apr 21, 2010, at 6:23 PM, Mark S. Miller wrote: On Wed, Apr 21, 2010 at 12:24 PM, Maciej Stachowiak wrote: I agree that "Anonymous" or "Anon" is more clear as to the purpose than "Uniform". In the same say this email is anonymous. Sure, I say it is from MarkM, but my browser doesn't add any identifying info that you can see. Even if I included MarkM's PGP signature, by your criteria, it would still be anonymous. Your mail client automatically adds identifying info, as do any mail relays in the delivery path. If that were not the case, I would think it's fair to say the message is sent anonymously based on the envelope being anynymous. That's so even if the message contents include a claim or proof of your identity. Ok, so a request is non-anonymous if the identifying information is added by at least: 1) a browser (cookies, etc) 2) a mail client 3) any mail relays in the delivery path. What other software counts? Why does PGP not count? If the mail client in question is JavaScript running in a web page sending a uniform message, is it still non-anonymous? I'm not trying to draw a bright line here between categories of software, rather I am looking into the reason this proposed API would exist. The purpose is to avoid passively including any credentials that would identify the user, identify the requesting site, or otherwise convey ambient authority. Right? So what's a good word to express that? Maybe "Anonymous" is not the best word to capture that concept, but "Uniform" does not seem to capture it either. I don't think most people would make the leap that "Uniform" means, "please, browser, don't add any credentials". Whereas I think "Anonymous" does convey that intent. There may be an even better words, but I think "Anonymous" is a really good fit. Consider Tor. Tor calls itself "a distributed, anonymous network", and most would agree that is a fair label. However, no one assumes that Tor will prevent you from typing your real name or other indentifying information into a Web page, or stop you from uploading a file that includes a PGP signature. What it does try to do is ensure that such information is not conveyed to anyone passively. That seems to match the intent of UMP (and the UMP-like subset of CORS) - no identifying information is passively added, but the sender is free to explicitly add it themselves. I understand why UMP uses that term but I don't think it will be obvious to authors reading code. "XML" is also a misnomer. And "Http" is confusing as well, since these requests can (and should) generally be carried over https. At least we agree on "Request" ;). I agree, but (a) that ship has sailed; and (b) dropping those from the name only in the anonymous/uniform/whatever version would probably be more confusing than helpful, at least if the API ends up being roughly similar. XMLHttpRequest has brand value, and it's worth building on author awareness even if the X and the H are more historical than meaningful at this point. Funny, I don't recall anyone objecting that the proposed JSONRequest should have been called JSONXmlHttpRequest. I also don't recall anyone suggesting that Microsoft rename XDomainRequest to XDomainXmlHttpRequest. Surely the same argument holds for these? This Working Group also did not agree to standardize those APIs, though both were proposed. We have no say in what names third parties use in nonstandard APIs. In addition, they both of these APIs gratuitously different from XMLHttpRequest in ways other than security policy. I would suggest that we not do that with the proposed new constructor. Regards, Maciej
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 6:45 PM, Maciej Stachowiak wrote: > > On Apr 21, 2010, at 6:23 PM, Mark S. Miller wrote: > > On Wed, Apr 21, 2010 at 12:24 PM, Maciej Stachowiak wrote: > >> I agree that "Anonymous" or "Anon" is more clear as to the purpose than >> "Uniform". > > > In the same say this email is anonymous. Sure, I say it is from MarkM, but > my browser doesn't add any identifying info that you can see. Even if I > included MarkM's PGP signature, by your criteria, it would still be > anonymous. > > > Your mail client automatically adds identifying info, as do any mail relays > in the delivery path. If that were not the case, I would think it's fair to > say the message is sent anonymously based on the envelope being anynymous. > That's so even if the message contents include a claim or proof of your > identity. > Ok, so a request is non-anonymous if the identifying information is added by at least: 1) a browser (cookies, etc) 2) a mail client 3) any mail relays in the delivery path. What other software counts? Why does PGP not count? If the mail client in question is JavaScript running in a web page sending a uniform message, is it still non-anonymous? > > >> I understand why UMP uses that term but I don't think it will be obvious >> to authors reading code. >> >> > "XML" is also a misnomer. And "Http" is confusing as well, since these > requests can (and should) generally be carried over https. At least we agree > on "Request" ;). > > > I agree, but (a) that ship has sailed; and (b) dropping those from the name > only in the anonymous/uniform/whatever version would probably be more > confusing than helpful, at least if the API ends up being roughly similar. > XMLHttpRequest has brand value, and it's worth building on author awareness > even if the X and the H are more historical than meaningful at this point. > Funny, I don't recall anyone objecting that the proposed JSONRequest should have been called JSONXmlHttpRequest. I also don't recall anyone suggesting that Microsoft rename XDomainRequest to XDomainXmlHttpRequest. Surely the same argument holds for these? > > Cheers, > Maciej > > -- Cheers, --MarkM
Re: UMP / CORS: Implementor Interest
On Apr 21, 2010, at 6:23 PM, Mark S. Miller wrote: On Wed, Apr 21, 2010 at 12:24 PM, Maciej Stachowiak wrote: I agree that "Anonymous" or "Anon" is more clear as to the purpose than "Uniform". In the same say this email is anonymous. Sure, I say it is from MarkM, but my browser doesn't add any identifying info that you can see. Even if I included MarkM's PGP signature, by your criteria, it would still be anonymous. Your mail client automatically adds identifying info, as do any mail relays in the delivery path. If that were not the case, I would think it's fair to say the message is sent anonymously based on the envelope being anynymous. That's so even if the message contents include a claim or proof of your identity. I understand why UMP uses that term but I don't think it will be obvious to authors reading code. "XML" is also a misnomer. And "Http" is confusing as well, since these requests can (and should) generally be carried over https. At least we agree on "Request" ;). I agree, but (a) that ship has sailed; and (b) dropping those from the name only in the anonymous/uniform/whatever version would probably be more confusing than helpful, at least if the API ends up being roughly similar. XMLHttpRequest has brand value, and it's worth building on author awareness even if the X and the H are more historical than meaningful at this point. Cheers, Maciej
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 12:24 PM, Maciej Stachowiak wrote: > I agree that "Anonymous" or "Anon" is more clear as to the purpose than > "Uniform". In the same say this email is anonymous. Sure, I say it is from MarkM, but my browser doesn't add any identifying info that you can see. Even if I included MarkM's PGP signature, by your criteria, it would still be anonymous. > I understand why UMP uses that term but I don't think it will be obvious to > authors reading code. > > "XML" is also a misnomer. And "Http" is confusing as well, since these requests can (and should) generally be carried over https. At least we agree on "Request" ;). -- Cheers, --MarkM
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 2:43 PM, Dirk Pranke wrote: > Similarly, if it is really your intent to stop CORS from getting > implemented, you're going to have to sell that harder, because (to > switch metaphors), if that ship hasn't already sailed, it is at least > boarding. I'd like to check the status of this discussion with the WG. I believe I've made a strong case that using CORS in a natural way can result in CSRF-like (Confused Deputy) vulnerabilities. There are several ways in which the pattern can manifest, but one of the simplest is A makes a request to B and includes some of the received data in a subsequent request to C. If credentials are used, A is applying all of its authority to identifiers selected by B. If B might be an attacker, there's a Confused Deputy vulnerability. There's nothing C can do to detect the attack server-side. Do WG members understand and accept the above? My impression from the discussion is yes, but people think it's a problem for Web developers to deal with and CORS has no responsibility here. Is that accurate? If so, can I convince WG members that we have a responsibility to provide easy-to-use *and* safe APIs to Web developers? --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 1:49 PM, Tyler Close wrote: > On Wed, Apr 21, 2010 at 1:29 PM, Ojan Vafai wrote: >> I've been watching the CORS/UMP debate from the sidelines. Here's how it >> looks to me: >> 1) UMP folk want to keep UMP a separate spec so that it can (theoretically) >> be easier to implement and ship sooner. > > We want to keep it a separate specification for two main reasons: > a) The simpler, shorter UMP spec is easier for web developers to > understand than a combined spec would be. > b) We believe there are significant technical issues with CORS that > should prevent it from being standardized in its current form. > > I suspect implementation of UMP features is independent of whether or > not there are two documents or one, or whether its called CORS or > UMP/CORS. I suspect implementers will move ahead if they think it's a > good idea with a stable specification. For example, I don't think the > number of documents used to specify the formerly more monolithic HTML5 > has affected implementation plans. > >> 2) Browser vendors intend to implement CORS. They don't want to have two >> similar but slightly different stacks for making requests, either in >> implementation or in what's exposed to developers. So, having UMP as a >> separate spec doesn't make sense if it's intended to be a subset (or even >> mostly a subset) of CORS. Mozilla might be willing to implement UMP with >> some API modifications and Microsoft hasn't voiced an opinion. >> Is that an accurate summary? >> Are there other advantages to keeping UMP a separate spec other than >> concerns of ship dates? Given the lack of vendor support, it doesn't seem >> like ship date is really a good argument since the ship date is dependent >> on vendors actually implementing this. > > AFAICT, there is good implementer support for the technical features > defined in UMP. Both Maciej and Anne indicated the features might be > implemented, but under the name CORS rather than UMP. AFAICT, that > constraint can be met by having CORS reference and extend UMP. > I believe UMP suffers from the perception that it is Yet Another Spec, as in some people will look at it and think "we're already doing CORS, why do we need to implement Yet Another Spec"? Whatever you can do to fix that impression will be in your interest. Similarly, if it is really your intent to stop CORS from getting implemented, you're going to have to sell that harder, because (to switch metaphors), if that ship hasn't already sailed, it is at least boarding. -- Dirk (Not speaking on behalf of the Chromium team)
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 1:29 PM, Ojan Vafai wrote: > I've been watching the CORS/UMP debate from the sidelines. Here's how it > looks to me: > 1) UMP folk want to keep UMP a separate spec so that it can (theoretically) > be easier to implement and ship sooner. We want to keep it a separate specification for two main reasons: a) The simpler, shorter UMP spec is easier for web developers to understand than a combined spec would be. b) We believe there are significant technical issues with CORS that should prevent it from being standardized in its current form. I suspect implementation of UMP features is independent of whether or not there are two documents or one, or whether its called CORS or UMP/CORS. I suspect implementers will move ahead if they think it's a good idea with a stable specification. For example, I don't think the number of documents used to specify the formerly more monolithic HTML5 has affected implementation plans. > 2) Browser vendors intend to implement CORS. They don't want to have two > similar but slightly different stacks for making requests, either in > implementation or in what's exposed to developers. So, having UMP as a > separate spec doesn't make sense if it's intended to be a subset (or even > mostly a subset) of CORS. Mozilla might be willing to implement UMP with > some API modifications and Microsoft hasn't voiced an opinion. > Is that an accurate summary? > Are there other advantages to keeping UMP a separate spec other than > concerns of ship dates? Given the lack of vendor support, it doesn't seem > like ship date is really a good argument since the ship date is dependent > on vendors actually implementing this. AFAICT, there is good implementer support for the technical features defined in UMP. Both Maciej and Anne indicated the features might be implemented, but under the name CORS rather than UMP. AFAICT, that constraint can be met by having CORS reference and extend UMP. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 10:39 AM, Tyler Close wrote: > On Tue, Apr 20, 2010 at 10:07 PM, Anne van Kesteren > wrote: > > On Wed, 21 Apr 2010 01:27:10 +0900, Tyler Close > > wrote: > >> > >> Why can't it be made exactly like UMP? All of the requirements in UMP > >> have been discussed at length and in great detail on this list by some > >> highly qualified people. The current UMP spec reflects all of that > >> discussion. By your own admission, the CORS spec has not received the > >> same level of review for these features. Why hasn't CORS adopted the > >> UMP solution? > > > > Because I've yet to receive detailed feedback / proposals on CORS on what > > needs changing. In another thread Maciej asked you whether you would like > to > > file the appropriate bugs and the he would do so if you did not get > around > > to it. I have not seen much since. > > The email you refer to listed several specific problems with CORS. As > you've noted, Maciej agreed these were problems. Now you're telling us > that as editor for the WG you have decided to ignore this detailed > feedback because it is not yet filed as official Issues against CORS. > Instead, you are choosing to ignore UMP and press ahead trying to gain > implementer support for the mechanism defined in CORS, even though you > know there are agreed problems with it. > > A different approach, would be to recognize the value of all the work > and analysis the WG has put into UMP and so explore how CORS could > reference and leverage this work. I am happy to collaborate with you > on this task if you'd like to make the attempt. I've been watching the CORS/UMP debate from the sidelines. Here's how it looks to me: 1) UMP folk want to keep UMP a separate spec so that it can (theoretically) be easier to implement and ship sooner. 2) Browser vendors intend to implement CORS. They don't want to have two similar but slightly different stacks for making requests, either in implementation or in what's exposed to developers. So, having UMP as a separate spec doesn't make sense if it's intended to be a subset (or even mostly a subset) of CORS. Mozilla might be willing to implement UMP with some API modifications and Microsoft hasn't voiced an opinion. Is that an accurate summary? Are there other advantages to keeping UMP a separate spec other than concerns of ship dates? Given the lack of vendor support, it doesn't seem like ship date is really a good argument since the ship date is dependent on vendors actually implementing this. Ojan
Re: UMP / CORS: Implementor Interest
On Apr 21, 2010, at 8:57 AM, Anne van Kesteren wrote:
On Wed, 21 Apr 2010 23:37:54 +0900, Mark S. Miller
wrote:
I dislike "AnonXMLHttpRequest" because the request is not necessarily
anonymous. For example, the requestor may very well place
identifying info
in the body '{"from": "j...@example.com", ...}'.
I like constructor name already shown at <
http://dev.w3.org/2006/waf/UMP/#ump-api-name>: "UniformRequest".
Since you still work with the XMLHttpRequest object I think it
should be in the name of the constructor as well. "Uniform" doesn't
tell you much about what it is doing. "Anon" is much clearer in that
sense. The user agent will keep the request anonymous. That the
author can put identifying information on top of that is up to the
author.
I agree that "Anonymous" or "Anon" is more clear as to the purpose
than "Uniform". I understand why UMP uses that term but I don't think
it will be obvious to authors reading code.
Regards,
Maciej
Re: UMP / CORS: Implementor Interest
On Tue, Apr 20, 2010 at 10:07 PM, Anne van Kesteren wrote: > On Wed, 21 Apr 2010 01:27:10 +0900, Tyler Close > wrote: >> >> Why can't it be made exactly like UMP? All of the requirements in UMP >> have been discussed at length and in great detail on this list by some >> highly qualified people. The current UMP spec reflects all of that >> discussion. By your own admission, the CORS spec has not received the >> same level of review for these features. Why hasn't CORS adopted the >> UMP solution? > > Because I've yet to receive detailed feedback / proposals on CORS on what > needs changing. In another thread Maciej asked you whether you would like to > file the appropriate bugs and the he would do so if you did not get around > to it. I have not seen much since. The email you refer to listed several specific problems with CORS. As you've noted, Maciej agreed these were problems. Now you're telling us that as editor for the WG you have decided to ignore this detailed feedback because it is not yet filed as official Issues against CORS. Instead, you are choosing to ignore UMP and press ahead trying to gain implementer support for the mechanism defined in CORS, even though you know there are agreed problems with it. A different approach, would be to recognize the value of all the work and analysis the WG has put into UMP and so explore how CORS could reference and leverage this work. I am happy to collaborate with you on this task if you'd like to make the attempt. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 8:57 AM, Anne van Kesteren wrote: > "Uniform" doesn't tell you much about what it is doing. The term "uniform" in Uniform Messaging Policy (UMP) is used in the same sense as it is used in Uniform Resource Identifier (URI). In particular, the following from RFC 3986 is most relevant: "URIs have a global scope and are interpreted consistently regardless of context, ..." The UMP defines a way to produce an HTTP request regardless of context. Today, browsers can only produce requests that are entangled with the user-agent's local context and this is the key to enabling CSRF-like vulnerabilities. Well formed, legitimate Web content that expresses an HTTP request might be harmless when viewed from an attacker's user-agent, but if the exact same content is viewed through a victim's user-agent, there is a successful attack. The difference between the two requests is simply the change of context. The well-known CSRF attack is not the only way to cause mischief by switching the local context of an HTTP request. There is a whole family of similar attacks that use the same pattern, called Confused Deputy. The UMP enables web content to avoid this whole family of attacks by making requests from the global scope, rather than from the user-agent's local context. Today, requesting content is interpreted differently depending on context. The UMP makes this interpretation uniform, and so the produced HTTP request is the same no matter where it is produced from. This uniformity allows web content to avoid the built-in Confused Deputy vulnerabilities in the user-agent. Uniformity is the crux of what the UMP does. As MarkM noted, uniformity is not the same as anonymity. I can compose web content that produces a request that declares my identity. Using the UMP, I can ensure that the produced request is the same, no matter where the request is issued from. The produced request still declares my identity and so is not anonymous. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Wed, 21 Apr 2010 23:50:40 +0900, Mark S. Miller wrote: On Tue, Apr 20, 2010 at 10:07 PM, Anne van Kesteren wrote: On Wed, 21 Apr 2010 01:27:10 +0900, Tyler Close wrote: Why can't it be made exactly like UMP? All of the requirements in UMP have been discussed at length and in great detail on this list by some highly qualified people. The current UMP spec reflects all of that discussion. By your own admission, the CORS spec has not received the same level of review for these features. Why hasn't CORS adopted the UMP solution? Because I've yet to receive detailed feedback / proposals on CORS on what needs changing. How are "Why can't it be made exactly like UMP?" and "Ideally, I'd like UMP to be folded into CORS by reference rather than by value, ..." not a detailed proposal? It's not a long proposal, because the proposal is simple enough to be clear and short. Implementors are interested in an integrated solution (i.e. by value). I personally think it would also be of significantly less overhead and make it much more clear where the problems are. In another thread Maciej asked you whether you would like to file the appropriate bugs and the he would do so if you did not get around to it. I have not seen much since. As I pointed out we were already on the way to fixing this; I'm not sure why you want to revisit that discussion yet again. -- Anne van Kesteren http://annevankesteren.nl/
Re: UMP / CORS: Implementor Interest
On Wed, 21 Apr 2010 23:37:54 +0900, Mark S. Miller
wrote:
I dislike "AnonXMLHttpRequest" because the request is not necessarily
anonymous. For example, the requestor may very well place identifying
info
in the body '{"from": "j...@example.com", ...}'.
I like constructor name already shown at <
http://dev.w3.org/2006/waf/UMP/#ump-api-name>: "UniformRequest".
Since you still work with the XMLHttpRequest object I think it should be
in the name of the constructor as well. "Uniform" doesn't tell you much
about what it is doing. "Anon" is much clearer in that sense. The user
agent will keep the request anonymous. That the author can put identifying
information on top of that is up to the author.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: UMP / CORS: Implementor Interest
On Tue, Apr 20, 2010 at 10:07 PM, Anne van Kesteren wrote: > On Wed, 21 Apr 2010 01:27:10 +0900, Tyler Close > wrote: > >> Why can't it be made exactly like UMP? All of the requirements in UMP >> have been discussed at length and in great detail on this list by some >> highly qualified people. The current UMP spec reflects all of that >> discussion. By your own admission, the CORS spec has not received the >> same level of review for these features. Why hasn't CORS adopted the >> UMP solution? >> > > Because I've yet to receive detailed feedback / proposals on CORS on what > needs changing. How are "Why can't it be made exactly like UMP?" and "Ideally, I'd like UMP to be folded into CORS by reference rather than by value, ..." not a detailed proposal? It's not a long proposal, because the proposal is simple enough to be clear and short. > In another thread Maciej asked you whether you would like to file the > appropriate bugs and the he would do so if you did not get around to it. I > have not seen much since. > > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > > -- Cheers, --MarkM
Re: UMP / CORS: Implementor Interest
On Tue, Apr 20, 2010 at 10:05 PM, Anne van Kesteren wrote:
> On Wed, 21 Apr 2010 03:47:06 +0900, Maciej Stachowiak
> wrote:
>
>> I kinda hate the boolean argument. I would rather have a syntax where the
>> intent is obvious from the source code. A boolean is not very
>> self-documenting. In fact I can't even remember right now whether true or
>> false is the value that gives you anonymous XHR. Possibilities:
>>
>> - Separate AnonXMLHttpRequest constructor
>> - Constructor parameter takes an enum value, so you write new
>> XMLHttpRequest(ANON) or something like that.
>> - Constructor parameter takes a string value, so you write new
>> XMLHttpRequest("anon") or ("anonymous") or whatever.
>>
>
> I guess a separate constructor is the easiest way to go then. I wasn't sure
> whether it was worth it as it clutters the global object some more.
I dislike "AnonXMLHttpRequest" because the request is not necessarily
anonymous. For example, the requestor may very well place identifying info
in the body '{"from": "j...@example.com", ...}'.
I like constructor name already shown at <
http://dev.w3.org/2006/waf/UMP/#ump-api-name>: "UniformRequest".
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>
--
Cheers,
--MarkM
Re: UMP / CORS: Implementor Interest
On Wed, 21 Apr 2010 01:27:10 +0900, Tyler Close wrote: Why can't it be made exactly like UMP? All of the requirements in UMP have been discussed at length and in great detail on this list by some highly qualified people. The current UMP spec reflects all of that discussion. By your own admission, the CORS spec has not received the same level of review for these features. Why hasn't CORS adopted the UMP solution? Because I've yet to receive detailed feedback / proposals on CORS on what needs changing. In another thread Maciej asked you whether you would like to file the appropriate bugs and the he would do so if you did not get around to it. I have not seen much since. -- Anne van Kesteren http://annevankesteren.nl/
Re: UMP / CORS: Implementor Interest
On Wed, 21 Apr 2010 03:47:06 +0900, Maciej Stachowiak
wrote:
I kinda hate the boolean argument. I would rather have a syntax where
the intent is obvious from the source code. A boolean is not very self-
documenting. In fact I can't even remember right now whether true or
false is the value that gives you anonymous XHR. Possibilities:
- Separate AnonXMLHttpRequest constructor
- Constructor parameter takes an enum value, so you write new
XMLHttpRequest(ANON) or something like that.
- Constructor parameter takes a string value, so you write new
XMLHttpRequest("anon") or ("anonymous") or whatever.
I guess a separate constructor is the easiest way to go then. I wasn't
sure whether it was worth it as it clutters the global object some more.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: UMP / CORS: Implementor Interest
On Wed, 21 Apr 2010 03:34:42 +0900, Jonas Sicking wrote:
It looks ok to me, though somewhat lacking on details. What happens if
you call
x = new XMLHttpRequest("foopy");
or
x = new XMLHttpRequest(undefined);
See Web IDL.
You should probably define that the 'anon' argument is a boolean so
that the normal conversion rules automatically are applied.
See the Web IDL fragment in the specification.
I'm also wondering if the UMP guys are happy with this syntax.
I haven't gotten feedback on it so far.
There has been suggestions of changing header names. I'm not a big fan
of the current names, but if we're going to fix them, i'd rather see a
coherent strategy for all CORS headers than random spot fixes.
Does that mean you would be willing to remove support for the current
header
names? If not I'm not sure if it is worth it. But if you are I will
make a
proposal.
Yeah, the goal would definitely be to drop the old header names. We
probably couldn't drop them right away, but would need a phase-out
period. I think this would still be doable, but the longer we wait the
less that is going to be true.
Also, it requires everyone to be on board with this change, including
webkit and Microsoft.
Okay.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: UMP / CORS: Implementor Interest
On Tue, Apr 20, 2010 at 11:36 AM, Jonas Sicking wrote: > On Tue, Apr 20, 2010 at 9:27 AM, Tyler Close wrote: >> On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren wrote: >>> On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking wrote: As I've said before. I'd be interested in implementing UMP in firefox if we can come up with a reasonable API for using it. I.e. a separate constructor or flag or similar on XHR. This is assuming that UMP is a reasonable subset of CORS. >>> >>> Have you looked at the proposal I put in XHR2? It sets certain flags in CORS >>> that make it more or less the same as UMP. >> >> Why can't it be made exactly like UMP? All of the requirements in UMP >> have been discussed at length and in great detail on this list by some >> highly qualified people. The current UMP spec reflects all of that >> discussion. By your own admission, the CORS spec has not received the >> same level of review for these features. Why hasn't CORS adopted the >> UMP solution? > > Would you be fine with "folding" UMP into CORS if more of the wording > from UMP is used in the CORS spec? > > Are the differences only editorial or are there different header > names/values as well? The differences are not only editorial. The problem is missing MUST statements in the CORS spec, governing what the user-agent does. The on-the-wire parts are nearly identical. The header names and values are consistent (or will be once CORS response header filtering is fixed). Ideally, I'd like UMP to be folded into CORS by reference rather than by value, since there are major outstanding issues against CORS that don't affect UMP. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Tue, Apr 20, 2010 at 11:39 AM, Maciej Stachowiak wrote: > > On Apr 20, 2010, at 9:27 AM, Tyler Close wrote: > >> On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren >> wrote: >>> >>> On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking >>> wrote: As I've said before. I'd be interested in implementing UMP in firefox if we can come up with a reasonable API for using it. I.e. a separate constructor or flag or similar on XHR. This is assuming that UMP is a reasonable subset of CORS. >>> >>> Have you looked at the proposal I put in XHR2? It sets certain flags in >>> CORS >>> that make it more or less the same as UMP. >> >> Why can't it be made exactly like UMP? All of the requirements in UMP >> have been discussed at length and in great detail on this list by some >> highly qualified people. The current UMP spec reflects all of that >> discussion. By your own admission, the CORS spec has not received the >> same level of review for these features. Why hasn't CORS adopted the >> UMP solution? > > It should be made exactly like UMP, either by changing CORS, or changing > UMP, or some combination of the two. A list of differences between UMP and > CORS "anonymous mode" would be most helpful. Some of these issues are listed at the top of: http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0060.html Many of the differences arise from CORS being silent about relevant issues, such as caching or received cookies, so it's hard to know what the CORS stand on these issues is. This part of the CORS spec is just not well developed yet. Since there are still major outstanding issues against other parts of the CORS spec, I still think it's a better idea to move forward with separate documents, where the CORS spec references the UMP spec for its credential-free mode. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Tue, Apr 20, 2010 at 11:47 AM, Maciej Stachowiak wrote:
>
> On Apr 20, 2010, at 11:34 AM, Jonas Sicking wrote:
>
>> On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren
>> wrote:
>>>
>>> On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking
>>> wrote:
As I've said before. I'd be interested in implementing UMP in firefox
if we can come up with a reasonable API for using it. I.e. a separate
constructor or flag or similar on XHR. This is assuming that UMP is a
reasonable subset of CORS.
>>>
>>> Have you looked at the proposal I put in XHR2? It sets certain flags in
>>> CORS
>>> that make it more or less the same as UMP. I don't really see why we
>>> would
>>> need UMP if we have that.
>>
>> It looks ok to me, though somewhat lacking on details. What happens if you
>> call
>>
>> x = new XMLHttpRequest("foopy");
>> or
>> x = new XMLHttpRequest(undefined);
>>
>>
>> You should probably define that the 'anon' argument is a boolean so
>> that the normal conversion rules automatically are applied.
>
> I kinda hate the boolean argument. I would rather have a syntax where the
> intent is obvious from the source code. A boolean is not very
> self-documenting. In fact I can't even remember right now whether true or
> false is the value that gives you anonymous XHR. Possibilities:
>
> - Separate AnonXMLHttpRequest constructor
> - Constructor parameter takes an enum value, so you write new
> XMLHttpRequest(ANON) or something like that.
> - Constructor parameter takes a string value, so you write new
> XMLHttpRequest("anon") or ("anonymous") or whatever.
>
> For any of those options (or similar variants), it would be immediately
> obvious from source what is going on.
I agree that these all are better options. I think I like the enum one
the least, especially since you'd likely have to write
x = new XMLHttpRequest(XMLHttpRequest.ANON);
which would likely result in people writing
x = new XMLHttpRequest(1);
My favorite is the separate constructor.
>> I'm also wondering if the UMP guys are happy with this syntax.
>>
There has been suggestions of changing header names. I'm not a big fan
of the current names, but if we're going to fix them, i'd rather see a
coherent strategy for all CORS headers than random spot fixes.
>>>
>>> Does that mean you would be willing to remove support for the current
>>> header
>>> names? If not I'm not sure if it is worth it. But if you are I will make
>>> a
>>> proposal.
>>
>> Yeah, the goal would definitely be to drop the old header names. We
>> probably couldn't drop them right away, but would need a phase-out
>> period. I think this would still be doable, but the longer we wait the
>> less that is going to be true.
>>
>> Also, it requires everyone to be on board with this change, including
>> webkit and Microsoft.
>
> What do we know about the current level of CORS deployments? I'd be very
> hesitant to change headers that are actively in use. It might be reasonable
> to change only some of the headers if we learn that, for example,
> "Access-Control-Allow-Origin" is the only one in common use.
>
> Also, it's hard to answer this in the hypothetical. Do we have a specific
> idea for new header names that would be really great? I'm worried that
> opening up for change will just trigger a giant bikeshed and possibly not
> result in better names in the end.
These are all good questions. I'd say the responsibility to suggest
better names lies with the people that want to change the current
names.
I think phasing out the existing header names could be done relatively
quickly. The one exception is IE which traditionally have been slower
moving as far as backwards incompatible changes goes.
I don't intend to spend a lot of time on this until someone has
suggested a new set of header names and gotten microsoft to say they
are fine with implementing them in XDR.
/ Jonas
Re: UMP / CORS: Implementor Interest
On Apr 20, 2010, at 11:34 AM, Jonas Sicking wrote:
On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren
wrote:
On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking
wrote:
As I've said before. I'd be interested in implementing UMP in
firefox
if we can come up with a reasonable API for using it. I.e. a
separate
constructor or flag or similar on XHR. This is assuming that UMP
is a
reasonable subset of CORS.
Have you looked at the proposal I put in XHR2? It sets certain
flags in CORS
that make it more or less the same as UMP. I don't really see why
we would
need UMP if we have that.
It looks ok to me, though somewhat lacking on details. What happens
if you call
x = new XMLHttpRequest("foopy");
or
x = new XMLHttpRequest(undefined);
You should probably define that the 'anon' argument is a boolean so
that the normal conversion rules automatically are applied.
I kinda hate the boolean argument. I would rather have a syntax where
the intent is obvious from the source code. A boolean is not very self-
documenting. In fact I can't even remember right now whether true or
false is the value that gives you anonymous XHR. Possibilities:
- Separate AnonXMLHttpRequest constructor
- Constructor parameter takes an enum value, so you write new
XMLHttpRequest(ANON) or something like that.
- Constructor parameter takes a string value, so you write new
XMLHttpRequest("anon") or ("anonymous") or whatever.
For any of those options (or similar variants), it would be
immediately obvious from source what is going on.
I'm also wondering if the UMP guys are happy with this syntax.
There has been suggestions of changing header names. I'm not a big
fan
of the current names, but if we're going to fix them, i'd rather
see a
coherent strategy for all CORS headers than random spot fixes.
Does that mean you would be willing to remove support for the
current header
names? If not I'm not sure if it is worth it. But if you are I will
make a
proposal.
Yeah, the goal would definitely be to drop the old header names. We
probably couldn't drop them right away, but would need a phase-out
period. I think this would still be doable, but the longer we wait the
less that is going to be true.
Also, it requires everyone to be on board with this change, including
webkit and Microsoft.
What do we know about the current level of CORS deployments? I'd be
very hesitant to change headers that are actively in use. It might be
reasonable to change only some of the headers if we learn that, for
example, "Access-Control-Allow-Origin" is the only one in common use.
Also, it's hard to answer this in the hypothetical. Do we have a
specific idea for new header names that would be really great? I'm
worried that opening up for change will just trigger a giant bikeshed
and possibly not result in better names in the end.
Cheers,
Maciej
Re: UMP / CORS: Implementor Interest
On Apr 20, 2010, at 9:27 AM, Tyler Close wrote: On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren wrote: On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking wrote: As I've said before. I'd be interested in implementing UMP in firefox if we can come up with a reasonable API for using it. I.e. a separate constructor or flag or similar on XHR. This is assuming that UMP is a reasonable subset of CORS. Have you looked at the proposal I put in XHR2? It sets certain flags in CORS that make it more or less the same as UMP. Why can't it be made exactly like UMP? All of the requirements in UMP have been discussed at length and in great detail on this list by some highly qualified people. The current UMP spec reflects all of that discussion. By your own admission, the CORS spec has not received the same level of review for these features. Why hasn't CORS adopted the UMP solution? It should be made exactly like UMP, either by changing CORS, or changing UMP, or some combination of the two. A list of differences between UMP and CORS "anonymous mode" would be most helpful. Regards, Maciej
Re: UMP / CORS: Implementor Interest
On Tue, Apr 20, 2010 at 9:27 AM, Tyler Close wrote: > On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren wrote: >> On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking wrote: >>> >>> As I've said before. I'd be interested in implementing UMP in firefox >>> if we can come up with a reasonable API for using it. I.e. a separate >>> constructor or flag or similar on XHR. This is assuming that UMP is a >>> reasonable subset of CORS. >> >> Have you looked at the proposal I put in XHR2? It sets certain flags in CORS >> that make it more or less the same as UMP. > > Why can't it be made exactly like UMP? All of the requirements in UMP > have been discussed at length and in great detail on this list by some > highly qualified people. The current UMP spec reflects all of that > discussion. By your own admission, the CORS spec has not received the > same level of review for these features. Why hasn't CORS adopted the > UMP solution? Would you be fine with "folding" UMP into CORS if more of the wording from UMP is used in the CORS spec? Are the differences only editorial or are there different header names/values as well? / Jonas
Re: UMP / CORS: Implementor Interest
On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren wrote:
> On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking wrote:
>>
>> As I've said before. I'd be interested in implementing UMP in firefox
>> if we can come up with a reasonable API for using it. I.e. a separate
>> constructor or flag or similar on XHR. This is assuming that UMP is a
>> reasonable subset of CORS.
>
> Have you looked at the proposal I put in XHR2? It sets certain flags in CORS
> that make it more or less the same as UMP. I don't really see why we would
> need UMP if we have that.
It looks ok to me, though somewhat lacking on details. What happens if you call
x = new XMLHttpRequest("foopy");
or
x = new XMLHttpRequest(undefined);
You should probably define that the 'anon' argument is a boolean so
that the normal conversion rules automatically are applied.
I'm also wondering if the UMP guys are happy with this syntax.
>> There has been suggestions of changing header names. I'm not a big fan
>> of the current names, but if we're going to fix them, i'd rather see a
>> coherent strategy for all CORS headers than random spot fixes.
>
> Does that mean you would be willing to remove support for the current header
> names? If not I'm not sure if it is worth it. But if you are I will make a
> proposal.
Yeah, the goal would definitely be to drop the old header names. We
probably couldn't drop them right away, but would need a phase-out
period. I think this would still be doable, but the longer we wait the
less that is going to be true.
Also, it requires everyone to be on board with this change, including
webkit and Microsoft.
/ Jonas
Re: UMP / CORS: Implementor Interest
On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren wrote: > On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking wrote: >> >> As I've said before. I'd be interested in implementing UMP in firefox >> if we can come up with a reasonable API for using it. I.e. a separate >> constructor or flag or similar on XHR. This is assuming that UMP is a >> reasonable subset of CORS. > > Have you looked at the proposal I put in XHR2? It sets certain flags in CORS > that make it more or less the same as UMP. Why can't it be made exactly like UMP? All of the requirements in UMP have been discussed at length and in great detail on this list by some highly qualified people. The current UMP spec reflects all of that discussion. By your own admission, the CORS spec has not received the same level of review for these features. Why hasn't CORS adopted the UMP solution? --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking wrote: As I've said before. I'd be interested in implementing UMP in firefox if we can come up with a reasonable API for using it. I.e. a separate constructor or flag or similar on XHR. This is assuming that UMP is a reasonable subset of CORS. Have you looked at the proposal I put in XHR2? It sets certain flags in CORS that make it more or less the same as UMP. I don't really see why we would need UMP if we have that. There has been suggestions of changing header names. I'm not a big fan of the current names, but if we're going to fix them, i'd rather see a coherent strategy for all CORS headers than random spot fixes. Does that mean you would be willing to remove support for the current header names? If not I'm not sure if it is worth it. But if you are I will make a proposal. -- Anne van Kesteren http://annevankesteren.nl/
Re: UMP / CORS: Implementor Interest
On Mon, Apr 19, 2010 at 12:43 AM, Anne van Kesteren wrote: > Hopefully it helps calling out attention to this in a separate thread. > > In http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0043.html > Maciej states Apple has no interest in implementing UMP from the UMP > specification. (I believe this means that a CORS defined subset that roughly > matches UMP is fine.) They want to retain their CORS support. > > For Opera I can say we are planning on supporting on CORS in due course and > have no plans on implementing UMP from the UMP specification. > > It would be nice if the three other major implementors (i.e. Google, > Mozilla, and Microsoft) also stated their interest for both specifications, > especially including whether removing their current level of CORS support is > considered an option. I've forwarded your question to chromium-dev: http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/4ffa158e71ec4613# Adam
Re: UMP / CORS: Implementor Interest
On Mon, Apr 19, 2010 at 12:43 AM, Anne van Kesteren wrote: > Hopefully it helps calling out attention to this in a separate thread. > > In http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0043.html > Maciej states Apple has no interest in implementing UMP from the UMP > specification. (I believe this means that a CORS defined subset that roughly > matches UMP is fine.) They want to retain their CORS support. > > For Opera I can say we are planning on supporting on CORS in due course and > have no plans on implementing UMP from the UMP specification. > > It would be nice if the three other major implementors (i.e. Google, > Mozilla, and Microsoft) also stated their interest for both specifications, > especially including whether removing their current level of CORS support is > considered an option. As I've said before. I'd be interested in implementing UMP in firefox if we can come up with a reasonable API for using it. I.e. a separate constructor or flag or similar on XHR. This is assuming that UMP is a reasonable subset of CORS. There has been suggestions of changing header names. I'm not a big fan of the current names, but if we're going to fix them, i'd rather see a coherent strategy for all CORS headers than random spot fixes. / Jonas
