Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Tue, Apr 13, 2010 at 10:17 AM, Jonas Sicking wrote: > On Mon, Apr 12, 2010 at 5:28 PM, Jonas Sicking wrote: >> I wouldn't be opposed to implementing UMP, as long as there's a decent >> API for invoking it, and that it's a good subset relative to CORS. I >> think we've talked about various constructors or flags that let you >> use the XHR API together with the UMP protocol. I'm less concerned with the actual syntax, so please propose your preferred choice. I just want something easy to use with the right semantics. > Oh, I should mention one concern that I have with UMP though. The spec > seems to explicitly forbid sending the 'Referer' header [1]. I > understand the purpose of this as the Referer header can be > interpreted as ambient authentication. > > However a problem is that I think many sites rely on this header for > things other than authentication. Such as measuring load from various > 3rd parties, measuring who loads data in order to provide back links, > etc. This is done for public data as much as for private. > > I don't have a solution to propose. Nor do I at this time think that > this is a blocker issue. However I wouldn't be surprised if sites will > not want to deploy UMP because of this. There are a number of click tracking techniques that use unique URLs, instead of the Referer header. In many cases, these techniques are more reliable since some firewalls drop the Referer header and caching proxies can prevent requests from reaching the hosting server at all. I'm hopeful these techniques will support traffic analysis of public data offered via UMP, without the security hazards created by the Referer header. > [1] Section 3.2, Sending a Uniform Request, says: "MUST NOT add any > information obtained from ... or the referring resource". For what > it's worth, I think this could be made more clear. Thanks, I'll attempt a different phrasing. Thanks for the feedback. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Mon, Apr 12, 2010 at 5:28 PM, Jonas Sicking wrote: > On Mon, Apr 12, 2010 at 4:28 PM, Tyler Close wrote: >> On Mon, Apr 12, 2010 at 4:14 PM, Jonas Sicking wrote: >>> On Mon, Apr 12, 2010 at 3:48 PM, Tyler Close wrote: On Mon, Apr 12, 2010 at 3:41 PM, Jonas Sicking wrote: > On Mon, Apr 12, 2010 at 3:10 PM, Tyler Close > wrote: >>> I think even taken together, your set of subset conditions does >>> guarantee >>> that a CORS client implementation is automatically also a UMP client >>> implementation. If we went that way, then we would have to consider >>> whether >>> there will ever be client implementors of UMP itself, or it will be >>> impossible to fulfill CR exit criteria. >> >> If there are implementers of CORS, then by definition, there are >> implementers of UMP. I don't see anything in CR exit criteria that >> requires implementers to swear not to also implement other >> specifications. > > So is sending the 'Origin' and 'Referer' headers ok per UMP? Sending "Origin: null" is OK per UMP. Similarly, an "null"-like value for Referer would be OK. > The current CORS implementation in firefox always sends those headers. Then that implementation is only compatible with UMP when used in combination with some mechanism for putting the requesting content in an anonymous . Ideally, Firefox would allow this to be expressed via the messaging API instead of requiring the anonymous . > I would have imagined that UMP would explicitly forbid any ambient > authority or identity information other than IP number? Correct. >>> >>> It seems to me then that Firefox implements CORS, but does not >>> implement UMP. The fact that a web page can use javascript to >>> implement UMP using the primitives implemented by the browser doesn't >>> change the fact that the browser doesn't implement UMP. We have had >>> similar situations in the past where javascript libraries have been >>> able to implement various CSS features, despite those features not >>> being natively implemented by the browser. I also think it would be >>> possible to implement CORS purely in javascript as well, as long as >>> you can set the 'Origin' header for same-site XHR requests (this is >>> possible in older browser versions). >>> >>> We have traditionally not counted such javascript implementations >>> towards the "two implementations" requirement. >> >> Does that tradition necessarily apply to a specification that only >> defines a security policy and no API, such as CORS or UMP? That kind >> of spec hasn't been done before. With the CSS example, there is an >> actual piece of syntax you can point to and show that the browser >> doesn't implement it. In UMP, the only syntax to point at is the >> "Access-Control-Allow-Origin" header and Firefox implements that as >> specified. Neither CORS nor UMP specify the syntax required for making >> a request. The browser is free to use whatever arcane syntax it wants. > > Yes, both CORS and UMP are effectively protocol specifications. Other > specs, such as XHR L2, specifies when they are to be used. I don't > think that makes a difference as far as the 2 implementation > requirement though. But note that I'm not the ultimate authority on > the matter by any means. > >> In either case, my ultimate goal is to get a nice syntax for UMP in >> the browser. Given that we all recognize the value of this >> functionality and some have actually implemented it, why not give it a >> nice syntax? Shouldn't a future version of Firefox make it easy to >> express a uniform request instead of requiring the developer to jump >> through hoops? > > I wouldn't be opposed to implementing UMP, as long as there's a decent > API for invoking it, and that it's a good subset relative to CORS. I > think we've talked about various constructors or flags that let you > use the XHR API together with the UMP protocol. Oh, I should mention one concern that I have with UMP though. The spec seems to explicitly forbid sending the 'Referer' header [1]. I understand the purpose of this as the Referer header can be interpreted as ambient authentication. However a problem is that I think many sites rely on this header for things other than authentication. Such as measuring load from various 3rd parties, measuring who loads data in order to provide back links, etc. This is done for public data as much as for private. I don't have a solution to propose. Nor do I at this time think that this is a blocker issue. However I wouldn't be surprised if sites will not want to deploy UMP because of this. [1] Section 3.2, Sending a Uniform Request, says: "MUST NOT add any information obtained from ... or the referring resource". For what it's worth, I think this could be made more clear. / Jonas
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Apr 12, 2010, at 4:00 PM, ext Maciej Stachowiak wrote: On Apr 12, 2010, at 10:33 AM, Tyler Close wrote: I've added a new section to the wiki page, "UMP as subset of CORS": http://www.w3.org/Security/wiki/ Comparison_of_CORS_and_UMP#UMP_as_subset_of_CORS I do not think the set of subset criteria posted there matches what I proposed and what we've been discussing in this thread. Should I put some abbreviated form of my proposal in the wiki? I think that would be useful since you've now stated a subset of your original properties would be sufficient. I am not sure what the conventions are for editing this wiki page. AFAIK, no specific conventions were set for that page so anyone in the group should feel to modify it (I believe Thomas created the Security page so he indicate otherwise). -Art Barstow
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Tue, 13 Apr 2010 02:28:53 +0200, Jonas Sicking wrote: I wouldn't be opposed to implementing UMP, as long as there's a decent API for invoking it, and that it's a good subset relative to CORS. I think we've talked about various constructors or flags that let you use the XHR API together with the UMP protocol. XMLHttpRequest Level 2 defines a constructor for XMLHttpRequest that enforces certain properties of CORS. That gives you something that looks like UMP, but you don't need UMP for it. You just need to implement CORS and XMLHttpRequest Level 2. (It may be certain aspects need further clarification/fixing, but that seems somewhat unrelated of what would be the preferred approach.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Mon, 12 Apr 2010 15:49:22 +0200, Arthur Barstow wrote: Anne - as Maciej mentioned in another thread [2], it would be good to get your feedback on this subject. I don't really care about subset relations to be honest. Fixing bugs in CORS is fine, and I think that is what we should be focusing on, rather than trying to go along with several drafts that may or may not be subsets. [1] http://www.w3.org/Security/wiki/Comparison_of_CORS_and_UMP [2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0058.html -- Anne van Kesteren http://annevankesteren.nl/
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Mon, Apr 12, 2010 at 4:28 PM, Tyler Close wrote: > On Mon, Apr 12, 2010 at 4:14 PM, Jonas Sicking wrote: >> On Mon, Apr 12, 2010 at 3:48 PM, Tyler Close wrote: >>> On Mon, Apr 12, 2010 at 3:41 PM, Jonas Sicking wrote: On Mon, Apr 12, 2010 at 3:10 PM, Tyler Close wrote: >> I think even taken together, your set of subset conditions does guarantee >> that a CORS client implementation is automatically also a UMP client >> implementation. If we went that way, then we would have to consider >> whether >> there will ever be client implementors of UMP itself, or it will be >> impossible to fulfill CR exit criteria. > > If there are implementers of CORS, then by definition, there are > implementers of UMP. I don't see anything in CR exit criteria that > requires implementers to swear not to also implement other > specifications. So is sending the 'Origin' and 'Referer' headers ok per UMP? >>> >>> Sending "Origin: null" is OK per UMP. Similarly, an "null"-like value >>> for Referer would be OK. >>> The current CORS implementation in firefox always sends those headers. >>> >>> Then that implementation is only compatible with UMP when used in >>> combination with some mechanism for putting the requesting content in >>> an anonymous . Ideally, Firefox would allow this to be >>> expressed via the messaging API instead of requiring the anonymous >>> . >>> I would have imagined that UMP would explicitly forbid any ambient authority or identity information other than IP number? >>> >>> Correct. >> >> It seems to me then that Firefox implements CORS, but does not >> implement UMP. The fact that a web page can use javascript to >> implement UMP using the primitives implemented by the browser doesn't >> change the fact that the browser doesn't implement UMP. We have had >> similar situations in the past where javascript libraries have been >> able to implement various CSS features, despite those features not >> being natively implemented by the browser. I also think it would be >> possible to implement CORS purely in javascript as well, as long as >> you can set the 'Origin' header for same-site XHR requests (this is >> possible in older browser versions). >> >> We have traditionally not counted such javascript implementations >> towards the "two implementations" requirement. > > Does that tradition necessarily apply to a specification that only > defines a security policy and no API, such as CORS or UMP? That kind > of spec hasn't been done before. With the CSS example, there is an > actual piece of syntax you can point to and show that the browser > doesn't implement it. In UMP, the only syntax to point at is the > "Access-Control-Allow-Origin" header and Firefox implements that as > specified. Neither CORS nor UMP specify the syntax required for making > a request. The browser is free to use whatever arcane syntax it wants. Yes, both CORS and UMP are effectively protocol specifications. Other specs, such as XHR L2, specifies when they are to be used. I don't think that makes a difference as far as the 2 implementation requirement though. But note that I'm not the ultimate authority on the matter by any means. > In either case, my ultimate goal is to get a nice syntax for UMP in > the browser. Given that we all recognize the value of this > functionality and some have actually implemented it, why not give it a > nice syntax? Shouldn't a future version of Firefox make it easy to > express a uniform request instead of requiring the developer to jump > through hoops? I wouldn't be opposed to implementing UMP, as long as there's a decent API for invoking it, and that it's a good subset relative to CORS. I think we've talked about various constructors or flags that let you use the XHR API together with the UMP protocol. / Jonas
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Mon, Apr 12, 2010 at 4:14 PM, Jonas Sicking wrote: > On Mon, Apr 12, 2010 at 3:48 PM, Tyler Close wrote: >> On Mon, Apr 12, 2010 at 3:41 PM, Jonas Sicking wrote: >>> On Mon, Apr 12, 2010 at 3:10 PM, Tyler Close wrote: > I think even taken together, your set of subset conditions does guarantee > that a CORS client implementation is automatically also a UMP client > implementation. If we went that way, then we would have to consider > whether > there will ever be client implementors of UMP itself, or it will be > impossible to fulfill CR exit criteria. If there are implementers of CORS, then by definition, there are implementers of UMP. I don't see anything in CR exit criteria that requires implementers to swear not to also implement other specifications. >>> >>> So is sending the 'Origin' and 'Referer' headers ok per UMP? >> >> Sending "Origin: null" is OK per UMP. Similarly, an "null"-like value >> for Referer would be OK. >> >>> The current CORS implementation in firefox always sends those headers. >> >> Then that implementation is only compatible with UMP when used in >> combination with some mechanism for putting the requesting content in >> an anonymous . Ideally, Firefox would allow this to be >> expressed via the messaging API instead of requiring the anonymous >> . >> >>> I would have imagined that UMP would explicitly forbid any ambient >>> authority or identity information other than IP number? >> >> Correct. > > It seems to me then that Firefox implements CORS, but does not > implement UMP. The fact that a web page can use javascript to > implement UMP using the primitives implemented by the browser doesn't > change the fact that the browser doesn't implement UMP. We have had > similar situations in the past where javascript libraries have been > able to implement various CSS features, despite those features not > being natively implemented by the browser. I also think it would be > possible to implement CORS purely in javascript as well, as long as > you can set the 'Origin' header for same-site XHR requests (this is > possible in older browser versions). > > We have traditionally not counted such javascript implementations > towards the "two implementations" requirement. Does that tradition necessarily apply to a specification that only defines a security policy and no API, such as CORS or UMP? That kind of spec hasn't been done before. With the CSS example, there is an actual piece of syntax you can point to and show that the browser doesn't implement it. In UMP, the only syntax to point at is the "Access-Control-Allow-Origin" header and Firefox implements that as specified. Neither CORS nor UMP specify the syntax required for making a request. The browser is free to use whatever arcane syntax it wants. In either case, my ultimate goal is to get a nice syntax for UMP in the browser. Given that we all recognize the value of this functionality and some have actually implemented it, why not give it a nice syntax? Shouldn't a future version of Firefox make it easy to express a uniform request instead of requiring the developer to jump through hoops? --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Mon, Apr 12, 2010 at 3:48 PM, Tyler Close wrote: > On Mon, Apr 12, 2010 at 3:41 PM, Jonas Sicking wrote: >> On Mon, Apr 12, 2010 at 3:10 PM, Tyler Close wrote: I think even taken together, your set of subset conditions does guarantee that a CORS client implementation is automatically also a UMP client implementation. If we went that way, then we would have to consider whether there will ever be client implementors of UMP itself, or it will be impossible to fulfill CR exit criteria. >>> >>> If there are implementers of CORS, then by definition, there are >>> implementers of UMP. I don't see anything in CR exit criteria that >>> requires implementers to swear not to also implement other >>> specifications. >> >> So is sending the 'Origin' and 'Referer' headers ok per UMP? > > Sending "Origin: null" is OK per UMP. Similarly, an "null"-like value > for Referer would be OK. > >> The current CORS implementation in firefox always sends those headers. > > Then that implementation is only compatible with UMP when used in > combination with some mechanism for putting the requesting content in > an anonymous . Ideally, Firefox would allow this to be > expressed via the messaging API instead of requiring the anonymous > . > >> I would have imagined that UMP would explicitly forbid any ambient >> authority or identity information other than IP number? > > Correct. It seems to me then that Firefox implements CORS, but does not implement UMP. The fact that a web page can use javascript to implement UMP using the primitives implemented by the browser doesn't change the fact that the browser doesn't implement UMP. We have had similar situations in the past where javascript libraries have been able to implement various CSS features, despite those features not being natively implemented by the browser. I also think it would be possible to implement CORS purely in javascript as well, as long as you can set the 'Origin' header for same-site XHR requests (this is possible in older browser versions). We have traditionally not counted such javascript implementations towards the "two implementations" requirement. / Jonas
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Mon, Apr 12, 2010 at 3:41 PM, Jonas Sicking wrote: > On Mon, Apr 12, 2010 at 3:10 PM, Tyler Close wrote: >>> I think even taken together, your set of subset conditions does guarantee >>> that a CORS client implementation is automatically also a UMP client >>> implementation. If we went that way, then we would have to consider whether >>> there will ever be client implementors of UMP itself, or it will be >>> impossible to fulfill CR exit criteria. >> >> If there are implementers of CORS, then by definition, there are >> implementers of UMP. I don't see anything in CR exit criteria that >> requires implementers to swear not to also implement other >> specifications. > > So is sending the 'Origin' and 'Referer' headers ok per UMP? Sending "Origin: null" is OK per UMP. Similarly, an "null"-like value for Referer would be OK. > The current CORS implementation in firefox always sends those headers. Then that implementation is only compatible with UMP when used in combination with some mechanism for putting the requesting content in an anonymous . Ideally, Firefox would allow this to be expressed via the messaging API instead of requiring the anonymous . > I would have imagined that UMP would explicitly forbid any ambient > authority or identity information other than IP number? Correct. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Mon, Apr 12, 2010 at 3:10 PM, Tyler Close wrote: >> I think even taken together, your set of subset conditions does guarantee >> that a CORS client implementation is automatically also a UMP client >> implementation. If we went that way, then we would have to consider whether >> there will ever be client implementors of UMP itself, or it will be >> impossible to fulfill CR exit criteria. > > If there are implementers of CORS, then by definition, there are > implementers of UMP. I don't see anything in CR exit criteria that > requires implementers to swear not to also implement other > specifications. So is sending the 'Origin' and 'Referer' headers ok per UMP? The current CORS implementation in firefox always sends those headers. I would have imagined that UMP would explicitly forbid any ambient authority or identity information other than IP number? / Jonas
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Mon, Apr 12, 2010 at 1:00 PM, Maciej Stachowiak wrote: > > On Apr 12, 2010, at 10:33 AM, Tyler Close wrote: > >> On Mon, Apr 12, 2010 at 6:49 AM, Arthur Barstow >> wrote: >>> >>> Maciej, Tyler - thanks for continuing this discussion. I think it would >>> be >>> helpful to have consensus on what we mean by subsetting in this context. >>> (Perhaps the agreed definition could be added to the CORS and UMP >>> Comparison >>> [1].) >> >> I've added a new section to the wiki page, "UMP as subset of CORS": >> >> >> http://www.w3.org/Security/wiki/Comparison_of_CORS_and_UMP#UMP_as_subset_of_CORS >> > > I do not think the set of subset criteria posted there matches what I > proposed and what we've been discussing in this thread. I intended criteria #3 to correspond to conditions A1+B2 in our last email exchange, which covers an UMP API to CORS resource message exchange. The last unnumbered criteria corresponds to conditions A2+B1 in our last email exchange, which covers a CORS API to UMP resource message exchange. Criteria #1 and #2 correspond to the additional safety aspects of condition C that you wanted explicitly stated. What aspect of the subset criteria have I missed? > Should I put some > abbreviated form of my proposal in the wiki? I am not sure what the > conventions are for editing this wiki page. > > I think the points you make on the wiki about cross-endangerment are good, > but they are not really subset criteria, that's a property we want for any > two Web platform features, and it could be achieved with a strategy of > making things completely different instead of the subset strategy. They do > represent relations that we should maintain however. I included these because our last email exchange indicated to me that you wanted them explicitly stated. > I think even taken together, your set of subset conditions does guarantee > that a CORS client implementation is automatically also a UMP client > implementation. If we went that way, then we would have to consider whether > there will ever be client implementors of UMP itself, or it will be > impossible to fulfill CR exit criteria. If there are implementers of CORS, then by definition, there are implementers of UMP. I don't see anything in CR exit criteria that requires implementers to swear not to also implement other specifications. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Apr 12, 2010, at 10:33 AM, Tyler Close wrote: On Mon, Apr 12, 2010 at 6:49 AM, Arthur Barstow wrote: Maciej, Tyler - thanks for continuing this discussion. I think it would be helpful to have consensus on what we mean by subsetting in this context. (Perhaps the agreed definition could be added to the CORS and UMP Comparison [1].) I've added a new section to the wiki page, "UMP as subset of CORS": http://www.w3.org/Security/wiki/Comparison_of_CORS_and_UMP#UMP_as_subset_of_CORS I do not think the set of subset criteria posted there matches what I proposed and what we've been discussing in this thread. Should I put some abbreviated form of my proposal in the wiki? I am not sure what the conventions are for editing this wiki page. I think the points you make on the wiki about cross-endangerment are good, but they are not really subset criteria, that's a property we want for any two Web platform features, and it could be achieved with a strategy of making things completely different instead of the subset strategy. They do represent relations that we should maintain however. I think even taken together, your set of subset conditions does guarantee that a CORS client implementation is automatically also a UMP client implementation. If we went that way, then we would have to consider whether there will ever be client implementors of UMP itself, or it will be impossible to fulfill CR exit criteria. Regards, Maciej
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Mon, Apr 12, 2010 at 6:49 AM, Arthur Barstow wrote: > Maciej, Tyler - thanks for continuing this discussion. I think it would be > helpful to have consensus on what we mean by subsetting in this context. > (Perhaps the agreed definition could be added to the CORS and UMP Comparison > [1].) I've added a new section to the wiki page, "UMP as subset of CORS": http://www.w3.org/Security/wiki/Comparison_of_CORS_and_UMP#UMP_as_subset_of_CORS --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
Maciej, Tyler - thanks for continuing this discussion. I think it would be helpful to have consensus on what we mean by subsetting in this context. (Perhaps the agreed definition could be added to the CORS and UMP Comparison [1].) Anne - as Maciej mentioned in another thread [2], it would be good to get your feedback on this subject. -Art Barstow [1] http://www.w3.org/Security/wiki/Comparison_of_CORS_and_UMP [2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/ 0058.html On Apr 8, 2010, at 8:51 PM, ext Maciej Stachowiak wrote: On Apr 8, 2010, at 5:20 PM, Tyler Close wrote: On Wed, Feb 3, 2010 at 7:40 PM, Maciej Stachowiak wrote: Actually, the other proposal is to provide an XHR-like API that would use CORS forcing a unique origin as an input parameter - there is no need to My hope is that this would be semantically equivalent to using UMP. This unique origin would still need to discard Set-Cookie response headers to prevent the accumulation of credentials associated with the unique origin. It would also need to prohibit the reuse of a TLS client authenticated connection or NTLM authenticated connection. It would also need to prevent use of cache entries populated by non-uniform requests. The CORS draft is also unclear on what happens with the Referer header. Good point. It seems like these should all be raised as issues on CORS. I will do it if you don't beat me. What I'm looking for is a clear and objective way to evaluate the desired subset properties. Here are some clear-cut subset properties that I think will give most of the interoperability and ease of implementation you want: (A) Every Uniform Request should also be a valid CORS request. . ...with the same semantics. The goals being: 1) an UMP API can safely and successfully send a uniform request to a CORS resource 2) a CORS API can safely send a request to an UMP resource, which may choose to either fail or allow the request Sounds good, although I meant this to only be a syntactic criterion - (C) is intended to be the semantic / processing requirements criterion. (B) Every Uniform Response should also be a valid CORS response. ...with the same semantics. The goal being: 1) an UMP resource can safely and successfully return a uniform response to a CORS API 2) a CORS resource can safely and successfully return a uniform response to an UMP API Given the above, a developer can read only UMP and ignore CORS and still write safe code that works. That's what I mean by "subset". Also agree to your clarifications. (C) When a CORS client makes a Uniform Request and receives either a Uniform Response, or an HTTP response that is neither a Uniform Response nor a response would allow access under CORS rules, then the processing requirements under CORS are the same as the processing requirements under UMP. (C) seems the same as (B) if we assume both CORS and UMP properly reject Same-Origin-only responses. I'd like to have a rule explicitly about the processing requirements rather than have that implied by rules about semantics. "Semantics" is not quite clear-cut enough to evaluate objectively. Currently (A) and (C) do not hold. One counter-example to (A): a request that contains no Origin header at all, not even Origin: null, may be a Uniform Request but is not a valid CORS request. I think it would be safe for a CORS resource to assume Origin: null when no Origin is provided. I agree the current spec doesn't say so. Either UMP or CORS could change here, but we have to agree which to change and do it. I don't actually know if assuming "Origin: null" in the absence of an origin is safe; that's a change to the model that would have to be reviewed. I am pretty confident that adding "Origin: null" to a Uniform Request does not pose a security risk, though it may be seen as unnecessary from the UMP-only perspective. I also do not know if this is the only counter-example; I did not do a thorough review UMP and CORS against these criteria at the time. I think we should review carefully according to these criteria and reconcile all violations before either spec goes to CR (and ideally before either goes to LC). One counter-example to (C): UMP will follow a redirect that is neither a Uniform Response nor allows access under CORS; but CORS will not. This has since been reconciled. Good news. I am not currently aware of any violations of (B). (B)(2) is currently violated by the difference in response header filtering. This can be reconciled when the current open CORS issue about response headers is closed. It'll be interesting to see how this issue is resolved since it is potentially very contentious. Banning response headers seriously affects the extensibility of HTTP. Can you explain more specifically what the (B) violation is? Also, the reason the conditions on (C) are a little funny: I think it's possible that a CORS implementation could make a Uniform Request that
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Apr 8, 2010, at 5:20 PM, Tyler Close wrote: On Wed, Feb 3, 2010 at 7:40 PM, Maciej Stachowiak wrote: Actually, the other proposal is to provide an XHR-like API that would use CORS forcing a unique origin as an input parameter - there is no need to My hope is that this would be semantically equivalent to using UMP. This unique origin would still need to discard Set-Cookie response headers to prevent the accumulation of credentials associated with the unique origin. It would also need to prohibit the reuse of a TLS client authenticated connection or NTLM authenticated connection. It would also need to prevent use of cache entries populated by non-uniform requests. The CORS draft is also unclear on what happens with the Referer header. Good point. It seems like these should all be raised as issues on CORS. I will do it if you don't beat me. What I'm looking for is a clear and objective way to evaluate the desired subset properties. Here are some clear-cut subset properties that I think will give most of the interoperability and ease of implementation you want: (A) Every Uniform Request should also be a valid CORS request. . ...with the same semantics. The goals being: 1) an UMP API can safely and successfully send a uniform request to a CORS resource 2) a CORS API can safely send a request to an UMP resource, which may choose to either fail or allow the request Sounds good, although I meant this to only be a syntactic criterion - (C) is intended to be the semantic / processing requirements criterion. (B) Every Uniform Response should also be a valid CORS response. ...with the same semantics. The goal being: 1) an UMP resource can safely and successfully return a uniform response to a CORS API 2) a CORS resource can safely and successfully return a uniform response to an UMP API Given the above, a developer can read only UMP and ignore CORS and still write safe code that works. That's what I mean by "subset". Also agree to your clarifications. (C) When a CORS client makes a Uniform Request and receives either a Uniform Response, or an HTTP response that is neither a Uniform Response nor a response would allow access under CORS rules, then the processing requirements under CORS are the same as the processing requirements under UMP. (C) seems the same as (B) if we assume both CORS and UMP properly reject Same-Origin-only responses. I'd like to have a rule explicitly about the processing requirements rather than have that implied by rules about semantics. "Semantics" is not quite clear-cut enough to evaluate objectively. Currently (A) and (C) do not hold. One counter-example to (A): a request that contains no Origin header at all, not even Origin: null, may be a Uniform Request but is not a valid CORS request. I think it would be safe for a CORS resource to assume Origin: null when no Origin is provided. I agree the current spec doesn't say so. Either UMP or CORS could change here, but we have to agree which to change and do it. I don't actually know if assuming "Origin: null" in the absence of an origin is safe; that's a change to the model that would have to be reviewed. I am pretty confident that adding "Origin: null" to a Uniform Request does not pose a security risk, though it may be seen as unnecessary from the UMP-only perspective. I also do not know if this is the only counter-example; I did not do a thorough review UMP and CORS against these criteria at the time. I think we should review carefully according to these criteria and reconcile all violations before either spec goes to CR (and ideally before either goes to LC). One counter-example to (C): UMP will follow a redirect that is neither a Uniform Response nor allows access under CORS; but CORS will not. This has since been reconciled. Good news. I am not currently aware of any violations of (B). (B)(2) is currently violated by the difference in response header filtering. This can be reconciled when the current open CORS issue about response headers is closed. It'll be interesting to see how this issue is resolved since it is potentially very contentious. Banning response headers seriously affects the extensibility of HTTP. Can you explain more specifically what the (B) violation is? Also, the reason the conditions on (C) are a little funny: I think it's possible that a CORS implementation could make a Uniform Request that receives a non-Uniform Response that nontheless allows access, but I'm actually not sure if this is possible. It's definitely possible if it is legal to send multiple "Access-Control- Allow-Origin:" headers in a response, or to send "Access-Control- Allow-Origin: null". I am not sure if either of these is allowed. I'm also not sure if there are other possible CORS responses that would violate the Uniform Request requirements or UMP processing model. If there are no such conflicts, then we could t
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
On Wed, Feb 3, 2010 at 7:40 PM, Maciej Stachowiak wrote: > Actually, the other proposal is to provide an XHR-like API that would use > CORS forcing a unique origin as an input parameter - there is no need to > My hope is that this would be semantically equivalent to using UMP. This unique origin would still need to discard Set-Cookie response headers to prevent the accumulation of credentials associated with the unique origin. It would also need to prohibit the reuse of a TLS client authenticated connection or NTLM authenticated connection. It would also need to prevent use of cache entries populated by non-uniform requests. The CORS draft is also unclear on what happens with the Referer header. > What I'm looking for is a clear and objective way to evaluate the desired > subset properties. Here are some clear-cut subset properties that I think > will give most of the interoperability and ease of implementation you want: > > (A) Every Uniform Request should also be a valid CORS request. . ...with the same semantics. The goals being: 1) an UMP API can safely and successfully send a uniform request to a CORS resource 2) a CORS API can safely send a request to an UMP resource, which may choose to either fail or allow the request > (B) Every Uniform Response should also be a valid CORS response. ...with the same semantics. The goal being: 1) an UMP resource can safely and successfully return a uniform response to a CORS API 2) a CORS resource can safely and successfully return a uniform response to an UMP API Given the above, a developer can read only UMP and ignore CORS and still write safe code that works. That's what I mean by "subset". > (C) When a CORS client makes a Uniform Request and receives either a Uniform > Response, or an HTTP response that is neither a Uniform Response nor a > response would allow access under CORS rules, then the processing > requirements under CORS are the same as the processing requirements under UMP. (C) seems the same as (B) if we assume both CORS and UMP properly reject Same-Origin-only responses. > Currently (A) and (C) do not hold. One counter-example to (A): a request that > contains no Origin header at all, not even Origin: null, may be a Uniform > Request but is not a valid CORS request. I think it would be safe for a CORS resource to assume Origin: null when no Origin is provided. I agree the current spec doesn't say so. > One counter-example to (C): UMP will follow a redirect that is neither a > Uniform Response nor allows access under CORS; but CORS will not. This has since been reconciled. > I am not currently aware of any violations of (B). (B)(2) is currently violated by the difference in response header filtering. This can be reconciled when the current open CORS issue about response headers is closed. It'll be interesting to see how this issue is resolved since it is potentially very contentious. Banning response headers seriously affects the extensibility of HTTP. > Also, the reason the conditions on (C) are a little funny: I think it's > possible that a CORS implementation could make a Uniform Request that > receives a non-Uniform Response that nontheless allows access, but I'm > actually not sure if this is possible. It's definitely possible if it is > legal to send multiple "Access-Control-Allow-Origin:" headers in a response, > or to send "Access-Control-Allow-Origin: null". I am not sure if either of > these is allowed. I'm also not sure if there are other possible CORS > responses that would violate the Uniform Request requirements or UMP > processing model. If there are no such conflicts, then we could tighten C to: An UMP resource is only allowed to respond with a single Access-Control-Allow-Origin: *. Other values are undefined by UMP and so don't offer any defined behavior that an UMP resource can rely upon. That's not a violation of (C) through, since (C) says the response is either a uniform response or one rejected by both UMP and CORS. > (C') When a CORS client makes a Uniform Request and receives any response, > then the processing requirements under CORS are the same as the processing > requirements under UMP. CORS defines more kinds of successful responses than does UMP, since it supports additional values for the Access-Control-Allow-Origin header. So (C') would be violated if a non-compliant UMP resource responded with an Access-Control-Allow-Origin header with a value matching the received Origin header. > Also none of this squarely addresses your original point 1: whether a UMP > server would automatically be compatible with a CORS request that is *not* a > Uniform Request. That would require a condition something like this: > > (D) When a UMP server receives a CORS Request that is not a Uniform Request, > if it would have granted access to the same request with all user and server > credentials removed, it must process the CORS request in the same way as it > would if all credentials had in fact
Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
Hi Mark, First a couple of corrections... On Feb 3, 2010, at 5:31 PM, Mark S. Miller wrote: > Hi Maciej and Tyler, > > IMO, the important subsetting points, in priority order, are: > > 1) Server-side behavior compatible with UMP is automatically compatible with > CORS and with present CORS-like browser behaviors. > 2) The client-side mechanisms one needs to implement UMP correctly are a > small subset of the mechanisms one needs to implement CORS. Having made the > investment in implementing CORS-like mechanisms, no significant further > internal mechanism is needed to implement UMP. (Indeed, I wouldn't be > surprised if one could derive an UMP implementation from a CORS > implementation mostly by commenting out code.) That's unlikely. To implement UMP, we would have to write code to remove or specifically avoid things that we'd otherwise put in every request. (Beyond that, we'd also want to share code with CORS, so having something that's defined as a CORS subset or mode would make it easy to know where to put the if statements.) > 3) Given other proposals already on the table -- CORS and unique-origin > iframes -- one could build the proposed xhr-like UniformRequest API as a > library on top. Though these requests would include an unneeded "Origin: > null" header, such a header is not a credential and so would not violate any > MUST in UMP. The messages would still be Uniform. Actually, the other proposal is to provide an XHR-like API that would use CORS forcing a unique origin as an input parameter - there is no need to My hope is that this would be semantically equivalent to using UMP. > > I think this thread has focussed exclusively on point #3 and lost sight of > points #1 and #2. What I'm looking for is a clear and objective way to evaluate the desired subset properties. Here are some clear-cut subset properties that I think will give most of the interoperability and ease of implementation you want: (A) Every Uniform Request should also be a valid CORS request. (B) Every Uniform Response should also be a valid CORS response. (C) When a CORS client makes a Uniform Request and receives either a Uniform Response, or an HTTP response that is neither a Uniform Response nor a response would allow access under CORS rules, then the processing requirements under CORS are the same as the processing requirements under UMP. Currently (A) and (C) do not hold. One counter-example to (A): a request that contains no Origin header at all, not even Origin: null, may be a Uniform Request but is not a valid CORS request. One counter-example to (C): UMP will follow a redirect that is neither a Uniform Response nor allows access under CORS; but CORS will not. I am not currently aware of any violations of (B). Also, the reason the conditions on (C) are a little funny: I think it's possible that a CORS implementation could make a Uniform Request that receives a non-Uniform Response that nontheless allows access, but I'm actually not sure if this is possible. It's definitely possible if it is legal to send multiple "Access-Control-Allow-Origin:" headers in a response, or to send "Access-Control-Allow-Origin: null". I am not sure if either of these is allowed. I'm also not sure if there are other possible CORS responses that would violate the Uniform Request requirements or UMP processing model. If there are no such conflicts, then we could tighten C to: (C') When a CORS client makes a Uniform Request and receives any response, then the processing requirements under CORS are the same as the processing requirements under UMP. Also none of this squarely addresses your original point 1: whether a UMP server would automatically be compatible with a CORS request that is *not* a Uniform Request. That would require a condition something like this: (D) When a UMP server receives a CORS Request that is not a Uniform Request, if it would have granted access to the same request with all user and server credentials removed, it must process the CORS request in the same way as it would if all credentials had in fact been omitted. I don't think (D) follows from the current requirements, and I'm not entirely sure if it is practical to enforce through requirements. Whether CORS and UMP satisfy the various subset relations described here is something that can be determined objectively through review of both drafts. Relation conditions like "small subset of the mechanisms" or "automatically compatible" are harder to pin down. I would like to ensure that CORS and UMP satisfy at least relations (A), (B) and (C), and if desirable and practical, also (C') and (D). Note: I'm not making any assumptions here about which of CORS or UMP should change to address any given violation of the subset relation. If we satisfy all of these relations, then once we have an API that allows making requests that satisfy the Uniform Request requirements via CORS, it will be usable as a UMP API as
[UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())
Hi Maciej and Tyler, IMO, the important subsetting points, in priority order, are: 1) Server-side behavior compatible with UMP is automatically compatible with CORS and with present CORS-like browser behaviors. 2) The client-side mechanisms one needs to implement UMP correctly are a small subset of the mechanisms one needs to implement CORS. Having made the investment in implementing CORS-like mechanisms, no significant further internal mechanism is needed to implement UMP. (Indeed, I wouldn't be surprised if one could derive an UMP implementation from a CORS implementation mostly by commenting out code.) 3) Given other proposals already on the table -- CORS and unique-origin iframes -- one could build the proposed xhr-like UniformRequest API as a library on top. Though these requests would include an unneeded "Origin: null" header, such a header is not a credential and so would not violate any MUST in UMP. The messages would still be Uniform. I think this thread has focussed exclusively on point #3 and lost sight of points #1 and #2. -- Cheers, --MarkM
