Re: [UMP] Feedback on UMP from a quick read
On Jan 9, 2010, at 1:57 PM, Tyler Close wrote: On Sat, Jan 9, 2010 at 10:20 AM, Adam Barth w...@adambarth.com wrote: (As Maciej says, CORS doesn't appear to have this hole.) Indeed, I misread the section on simple requests: http://www.w3.org/TR/access-control/#simple-cross-origin-request0 I didn't realize the algorithm was checking the response headers in several different places. I guess that's one of the dangers of an algorithmic specification: you must have the whole thing in mind before you can make any statements about what it does or does not do. Given this correction, I'm reconsidering following of non-uniform redirects. I still don't like that it makes it look like your example design is safe, when in fact there are several non-confidentiality problems with it, and using JSON for the final response also breaks confidentiality. Thanks for giving this another look. As Maciej says, just because the server can screw up it's confidentiality doesn't means we should prevent servers from doing the secure thing. By this argument, we should remove the same-origin policy entirely because some sites might have XSS vulnerabilities. Deciding to use a popular and standard media-type in its intended setting is not at all comparable to filling your site with XSS vulnerabilities. I did not read Maciej's email as suggesting otherwise. I don't think I suggested otherwise, nor do I think Adam suggested that I suggested otherwise. What I meant to say was that the weak confidentiality protection for ECMAScript should not be used as an excuse to weaken protection for other resources. This is a leaky and awkward hole but it does not justify ignoring more general confidentiality concerns in any context. Adam's analogy was that the widespread existence of XSS bugs is not a reason to remove all cross-domain protection either. While it's not a 100% on-point analogy, I got the point he was making and I recognize that it is similar to my own. Regards, Maciej
Re: Publishing Selectors API Level 2 as an FPWD?
On 8/01/10 1:19 AM, Lachlan Hunt wrote: Hi, Now that Selectors API Level 1 is published and basically all but finalised (just waiting for some implementations to be officially released before taking it to REC), can we publish Selectors API Level 2 as an FPWD? It would be useful to have it more widely reviewed, especially since Mozilla and WebKit have begun their implementation of matchesSelector, which is defined in it. The editor's draft is here. http://dev.w3.org/2006/webapi/selectors-api2/ FYI, it seems the whole Status of this Document hasn't been updated for Selectors-API2. For instance: This document has been approved for publication as a Candidate Recommendation by the working group. However, in light of existing interoperable implementations, the group is considering requesting publication as a Proposed Recommendation. Also, the links to the W3C CVS are for Selectors-API, not Selectors-API2. I can't see the value of queryScopedSelector*() methods. The original rationale was that JS libs could potentially drop their selector engines, but this isn't facilitated by the proposed methods. Given that JS libs will still have to parse the selectors it is a trivial step to call querySelector*(rewrittenSelector, refNode) rather than queryScopedSelector*(rewrittenSelector) The queryScopedSelector*() methods have misleading names - they don't match the definition of scope. It would be ridiculous to stick with those names if there are no implementations already out there. Similarly, the :scope pseudo-class has a misleading name.
Re: Publishing Selectors API Level 2 as an FPWD?
Sean Hogan wrote: On 8/01/10 1:19 AM, Lachlan Hunt wrote: can we publish Selectors API Level 2 as an FPWD? http://dev.w3.org/2006/webapi/selectors-api2/ FYI, it seems the whole Status of this Document hasn't been updated for Selectors-API2. Yeah, that will get fixed up when I get the spec ready for publication and do all the PubRules checks, etc. Also, the links to the W3C CVS are for Selectors-API, not Selectors-API2. Likewise. I can't see the value of queryScopedSelector*() methods. The original rationale was that JS libs could potentially drop their selector engines, but this isn't facilitated by the proposed methods. Given that JS libs will still have to parse the selectors it is a trivial step to call querySelector*(rewrittenSelector, refNode) rather than queryScopedSelector*(rewrittenSelector) Personally, I agree and was initially hesitant about adding it, but there were some reasonable arguments put forth suggesting that lifting the burden of pre-processing the selector to prepend :scope from JS libs would be useful [1]. Evidence to the contrary would be helpful. John Resig also once told me he had an alternative proposal, but he hasn't yet shared it with me. The queryScopedSelector*() methods have misleading names - they don't match the definition of scope. It would be ridiculous to stick with those names if there are no implementations already out there. Do you have a better alternative suggestion? Similarly, the :scope pseudo-class has a misleading name. I've tried various alternative names, like :context, :reference, etc., but so far scope seems to be the least objectionable. But all things considered, I don't think :scope is a particularly bad name, since it's name somewhat describes it's purpose and relates it to its utility in scoped stylesheets. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [UMP] Proxy-Authorization
On Sat, Jan 9, 2010 at 10:50 AM, Adam Barth w...@adambarth.com wrote: The UMP spec says: [[ The user agent must not add any information obtained from: HTTP cookies, HTTP Auth headers, client certificates, or the referring resource, including its origin (other than the request parameters). ]] Does this include the Proxy-Authorization header? If so, how can clients behind proxies that require authorization use web sites that depend on UMP? Good catch. I've updated the text on sending a uniform request to account for this proxy information. The new text is: 3.2 Sending a Uniform Request The content of a uniform request is determined solely by the provided uniform request parameters, the user-agent's response cache and the required structure of an HTTP request. If a user-agent is configured to send the request via a proxy, instead of directly to the host specified by the request URL, this proxy configuration information can be used to send the request to the proxy. In this case, the request sent by the user-agent is not a uniform request; however, the request ultimately delivered to the resource host will be, since any Proxy-Authorization request header is removed by the proxy before forwarding the request to the resource host. Other than this proxy information, the user-agent must not augment the sent request with any data that identifies the user or the origin of the request. In particular, the user-agent must not add any information obtained from: HTTP cookies, HTTP Auth headers, client certificates, or the referring resource, including its origin (other than the request parameters). See: http://dev.w3.org/2006/waf/UMP/#request-sending --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [UMP] Proxy-Authorization
I don't quite understand this part of that text: [[ In this case, the request sent by the user-agent is not a uniform request; however, the request ultimately delivered to the resource host will be, since any Proxy-Authorization request header is removed by the proxy before forwarding the request to the resource host. ]] Concretely, suppose: 1) The user has authenticated to a proxy P using the Proxy-Authenticate / Proxy-Authentication protocol. 2) The user visits web site A which uses the UniformRequest API to generate a request R to web site B. 3) Based on that text, it sounds like R is delivered to P with the Proxy-Authentication information intact. Presumably the proxy will forward the request to B. 4) B responds with Access-Control-Allow-Origin: *. Now, is B's response delivered to A? More abstractly, why aren't we worrying about P misbehaving based on the ambient authority in R (i.e., the Proxy-Authentication information)? Why do the security considerations for the Proxy-Authorization header differ from the security considerations for the Authorization header? Adam On Sun, Jan 10, 2010 at 2:14 PM, Tyler Close tyler.cl...@gmail.com wrote: On Sat, Jan 9, 2010 at 10:50 AM, Adam Barth w...@adambarth.com wrote: The UMP spec says: [[ The user agent must not add any information obtained from: HTTP cookies, HTTP Auth headers, client certificates, or the referring resource, including its origin (other than the request parameters). ]] Does this include the Proxy-Authorization header? If so, how can clients behind proxies that require authorization use web sites that depend on UMP? Good catch. I've updated the text on sending a uniform request to account for this proxy information. The new text is: 3.2 Sending a Uniform Request The content of a uniform request is determined solely by the provided uniform request parameters, the user-agent's response cache and the required structure of an HTTP request. If a user-agent is configured to send the request via a proxy, instead of directly to the host specified by the request URL, this proxy configuration information can be used to send the request to the proxy. In this case, the request sent by the user-agent is not a uniform request; however, the request ultimately delivered to the resource host will be, since any Proxy-Authorization request header is removed by the proxy before forwarding the request to the resource host. Other than this proxy information, the user-agent must not augment the sent request with any data that identifies the user or the origin of the request. In particular, the user-agent must not add any information obtained from: HTTP cookies, HTTP Auth headers, client certificates, or the referring resource, including its origin (other than the request parameters). See: http://dev.w3.org/2006/waf/UMP/#request-sending --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [UMP] Feedback on UMP from a quick read
On Sun, Jan 10, 2010 at 6:54 AM, Maciej Stachowiak m...@apple.com wrote: What I meant to say was that the weak confidentiality protection for ECMAScript should not be used as an excuse to weaken protection for other resources. And I was never proposing to weaken existing protection for other resources. My reasoning rested on two points: 1. I thought this redirect behavior was the CORS defined behavior. 2. Even if it's not, this WG is currently defining the security model for newly allowed cross-domain requests. It's reasonable to say that if you refer to a resource using a guessable URL and respond to a uniform GET request with a response marked as accessible by any origin, then there's no confidentiality. This rule has no impact on the security of existing resources, since they don't yet have a Same Origin Policy opt-out header. This rule has the advantage of covering up the bizarre Same Origin Policy handling of ECMAScript data, thus eliminating a dangerous security gotcha for developers. It's bad when developers think they've implemented a design that provides confidentiality, and that turns out not to be true. We should be trying for a simple set of rules that yield easily predictable results. This is a leaky and awkward hole but it does not justify ignoring more general confidentiality concerns in any context. Again, I wasn't doing that. I was looking at one very specific context that doesn't even exist yet, because we're currently defining it. Adam's analogy was that the widespread existence of XSS bugs is not a reason to remove all cross-domain protection either. That would be an extremely foolish thing to propose. I don't think I was being extremely foolish. The analogy is a poor one. While it's not a 100% on-point analogy, I got the point he was making and I recognize that it is similar to my own. In that case, please consider the argument I present at the top of this email. The proposal is different from what you've understood. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: Publishing Selectors API Level 2 as an FPWD?
On 11/01/10 8:29 AM, Lachlan Hunt wrote: Sean Hogan wrote: On 8/01/10 1:19 AM, Lachlan Hunt wrote: can we publish Selectors API Level 2 as an FPWD? http://dev.w3.org/2006/webapi/selectors-api2/ I can't see the value of queryScopedSelector*() methods. The original rationale was that JS libs could potentially drop their selector engines, but this isn't facilitated by the proposed methods. Given that JS libs will still have to parse the selectors it is a trivial step to call querySelector*(rewrittenSelector, refNode) rather than queryScopedSelector*(rewrittenSelector) Personally, I agree and was initially hesitant about adding it, but there were some reasonable arguments put forth suggesting that lifting the burden of pre-processing the selector to prepend :scope from JS libs would be useful [1]. Evidence to the contrary would be helpful. John Resig also once told me he had an alternative proposal, but he hasn't yet shared it with me. That's my point - in its current form queryScopedSelector*() doesn't lift that burden of pre-processing. I don't know about all selector engines, but jQuery, for example, has several non-standard selectors that will continue to require pre-processing. :first, :last, :even, :odd, :eq(), :gt(), :lt(), :header, :animated, :contains(), :has(), :parent, :input, :text, :password, :radio, :checkbox, :submit, :image, :reset, :button, :file Even if jQuery deprecates non-standard selectors, the current spec for queryScopedSelector*() doesn't support the jQuery implicitly scoped selector *. The queryScopedSelector*() methods have misleading names - they don't match the definition of scope. It would be ridiculous to stick with those names if there are no implementations already out there. Do you have a better alternative suggestion? Similarly, the :scope pseudo-class has a misleading name. I've tried various alternative names, like :context, :reference, etc., but so far scope seems to be the least objectionable. But all things considered, I don't think :scope is a particularly bad name, since it's name somewhat describes it's purpose and relates it to its utility in scoped stylesheets. :reference matches the text of the spec. :context would be second choice I guess. I seem to recall :ref-node and :context-node also being suggested. :scope only describes its purpose in specific cases - queries with one of the following forms: element.queryScopedSelector(:scope *) element.queryScopedSelector(:scope *) In the following forms :scope is misleading: element.queryScopedSelector(:scope + *) element.queryScopedSelector(:scope ~ *) and especially: element.querySelector(* :scope *, refNode)
Re: Publishing Selectors API Level 2 as an FPWD?
On 1/10/10 11:58 PM, Sean Hogan wrote: Even if jQuery deprecates non-standard selectors, the current spec for queryScopedSelector*() doesn't support the jQuery implicitly scoped selector *. As I understand it, jquery selectors on elements are always scoped in the sense that they behave differently from the v1 Selectors API. In particular, if I understand correctly, the behavior of: element.querySelector(body div) in matching all divs that are descendants of |element| and also descendants of a body (which may be an _ancestor_ of |element|) is different from the selector behavior in jquery. Or did I understand incorrectly? All that said, I just read the draft at http://dev.w3.org/2006/webapi/selectors-api2/ and I can't make heads or tails of either what the new arguments to querySelector(All) are supposed to mean (are they just an enumaration of the things :scope is allowed to match during the selector evaluation?) or what queryScopedSelector(All) is supposed to do. Am I just missing something? Am I reading the wrong draft? (I'd link to the dated version of the draft, in case it changes, but that link is broken, sadly.) In the following forms :scope is misleading: element.queryScopedSelector(:scope + *) element.queryScopedSelector(:scope ~ *) and especially: element.querySelector(* :scope *, refNode) Can't exactly comment on this given the above -Boris
Re: Publishing Selectors API Level 2 as an FPWD?
On 11/01/10 4:19 PM, Boris Zbarsky wrote: On 1/10/10 11:58 PM, Sean Hogan wrote: Even if jQuery deprecates non-standard selectors, the current spec for queryScopedSelector*() doesn't support the jQuery implicitly scoped selector *. As I understand it, jquery selectors on elements are always scoped in the sense that they behave differently from the v1 Selectors API. In particular, if I understand correctly, the behavior of: element.querySelector(body div) in matching all divs that are descendants of |element| and also descendants of a body (which may be an _ancestor_ of |element|) is different from the selector behavior in jquery. Or did I understand incorrectly? That's correct. jQuery's $(element).find(div) is the equivalent of SelectorsAPI2's element.querySelectorAll(:scope div) or element.queryScopedSelectorAll(div). My point is that jQuery's $(element).find( div) isn't supported (without pre-processing by the JS lib) by element.queryScopedSelectorAll(). All that said, I just read the draft at http://dev.w3.org/2006/webapi/selectors-api2/ and I can't make heads or tails of either what the new arguments to querySelector(All) are supposed to mean (are they just an enumaration of the things :scope is allowed to match during the selector evaluation?) or what queryScopedSelector(All) is supposed to do. Am I just missing something? Am I reading the wrong draft? (I'd link to the dated version of the draft, in case it changes, but that link is broken, sadly.) You are correct about the new refNodes argument in querySelector*(). queryScopedSelector*() are more-or-less wrappers around querySelector*(). e.g. element.queryScopedSelectorAll(div) generally becomes element.parentNode.querySelectorAll(:scope div, element) which is the same as element.querySelectorAll(:scope div, element) or even element.querySelectorAll(:scope div) element.queryScopedSelectorAll(:scope div) generally becomes element.parentNode.querySelectorAll(:scope div, element) which is the same as element.querySelectorAll(:scope div, element) or even element.querySelectorAll(:scope div) element.queryScopedSelectorAll(:scope + div) generally becomes element.parentNode.querySelectorAll(:scope + div, element) element.queryScopedSelectorAll(div, div:scope) generally becomes element.parentNode.querySelectorAll(:scope div, div:scope, element)
Re: Publishing Selectors API Level 2 as an FPWD?
On 11/01/10 5:24 PM, Sean Hogan wrote: On 11/01/10 4:19 PM, Boris Zbarsky wrote: On 1/10/10 11:58 PM, Sean Hogan wrote: Even if jQuery deprecates non-standard selectors, the current spec for queryScopedSelector*() doesn't support the jQuery implicitly scoped selector *. As I understand it, jquery selectors on elements are always scoped in the sense that they behave differently from the v1 Selectors API. In particular, if I understand correctly, the behavior of: element.querySelector(body div) in matching all divs that are descendants of |element| and also descendants of a body (which may be an _ancestor_ of |element|) is different from the selector behavior in jquery. Or did I understand incorrectly? That's correct. jQuery's $(element).find(div) is the equivalent of SelectorsAPI2's element.querySelectorAll(:scope div) or element.queryScopedSelectorAll(div). Oops. Not a very insightful example. Perhaps the following would be better. Same for examples below. jQuery's $(element).find(div p) is the equivalent of SelectorsAPI2's element.querySelectorAll(:scope div p) or element.queryScopedSelectorAll(div p). My point is that jQuery's $(element).find( div) isn't supported (without pre-processing by the JS lib) by element.queryScopedSelectorAll(). All that said, I just read the draft at http://dev.w3.org/2006/webapi/selectors-api2/ and I can't make heads or tails of either what the new arguments to querySelector(All) are supposed to mean (are they just an enumaration of the things :scope is allowed to match during the selector evaluation?) or what queryScopedSelector(All) is supposed to do. Am I just missing something? Am I reading the wrong draft? (I'd link to the dated version of the draft, in case it changes, but that link is broken, sadly.) You are correct about the new refNodes argument in querySelector*(). queryScopedSelector*() are more-or-less wrappers around querySelector*(). e.g. element.queryScopedSelectorAll(div) generally becomes element.parentNode.querySelectorAll(:scope div, element) which is the same as element.querySelectorAll(:scope div, element) or even element.querySelectorAll(:scope div) element.queryScopedSelectorAll(:scope div) generally becomes element.parentNode.querySelectorAll(:scope div, element) which is the same as element.querySelectorAll(:scope div, element) or even element.querySelectorAll(:scope div) element.queryScopedSelectorAll(:scope + div) generally becomes element.parentNode.querySelectorAll(:scope + div, element) element.queryScopedSelectorAll(div, div:scope) generally becomes element.parentNode.querySelectorAll(:scope div, div:scope, element)
Re: Publishing Selectors API Level 2 as an FPWD?
On 1/11/10 1:24 AM, Sean Hogan wrote: That's correct. jQuery's $(element).find(div) is the equivalent of SelectorsAPI2's element.querySelectorAll(:scope div) or So in fact jquery can simply implement Element.find in terms of querySelectorAll by just prepending :scope to the selector string, right? Note that this happens to work even for the div case (by converting the selector to :scope div, which is what jquery means). So the div thing doesn't seem to require preparsing (modulo commas in the selector; was that the key point?). Of course the jquery selectors that aren't in CSS do (or possibly post-parsing depending on how it's implemented). My point is that jQuery's $(element).find( div) isn't supported (without pre-processing by the JS lib) by element.queryScopedSelectorAll(). ... element.queryScopedSelectorAll(:scope div) generally becomes element.parentNode.querySelectorAll(:scope div, element) which is the same as element.querySelectorAll(:scope div, element) or even element.querySelectorAll(:scope div) That's what I'm confused about. Does implementing element.find( div) as element.queryScopedSelectorAll(:scope div) not do what the current jquery code does? If not, how do they differ? I'm still confused about queryScopedSelectorAll, though. It sounds from your example like queryScopedSelectorAll just prepends :scope to the whole query string and then calls querySelectorAll on the parentNode of the scope node, with the scope node passed in as the optional argument. So: element.queryScopedSelectorAll(myStr) is the same as: element.parentNode.querySelectorAll(:scope + myStr, element); is that correct? -Boris
