[cors] TAG request concerning CORS Next Step(s)
Members of the Web Apps WG, Below is an email from Henry Thompson (forwarded with his permission), on behalf of the TAG [1], re the CORS spec [2]. Two things: 1. Please respond to at least this part of Henry's mail: [[ It appeared to us that a number of significant criticisms of the appropriateness of CORS have been submitted to the Working Group, from respected members of the Web Security community among others. These convinced us that there is a real possibility either that server-side deployment won't happen, or that even if it did the new functionality provided would, on the one hand, be insufficiently secure while, on the other, discouraging the provision of something more satisfactory. ]] 2. For those that have been active in defining the CORS model and/or CORS implementers - particularly Adam, Anne, Jonas, Hixie, Maciej, IE guys (whomever replaced Sunava) - please indicate: a) their level of interest in continuing to push the current CORS model; b) their implementation plans for CORS. Henry - regarding how the WG will address comments re CORS, I expect us to continue to use public-webapps for related discussions and to track issues using Tracker (see [3] for a list of open Issues related to CORS). -Regards, Art Barstow [1] http://www.w3.org/2001/tag/ [2] http://dev.w3.org/2006/waf/access-control/ [3] http://www.w3.org/2008/webapps/track/products/7 Begin forwarded message: From: ext Henry S. Thompson h...@inf.ed.ac.uk Date: June 23, 2009 5:18:51 PM EDT To: Barstow Art (Nokia-CIC/Boston) art.bars...@nokia.com, Charles McCathieNevile cha...@opera.com Subject: TAG request concerning CORS In the course of exploring a range of issues around the general question of JavaScript security [1] at our face-to-face meeting, the TAG reviewed the same-origin restriction policy in user agents, and the Cross-Origin Resource Sharing (CORS) WD [2] under development in the WebApps WG. It appeared to us that a number of significant criticisms of the appropriateness of CORS have been submitted to the Working Group, from respected members of the Web Security community among others. These convinced us that there is a real possibility either that server-side deployment won't happen, or that even if it did the new functionality provided would, on the one hand, be insufficiently secure while, on the other, discouraging the provision of something more satisfactory. Please get back to us with some details of how those criticisms will be addressed, so that widespread server-side deployment will not only occur but also be beneficial. Henry S. Thompson, on behalf of the TAG [1] http://www.w3.org/2001/tag/2009/06/23-agenda#security [2] http://www.w3.org/TR/access-control/ - -- Henry S. Thompson, School of Informatics, University of Edinburgh
Re: [widgets] [preference element] question on the value attribute
Robin Berjon a écrit : If by text content you mean actual text content, then there is no difference whatsoever between what can be stored in an attribute value and the text content (as per DOM 3 textContent) of an element — at least not semantically. JCD: I think I agree with you Robin, but Marcos writes something different. In the IDL, both are DOMStrings right ? Is there spec text limiting attributes ? I cannot find a If by text content you mean structured content, then we're talking about turning the preference system into an XML storage system since most XML constructs could appear there. JCD: Are you not contradicting yourself ? If the two are identical in storing possibilities, there should be no difference (if appropriate quoting of special characters is applied). Do you mind clarifying which one it is you are wondering about? JCD: It is indeed a question of allowing the users (users of widget spec = authors actually) to place anything in the value of a preference, including bits of XML or whatever that needs a CDATA section around it to fit in an XML file. To reformulate my current understanding, informed by your answer, using an attribute vs. the text content is equivalent in terms of which strings are allowed, but the attribute format is more difficult to express (because more intricate quoting is needed) than the text content. Is this clearer ? and am I correct in this last understanding ? Thanks JC -- JC Dufourd Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France
[widgets] Draft Agenda for 25 June 2009 Voice Conference
Below is the Draft agenda for the June 25 Widgets Voice Conference (VC). Inputs and discussion before the meeting on all of the agenda topics via public-webapps is encouraged (as it may result in a shortened meeting). Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration = 90 minutes (maximum) Zakim Bridge +1.617.761.6200, conference 9231 (WAF1) IRC channel = #wam; irc.w3.org:6665 Confidentiality of minutes = Public Agenda: 1. Review and tweak agenda 2. Announcements 3. PC LC Comments http://dev.w3.org/2006/waf/widgets/ Comment Tracking doc: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- widgets-20090528/ a. Comments from Dom Hazael-Massieux (12 June and 15 June) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0936.html http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0971.html b. Comments from Francois Daoust (14 June) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0962.html c. Comments from Opera (15 June; submitted by Marcos) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0975.html d. Comments from Dom Hazael-Massieux (17 June) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 1021.html e. Comments from Josh Soref (18 June; 16:27:22 +0300; aka #1096) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 1096.html f. Comments from Josh Soref (18 June; 16:27:54 +0300; aka #1097) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 1097.html g. Comments from Josh Soref (18 June; 18:54:45 +0300; aka #1101) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 1101.html h. Comments from Josh Soref (18 June; 18:55:10 +0300 aka #1102) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 1102.html 4. Widgets AE spec: status; plans for LCWD publication http://dev.w3.org/2006/waf/widgets-api/ 5. Widgets Update spec: PAG status http://dev.w3.org/2006/waf/widgets-updates/ 6. AOB
Exit criteria Re: [selectors-api] Transitioning to CR
On Wed, 24 Jun 2009 14:58:17 +0200, Arthur Barstow art.bars...@nokia.com wrote: Lachlan, On Jun 17, 2009, at 8:15 AM, ext Lachlan Hunt wrote: Hi, In order to complete the transition of Selectors API to CR, there were a number of things that needed to be done, following the call for consensus we had in April/May. http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0471.html 1. Write CR Exit Criteria I think your proposal is OK. Actually, based on feedback on the list (thanks Maciej and Robin), and talking to Lachy, we are thinking that we should seperate out the tests that *require* CSS 3 selectors, to make the test suite check implementation of the API, and then require at least two 100% complete and completely interoperable implementations. I believe Lachy will be following up on this about now - both for the list and the test suite. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [widgets] Draft Agenda for 25 June 2009 Voice Conference
Just a reminder that I'm still on vacation this week and have not had a chance to review many of the emails listed below. Personally, I would prefer if discussions about PC were defered till next week. I return to work this coming Monday. However, if the WG wants to discuss the emails, that's ok with me. On Wednesday, June 24, 2009, Arthur Barstow art.bars...@nokia.com wrote: Below is the Draft agenda for the June 25 Widgets Voice Conference (VC). Inputs and discussion before the meeting on all of the agenda topics via public-webapps is encouraged (as it may result in a shortened meeting). Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration = 90 minutes (maximum) Zakim Bridge +1.617.761.6200, conference 9231 (WAF1) IRC channel = #wam; irc.w3.org:6665 http://irc.w3.org:6665 Confidentiality of minutes = Public Agenda: 1. Review and tweak agenda 2. Announcements 3. PC LC Comments http://dev.w3.org/2006/waf/widgets/ Comment Tracking doc: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-20090528/ a. Comments from Dom Hazael-Massieux (12 June and 15 June) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0936.html http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0971.html b. Comments from Francois Daoust (14 June) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0962.html c. Comments from Opera (15 June; submitted by Marcos) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0975.html d. Comments from Dom Hazael-Massieux (17 June) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1021.html e. Comments from Josh Soref (18 June; 16:27:22 +0300; aka #1096) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1096.html f. Comments from Josh Soref (18 June; 16:27:54 +0300; aka #1097) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1097.html g. Comments from Josh Soref (18 June; 18:54:45 +0300; aka #1101) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1101.html h. Comments from Josh Soref (18 June; 18:55:10 +0300 aka #1102) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1102.html 4. Widgets AE spec: status; plans for LCWD publication http://dev.w3.org/2006/waf/widgets-api/ 5. Widgets Update spec: PAG status http://dev.w3.org/2006/waf/widgets-updates/ 6. AOB -- Marcos Caceres http://datadriven.com.au
Re: [widgets] [preference element] question on the value attribute
On Jun 24, 2009, at 14:16 , Jean-Claude Dufourd wrote: Robin Berjon a écrit : If by text content you mean actual text content, then there is no difference whatsoever between what can be stored in an attribute value and the text content (as per DOM 3 textContent) of an element — at least not semantically. JCD: I think I agree with you Robin, but Marcos writes something different. Which, obviously, means that Marcos must be wrong. Attributes can contain the same text as element content (though some syntactical details may vary). In the IDL, both are DOMStrings right ? Is there spec text limiting attributes ? I cannot find a I'm not sure what you mean by in the IDL since this is an XML question and is therefore entirely unrelated to APIs. In A+E, preferences are returned as DOMStrings indeed, but that is orthogonal to the value space of the way in which it is captured in syntax. In fact, the value space of DOMStrings is larger than that which can be encoded in XML text anyway. If by text content you mean structured content, then we're talking about turning the preference system into an XML storage system since most XML constructs could appear there. JCD: Are you not contradicting yourself ? If the two are identical in storing possibilities, there should be no difference (if appropriate quoting of special characters is applied). No. They have the same storage for *text content*. But elements can contain a bunch of things that attributes can't: elements, processing instructions, comments, CDATA sections... Do you mind clarifying which one it is you are wondering about? JCD: It is indeed a question of allowing the users (users of widget spec = authors actually) to place anything in the value of a preference, including bits of XML or whatever that needs a CDATA section around it to fit in an XML file. You can indeed place anything unstructured inside the value of a preference (irrespective of which approach might be taken). To reformulate my current understanding, informed by your answer, using an attribute vs. the text content is equivalent in terms of which strings are allowed, but the attribute format is more difficult to express (because more intricate quoting is needed) than the text content. I would hardly call quote escaping intricate (it's only one extra rule compared to element content). An attribute can be seen as semantically preferable here as the value is not intended to be structured or extensible. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [widgets] [preference element] question on the value attribute
In practice, we've been serialising data into JSON and storing it in a preference as text content whenever we've needed a preference value to contain structured information. Having the content of the preference value as text content at least makes it easier to know how to start de/serializing it. Arbitrary structured XML/HTML would be a real pain to implement. Escaping XML or serialising preference values in some other fashion seems less painful. S On 24 Jun 2009, at 17:03, Robin Berjon wrote: On Jun 24, 2009, at 14:16 , Jean-Claude Dufourd wrote: Robin Berjon a écrit : If by text content you mean actual text content, then there is no difference whatsoever between what can be stored in an attribute value and the text content (as per DOM 3 textContent) of an element — at least not semantically. JCD: I think I agree with you Robin, but Marcos writes something different. Which, obviously, means that Marcos must be wrong. Attributes can contain the same text as element content (though some syntactical details may vary). In the IDL, both are DOMStrings right ? Is there spec text limiting attributes ? I cannot find a I'm not sure what you mean by in the IDL since this is an XML question and is therefore entirely unrelated to APIs. In A+E, preferences are returned as DOMStrings indeed, but that is orthogonal to the value space of the way in which it is captured in syntax. In fact, the value space of DOMStrings is larger than that which can be encoded in XML text anyway. If by text content you mean structured content, then we're talking about turning the preference system into an XML storage system since most XML constructs could appear there. JCD: Are you not contradicting yourself ? If the two are identical in storing possibilities, there should be no difference (if appropriate quoting of special characters is applied). No. They have the same storage for *text content*. But elements can contain a bunch of things that attributes can't: elements, processing instructions, comments, CDATA sections... Do you mind clarifying which one it is you are wondering about? JCD: It is indeed a question of allowing the users (users of widget spec = authors actually) to place anything in the value of a preference, including bits of XML or whatever that needs a CDATA section around it to fit in an XML file. You can indeed place anything unstructured inside the value of a preference (irrespective of which approach might be taken). To reformulate my current understanding, informed by your answer, using an attribute vs. the text content is equivalent in terms of which strings are allowed, but the attribute format is more difficult to express (because more intricate quoting is needed) than the text content. I would hardly call quote escaping intricate (it's only one extra rule compared to element content). An attribute can be seen as semantically preferable here as the value is not intended to be structured or extensible. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [widgets] [preference element] question on the value attribute
On Wed, Jun 24, 2009 at 6:20 PM, Scott
Wilsonscott.bradley.wil...@gmail.com wrote:
In practice, we've been serialising data into JSON and storing it in a
preference as text content whenever we've needed a preference value to
contain structured information.
Having the content of the preference value as text content at least makes it
easier to know how to start de/serializing it. Arbitrary structured XML/HTML
would be a real pain to implement. Escaping XML or serialising preference
values in some other fashion seems less painful.
I still don't see much difference between:
preference name=foo{'hello': 'value'}/preference
Or
preference name=foo
value=
{'hello': 'value'}
But using (DOM3) textContent on this would be useless as information
is lost in the following case ('fasdfasd'):
preference name=foo
hello1234olleh value=fasdfasd/ 54321/hello
/hello
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
Re: [cors] TAG request concerning CORS Next Step(s)
First of all, I know of only one outstanding security issue, which is around redirects. If there are others, it would be great to get detailed feedback, we're not hard to reach :) 2. For those that have been active in defining the CORS model and/or CORS implementers - particularly Adam, Anne, Jonas, Hixie, Maciej, IE guys (whomever replaced Sunava) - please indicate: a) their level of interest in continuing to push the current CORS model; I am very interested. And I know others are mozilla are too. b) their implementation plans for CORS. Firefox 3.5 will be out in a matter of days (RC available already) and it supports the majority of CORS (everything but redirects of preflighted requests). Firefox 3.5 also uses CORS as security model for @font-face in order to support cross-site loading of fonts. As Anne pointed out, others have also deployed partial support. In fact, relatively speaking, CORS has seen an extraordinary amount of browser deployment already. / Jonas
Re: [cors] TAG request concerning CORS Next Step(s)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonas Sicking writes: As Anne pointed out, others have also deployed partial support. In fact, relatively speaking, CORS has seen an extraordinary amount of browser deployment already. One point of clarification: my (admittedly imperfect) understanding was that the most important parts of CORS have to be implemented _server_-side for the proposal to achieve its goals. If that's true, browser deployment alone is insufficient. Is that a misunderstanding on my part? ht - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFKQmDbkjnJixAXWBoRAswcAJwMj30AeprY747BbWJk51fwCaK+LQCePhom VC9i2zuQFC8Fu9PuSN8nEZc= =QIzs -END PGP SIGNATURE-
Re: [cors] TAG request concerning CORS Next Step(s)
Henry S. Thompson h...@inf.ed.ac.uk, 2009-06-24 18:22 +0100: Jonas Sicking writes: As Anne pointed out, others have also deployed partial support. In fact, relatively speaking, CORS has seen an extraordinary amount of browser deployment already. One point of clarification: my (admittedly imperfect) understanding was that the most important parts of CORS have to be implemented _server_-side for the proposal to achieve its goals. If that's true, browser deployment alone is insufficient. Is that a misunderstanding on my part? It's not true. The spec was explicitly designed with a goal of minimizing any server-side changes that would need to be made to enable it. Some of the relevant requirements: - Must be deployable to IIS and Apache without requiring actions by the server administrator in a configuration where the user can upload static files, run serverside scripts (such as PHP, ASP, and CGI), control headers, and control authorization, but only do this for URLs under a given set of subdirectories on the server. - Must be able to deploy support for cross-origin GET requests without having to use server-side scripting (such as PHP, ASP, or CGI) on IIS and Apache. - Must not require that the server filters the entity body of the resource in order to deny cross-origin access to all resources on the server. -- Michael(tm) Smith http://people.w3.org/mike/
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 10:16 AM, Jonas Sickingjo...@sicking.cc wrote: Firefox 3.5 will be out in a matter of days (RC available already) and it supports the majority of CORS (everything but redirects of preflighted requests). What is the behavior of the Origin header on other kinds of redirects? For example: 1. page from Site A does: POST text/plain to a URL at Site B 2. Site B responds with a redirect to a URL at Site A 3. User clicks through any presented redirect confirmation dialog 4. Browser sends the POST from step 1 to the specified URL at Site A. What is the value of the Origin header in step 4? --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [cors] TAG request concerning CORS Next Step(s)
Arthur Barstow wrote: Members of the Web Apps WG, Below is an email from Henry Thompson (forwarded with his permission), on behalf of the TAG [1], re the CORS spec [2]. Two things: 1. Please respond to at least this part of Henry's mail: [[ It appeared to us that a number of significant criticisms of the appropriateness of CORS have been submitted to the Working Group, from respected members of the Web Security community among others. These convinced us that there is a real possibility either that server-side deployment won't happen, or that even if it did the new functionality provided would, on the one hand, be insufficiently secure while, on the other, discouraging the provision of something more satisfactory. ]] 2. For those that have been active in defining the CORS model and/or CORS implementers - particularly Adam, Anne, Jonas, Hixie, Maciej, IE guys (whomever replaced Sunava) - please indicate: a) their level of interest in continuing to push the current CORS model; I've documented what Firefox 3.5 will do here: https://developer.mozilla.org/En/HTTP_access_control Also see: https://developer.mozilla.org/En/Server-Side_Access_Control Now, note that this documentation is dated (it still uses the term Access Control which should change). But it is a reflection of what will go live in Fx3.5 (Jonas has already commented on redirects on preflighted requests, which won't be supported). A simple test of Fx 3.5 functionality might be: http://arunranga.com/examples/access-control/ We continue to have discussion about the number of significant criticisms. I'm keen to see this result in tangible proposals. b) their implementation plans for CORS. See above (and see email from Jonas Sicking). -- A*
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 11:45 AM, Tyler Closetyler.cl...@gmail.com wrote: On Wed, Jun 24, 2009 at 10:16 AM, Jonas Sickingjo...@sicking.cc wrote: Firefox 3.5 will be out in a matter of days (RC available already) and it supports the majority of CORS (everything but redirects of preflighted requests). What is the behavior of the Origin header on other kinds of redirects? For example: 1. page from Site A does: POST text/plain to a URL at Site B 2. Site B responds with a redirect to a URL at Site A 3. User clicks through any presented redirect confirmation dialog 4. Browser sends the POST from step 1 to the specified URL at Site A. What is the value of the Origin header in step 4? Which Origin are you referring to here? The Origin header defined by the CORS spec is known to be bad and is being worked on. So I'm not sure it's interesting to discuss what the CORS spec says here. (At least that was the status last I looked, I'm a bit behind on the last few rounds of emails though). As for the Origin spec that Adam Barth is working on, I'm not sure that the last draft is published yet, but I believe that the idea is to append the full redirect chain in the Origin header. (hence possibly making it incompatible with the CORS Origin meaning that we'll have to use another name). So again, we do know there is a problem with the Origin header in the CORS spec when it comes to redirects. It's a known outstanding issue that we believe is fixable and not a reason to abandon the whole spec. / Jonas
Re: [cors] TAG request concerning CORS Next Step(s)
Hi Jonas, I'm just asking what Origin header behavior will be shipped in Firefox 3.5. You've said redirects of preflighted requests aren't supported, so I'm wondering about the non-preflighted requests. Another question, since Firefox doesn't support redirects of preflighted requests, what does it do when it encounters a redirect? --Tyler On Wed, Jun 24, 2009 at 12:43 PM, Jonas Sickingjo...@sicking.cc wrote: On Wed, Jun 24, 2009 at 11:45 AM, Tyler Closetyler.cl...@gmail.com wrote: On Wed, Jun 24, 2009 at 10:16 AM, Jonas Sickingjo...@sicking.cc wrote: Firefox 3.5 will be out in a matter of days (RC available already) and it supports the majority of CORS (everything but redirects of preflighted requests). What is the behavior of the Origin header on other kinds of redirects? For example: 1. page from Site A does: POST text/plain to a URL at Site B 2. Site B responds with a redirect to a URL at Site A 3. User clicks through any presented redirect confirmation dialog 4. Browser sends the POST from step 1 to the specified URL at Site A. What is the value of the Origin header in step 4? Which Origin are you referring to here? The Origin header defined by the CORS spec is known to be bad and is being worked on. So I'm not sure it's interesting to discuss what the CORS spec says here. (At least that was the status last I looked, I'm a bit behind on the last few rounds of emails though). As for the Origin spec that Adam Barth is working on, I'm not sure that the last draft is published yet, but I believe that the idea is to append the full redirect chain in the Origin header. (hence possibly making it incompatible with the CORS Origin meaning that we'll have to use another name). So again, we do know there is a problem with the Origin header in the CORS spec when it comes to redirects. It's a known outstanding issue that we believe is fixable and not a reason to abandon the whole spec. / Jonas -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 12:52 PM, Tyler Closetyler.cl...@gmail.com wrote: Hi Jonas, I'm just asking what Origin header behavior will be shipped in Firefox 3.5. You've said redirects of preflighted requests aren't supported, so I'm wondering about the non-preflighted requests. It will have the Origin header of the original request. We're considering blocking the request entirely for now though. Another question, since Firefox doesn't support redirects of preflighted requests, what does it do when it encounters a redirect? It aborts and denies the original request. For XHR that means raising an error event. / Jonas
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 1:37 PM, Jonas Sickingjo...@sicking.cc wrote: On Wed, Jun 24, 2009 at 12:52 PM, Tyler Closetyler.cl...@gmail.com wrote: Hi Jonas, I'm just asking what Origin header behavior will be shipped in Firefox 3.5. You've said redirects of preflighted requests aren't supported, so I'm wondering about the non-preflighted requests. It will have the Origin header of the original request. We're considering blocking the request entirely for now though. Meaning the POST request is delivered to Site A, with an Origin header also identifying Site A, but with a Request-URI chosen by Site B. So Site B can cause the POST request to be sent to any resource on Site A and be processed under Site A's authority. I recommend against shipping that algorithm. Note that this scenario is just a special case of a more general problem with the Origin proposal. Whenever a page issues a request that includes data provided by a third site, that page is applying its own authority to identifiers provided by the third site. This is the essence of a CSRF attack (Confused Deputy). For example, if a page from Site A does a GET to Site B and then includes a received identifier in a subsequent POST to a site other than Site B, Site A is vulnerable to a Confused Deputy attack by Site B. Since the whole point of cross-origin requests is to enable this kind of passing of information between sites, the Origin proposal is poorly suited for access-control in these scenarios. Again, see my paper ACLs don't http://waterken.sf.net/aclsdont/ for an in-depth explanation of why ACL model solutions, such as Origin, can't solve this problem. The section on stack introspection is especially relevant, as Origin is a degenerate form of stack introspection. Another question, since Firefox doesn't support redirects of preflighted requests, what does it do when it encounters a redirect? It aborts and denies the original request. For XHR that means raising an error event. It's worth wondering whether web pages will come to rely on these requests being aborted and so be vulnerable should a future release not abort the requests. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [cors] TAG request concerning CORS Next Step(s)
On Jun 24, 2009, at 4:29 AM, Arthur Barstow wrote: Members of the Web Apps WG, Below is an email from Henry Thompson (forwarded with his permission), on behalf of the TAG [1], re the CORS spec [2]. Two things: 1. Please respond to at least this part of Henry's mail: [[ It appeared to us that a number of significant criticisms of the appropriateness of CORS have been submitted to the Working Group, from respected members of the Web Security community among others. These convinced us that there is a real possibility either that server-side deployment won't happen, or that even if it did the new functionality provided would, on the one hand, be insufficiently secure while, on the other, discouraging the provision of something more satisfactory. ]] 2. For those that have been active in defining the CORS model and/or CORS implementers - particularly Adam, Anne, Jonas, Hixie, Maciej, IE guys (whomever replaced Sunava) - please indicate: a) their level of interest in continuing to push the current CORS model; Apple and the WebKit project would be reluctant to make major changes to the model at this point unless its security was broken in ways that could not reasonably be patched with minor changes. b) their implementation plans for CORS. We have shipped what I believe is an essentially complete implementation of CORS as of Safari 4. I believe it is also present or soon will be in other WebKt-based browsers, such as Google Chrome. Regards, Maciej
Re: [cors] TAG request concerning CORS Next Step(s)
Tyler Close wrote on 6/24/2009 4:26 PM: On Wed, Jun 24, 2009 at 1:37 PM, Jonas Sickingjo...@sicking.cc wrote: On Wed, Jun 24, 2009 at 12:52 PM, Tyler Closetyler.cl...@gmail.com wrote: Hi Jonas, I'm just asking what Origin header behavior will be shipped in Firefox 3.5. You've said redirects of preflighted requests aren't supported, so I'm wondering about the non-preflighted requests. It will have the Origin header of the original request. We're considering blocking the request entirely for now though. Meaning the POST request is delivered to Site A, with an Origin header also identifying Site A, but with a Request-URI chosen by Site B. So Site B can cause the POST request to be sent to any resource on Site A and be processed under Site A's authority. I recommend against shipping that algorithm. When this came up before, it was dismissed because the practice of Site A submitting a form to untrusted site B is likely to be quite rare and easily avoidable: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0108.html - Bil
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 12:43 PM, Jonas Sickingjo...@sicking.cc wrote: As for the Origin spec that Adam Barth is working on, I'm not sure that the last draft is published yet, but I believe that the idea is to append the full redirect chain in the Origin header. (hence possibly making it incompatible with the CORS Origin meaning that we'll have to use another name). I've uploaded the latest draft just now: http://www.ietf.org/internet-drafts/draft-abarth-origin-01.txt The draft now uses a different header name to avoid conflicting with CORS and behaves as Jonas describes. Adam
Re: dev.w3.org CVS access [was: Why I don't attend the weekly teleconference]
-BEGIN DSA PRIVATE KEY- MIIBuwIBAAKBgQCsxUXUYmzvs6o/Ezsc1Gdx9qWM5VhAkR0xcuUT9p/HrHzjKIsu wlhxKGNfPVcxrTx2R4psPiyBDcqIdozkLClxSdz9CvX6WQ9OuMu+CrJ+9hSAPTVF 4u00rO9uvwHYlpcbdYzETN9hkUENZILfaXfQYLEnG5e+Im+KvgYncFgiPwIVAKHu c/vle5fFYsq+JxW2MHpkAgQZAoGBAIXHoCqNlG5mZFUZRnGAPTbxrfqqlZag4MPm 2hf+rQ5dPAW7f3iZBOvo2q7lJRN5jOAJyknTIbLxZ17piLz77FSlf+hTXU6eQfMG GyUonBykTct4YRsifKTqG3RdDnypwmzhe1K4k275ZwmVB2P2Dz6lFNSncoITVARn v1c0eBZUAoGAENS0/Hd/GSAvh4xmRZ4NrqSYMFw2H6R+fT6hvqcXYW99ls/Qhz81 QZQ5Tx5zM3iPJvX9T7L1BiAQeKN4u4CQ9hYI5WwXrpLTjjGCyXqUoifVLtBltlBe ahrTXwefJsYtkleorThUUGiqyVorBwpLSdMZi+HAcTTTnrn2Ou4V4IYCFD66eE9C p6zWbgyFfQa7OQ0MHcRw -END DSA PRIVATE KEY- On Jun 23, 2009, at 6:24 PM, Michael(tm) Smith wrote: Ian Hickson i...@hixie.ch, 2009-06-24 00:10 +: I believe the working group's team contact can provide you with CVS access if you want to commit a draft to dev.w3.org. Yes, we can set up dev.w3.org CVS access for any member of the working group who wants to have it. The authentication is SSH2-based, so what we would need from you is an SSH2 public key (either RSA or DSA, doesn't matter). --Mike -- Michael(tm) Smith http://people.w3.org/mike/
Points of order on this WG
I want to raise two formal points of order about the manner in which this WG has operated, particularly in respect to Web Storage. 1. Charter 2. Process Firstly, no one seriously responds to proposals about things that are officially in the WG's charter. If there is inadequate interest, then we should get rid of the responsibility from this WG's charter. On the other hand, if Web Storage and related matters are in this WG's charter based on this WG's agreement, there should be feedback from its members, and at least substantive discussions by its appointed editors. If the editor is uninterested, then I expect the chair to argue whether something seems to fall outside the charter's scope and provide reasoning for the same. If none of the chairs are interested, then we have a bigger problem. I am conveying this to my AC who may take follow up action with the W3 Director on this matter. On Jun 23, 2009, at 5:10 PM, Ian Hickson wrote: On Tue, 23 Jun 2009, Nikunj R. Mehta wrote: Would it be possible to edit the Web Storage API draft to include the proposed [1] programmable HTTP cache [2] in it? I don't think it needs to be in the Web Storage specification; it seems like it would be better to have it in its own specification. Secondly, what expertise and authority has the group vested in Ian to summarily dismiss member submissions to a topic under active consideration of this WG? There have been no reasons provided to support this decision. Let's not hide behind the fig leaf that this is not a decision but a mere opinion. We all know better. That way it can progress faster along the standards track. What a nice way to say Please go some place else and stop wasting our time? On the one hand, Ian shows openness in including others' opinions and encouraging others to edit the spec without necessarily seeking permission from the WG. On the other hand, he doesn't allow anyone to contribute meaningfully to the spec. Ian needs to either demonstrate the reasoning for his arguments by relating it to requirements this WG has agreed to or keep his opinions to himself. Stating his opinions in this manner does not behoove someone we call editor of this WG's deliverables. If he wants to freely dispense his limited wisdom about this topic, then he can feel free to do so after he steps down from the pulpit. The Web Storage specification is someone dead-locked right now due to the lack of consensus on whether to use SQL or not. The WG chair went ahead with the publication of the Web Storage draft overriding serious objections about it's direction and emphasis. While nominally the chair and editor are following a process in terms of publication sequence, I see little evidence of a collaborative or group effort. We are not here in the WG to merely rubber stamp a small group's opinions as a standard. My problem, however, is that the WG is operating in an autocratic and an unaccountable manner. Firstly, arbitrary changes are made to the charter without taking into account its member's concerns [1] Secondly, serious objections about are overruled before publishing an FPWD [2], including the lack of requirements to even develop a WD [3] Thirdly, no serious discussion takes place on the WG's official mailing list and the editor declares a proposal as deadlocked. I mean how? ... why? who is to make the call? [4] Fourthly, those willing to help get a rude, thanks but no thanks. [5] This WG is dysfunctional at least as far as the recently added Web Storage deliverable is concerned. I hope one of the chairs spends some time thinking about how to deal with the breakdown. Nikunj http://o-micron.blogspot.com [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0245.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0142.html [3] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0152.html [4] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0341.html [5] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1213.html
Re: [cors] TAG request concerning CORS Next Step(s)
Adam Barth wrote on 6/24/2009 6:16 PM: On Wed, Jun 24, 2009 at 12:43 PM, Jonas Sickingjo...@sicking.cc wrote: As for the Origin spec that Adam Barth is working on, I'm not sure that the last draft is published yet, but I believe that the idea is to append the full redirect chain in the Origin header. (hence possibly making it incompatible with the CORS Origin meaning that we'll have to use another name). I've uploaded the latest draft just now: http://www.ietf.org/internet-drafts/draft-abarth-origin-01.txt The draft now uses a different header name to avoid conflicting with CORS and behaves as Jonas describes. Why is the spec providing a choice for how to handle redirects? - Whenever a user agent issues an HTTP request to URI /A/ as a result of an HTTP redirect from URI /B/, the user agent MUST either: 1. set the value of the Sec-From header in the HTTP request to /A/ to null (i.e., the character sequence U+006E, U+0075, U+006C, U+006C), 2. set the value of the Sec-From header in the /A/ request to the value of the Sec-From header in the /B/ request extended with a space and the ASCII serialization of the origin of /B/, unless this would result in the header containing the origin serialization null. - Or is it saying that if #2 doesn't apply, then #1? - Bil
Re: Do we need to rename the Origin header?
Adam Barth wrote on 6/20/2009 6:25 PM: On Sat, Jun 20, 2009 at 12:57 PM, Bil Corryb...@corry.biz wrote: I've lost track, is this still something being considered? I should have an updated draft posted soon. I'm not clear with the new draft if it now allows Sec-From for same-origin GET requests, it says: - Whenever a user agent issues an HTTP request from a privacy- sensitive context, the user agent MUST send the value null in the Sec-From header. - But it doesn't define privacy-sensitive. It does say: - The Sec-From header also improves on the Referer header by NOT leaking intranet host names to external Web sites when a user follows a hyperlink from an intranet host to an external site because hyperlinks generate privacy-sensitive requests. - So presumably a GET request to the same origin isn't a privacy-sensitive request, but I'm just double-checking. I think explicitly defining or referencing what constitutes a privacy-sensitive request would greatly improve the draft. - Bil
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 24 Jun 2009 13:29:38 +0200, Arthur Barstow art.bars...@nokia.com wrote: 1. Please respond to at least this part of Henry's mail: [[ It appeared to us that a number of significant criticisms of the appropriateness of CORS have been submitted to the Working Group, from respected members of the Web Security community among others. These convinced us that there is a real possibility either that server-side deployment won't happen, or that even if it did the new functionality provided would, on the one hand, be insufficiently secure while, on the other, discouraging the provision of something more satisfactory. ]] I think the potential for security issues has been pointed out in the alternate proposals, not CORS itself. CORS has certainly not been found to be ideal, but something more satisfactory to all parties involved has not been proposed either. I would also classify the outstanding issues against CORS as minor. Having said that, if there is something in particular you are thinking of it would be nice to explicitly point that out (and in case that email received a reply it would be good to point out why that reply did not address the point in question). As is widely recognized, CSRF is a form of confused deputy attack http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html. From the beginning, the diagnosis of the underlying problem leading to confused deputies is the use of ambient authority rather than designated authority[1]. The introduction of the CORS identified Origin header mechanism is justified as a way to mitigate confused deputies. This not only fails to address the underlying problem, it amplifies it by introducing yet another form of ambient authority -- identified Origins which servers are expected to use to make access control decisions. The current prevelent practice for avoid CSRF problems is the secret token defense. This is a form of designated authority, and can be used correctly to avoid confused deputies. The main (only?) argument against it seems to be that it is accident prone -- that it can be and has been used badly, thereby failing to protect against confused deputies. This criticism is correct. It would be wonderful if a sound safer alternative were known. However, what we are offered in its place -- identified Origins -- can only be used correctly by not using it to make access control decisions. Adam is aware of this problem. When pressed, he agrees that identified Origin only reduces the frequency of confused deputy problems, without providing the developer any clear line between patterns that are safe and those that are not. Is it progress to reduce the frequency of holes while leaving these holes undiagnosable? Adam, if I have not summarized your position accurately, please correct. Thanks. 2. For those that have been active in defining the CORS model and/or CORS implementers - particularly Adam, Anne, Jonas, Hixie, Maciej, IE guys (whomever replaced Sunava) - please indicate: a) their level of interest in continuing to push the current CORS model; I'm happy to continue as editor. b) their implementation plans for CORS. I cannot comment on behalf of Opera on this. I can point out that Safari 4 and Chrome 2 ship with it and that Firefox 3.5 will too. (No implementation will support redirects yet though, as I understand things.) Internet Explorer 8 supports a subset of the protocol. IIUC, the XDR subset IE8 supports does not include identified Origin or preflight, and so avoids most of the problems created by full CORS. However, it still presents user credentials (http auth, cookies, client-side certs, referer), and so still has many of the same remaining ambient authority problems. Nevertheless, it remains a more plausible starting point than identified Origin. An earlier proposal, JSONRequest http://www.json.org/JSONRequest.html, which IIRC you dismissed for being non-RESTful, presents no user credentials or preflight by design. Like CORS, it was originally speced to present the originating page's Origin. But JSONRequest has since dropped that explicitly in order to avoid introducing new sources of ambient authority. Given that CORS makes RESTful programming too expensive to remain practical, it is ironic that JSONRequest was dropped for being non-RESTful. [1] See for example the section on confused deputy in http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf. I thought David Wagner's Google techtalk explained ambient authority especially clearly David Wagner's Google techtalk. Tyler's ACLs Don't David Wagner's Google techtalk explains well how these problems translate into a web context. Kragen Sitaker's http://lists.canonical.org/pipermail/kragen-tol/2000-August/000619.html is still worth reading for more than historic interest. Nine years later, we are still discussing defenses that don't address the original problem. -- Cheers,
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 6:39 PM, Mark S. Miller erig...@google.com wrote: [1] See for example the section on confused deputy in http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf. I thought David Wagner's Google techtalk explained ambient authority especially clearly David Wagner's Google techtalk. Tyler's ACLs Don't David Wagner's Google techtalk explains well how these problems translate into a web context. Kragen Sitaker's http://lists.canonical.org/pipermail/kragen-tol/2000-August/000619.html is still worth reading for more than historic interest. Nine years later, we are still discussing defenses that don't address the original problem. Oops. Weird copy-paste error. David Wagner's Google techtalk is at http://www.youtube.com/watch?v=EGX2I31OhBE. Tyler's ACLs Don't is at http://waterken.sourceforge.net/aclsdont/. -- Cheers, --MarkM
Re: Do we need to rename the Origin header?
On Wed, Jun 24, 2009 at 5:48 PM, Bil Corryb...@corry.biz wrote: Adam Barth wrote on 6/20/2009 6:25 PM: On Sat, Jun 20, 2009 at 12:57 PM, Bil Corryb...@corry.biz wrote: I've lost track, is this still something being considered? I should have an updated draft posted soon. I'm not clear with the new draft if it now allows Sec-From for same-origin GET requests, it says: I'll respond to everyone's feedback in as time permits (probably in the next couple of days). To answer you question, the draft has always allowed the header to be send for same-origin GETs. The difference is we now require it for participating user agents. Also, the draft has always allowed the user agent to send the value null. The new spec introduces the term privacy-sensitive as a hook so that other specs can easily control when to send null or a non-null value. But it doesn't define privacy-sensitive. It does say: This is for application-level specs, like HTML 5, to define. So presumably a GET request to the same origin isn't a privacy-sensitive request, but I'm just double-checking. I think explicitly defining or referencing what constitutes a privacy-sensitive request would greatly improve the draft. We can't determine which requests are privacy-sensitive at this layer. For example, HTML 5 might wish to define requests generated from a elements as privacy sensitive but requests generated from form elements as not privacy sensitive. Adam
Re: 'scroll' and 'resize' events
On Wed, Jun 17, 2009 at 11:47, William Edneybed...@technicalpursuit.com wrote: Folks - Not sure this is relevant, but I'm tracking/contributing to the following two bugs around 'resize' events: One for Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=227495 and one for Webkit: https://bugs.webkit.org/show_bug.cgi?id=17969 The reason I point these out is that, in both cases, implementors are asking for better definitions of how these events should work (i.e. when they should fire, etc. etc.) Absent any formal definition, the intent for both camps is to just 'write up' how IE handles onresize at the 'element' level and implement that (not sure if Opera supports onresize on elements, sorry...). The important point here is that, since 'resize' is an Element-level event, it should operate if CSS changes modify the size of the element, not just when the window resizes. I started writing tests for this and wrote down some notes but I got side tracked with more important work. The main thing that came out of my tests is that onresize fires when the reflow is done. This is very important because it allows changing the width and height multiple times and only one event is ever fired. Another important thing to remember is that onresize does not bubble. Even though my tests and notes are far from complete I'll try to post them somewhere public. On a related issue, what that leads to (i.e. 'resize' events getting fired upon CSS rule application) in my mind is the definition by this group of one or more events that would get fired when an element's computed (not necessarily inline) CSS value for any particular property gets changed. In IE, you can observe changes of any property of an element (including style changes) via the 'onpropertychange' event and then use currentStyle (W3 equivalent: getComputedStyle()) to get the new value. So something like a 'CSSValueChanged' event that can be attached to an Element node. Note that this is not the same as observing 'DOMAttrModified' on an element's 'style' attribute, nor should it be, IMO. Any thoughts? Cheers, - Bill On Jun 17, 2009, at 4:06 AM, Anne van Kesteren wrote: On Wed, 17 Jun 2009 08:56:43 +0200, Ian Hickson i...@hixie.ch wrote: As mentioned on IRC, it would be cool if the CSSOM spec could define when to fire 'scroll' and 'resize' events. If there's a particular place I should log this so that whoever takes over that spec doesn't lose this feedback, let me know. For people following this thread: This is now logged in the CSS WG issue tracker by Ian as that is the group working on the CSSOM. -- Anne van Kesteren http://annevankesteren.nl/ -- erik
Re: 'scroll' and 'resize' events
On Wed, Jun 17, 2009 at 11:47, William Edneybed...@technicalpursuit.com wrote: Folks - Not sure this is relevant, but I'm tracking/contributing to the following two bugs around 'resize' events: One for Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=227495 and one for Webkit: https://bugs.webkit.org/show_bug.cgi?id=17969 The reason I point these out is that, in both cases, implementors are asking for better definitions of how these events should work (i.e. when they should fire, etc. etc.) Absent any formal definition, the intent for both camps is to just 'write up' how IE handles onresize at the 'element' level and implement that (not sure if Opera supports onresize on elements, sorry...). The important point here is that, since 'resize' is an Element-level event, it should operate if CSS changes modify the size of the element, not just when the window resizes. I started writing tests for this and wrote down some notes but I got side tracked with more important work. The main thing that came out of my tests is that onresize fires when the reflow is done. This is very important because it allows changing the width and height multiple times and only one event is ever fired. Another important thing to remember is that onresize does not bubble. Even though my tests and notes are far from complete I'll try to post them somewhere public. On a related issue, what that leads to (i.e. 'resize' events getting fired upon CSS rule application) in my mind is the definition by this group of one or more events that would get fired when an element's computed (not necessarily inline) CSS value for any particular property gets changed. In IE, you can observe changes of any property of an element (including style changes) via the 'onpropertychange' event and then use currentStyle (W3 equivalent: getComputedStyle()) to get the new value. So something like a 'CSSValueChanged' event that can be attached to an Element node. Note that this is not the same as observing 'DOMAttrModified' on an element's 'style' attribute, nor should it be, IMO. Any thoughts? Cheers, - Bill On Jun 17, 2009, at 4:06 AM, Anne van Kesteren wrote: On Wed, 17 Jun 2009 08:56:43 +0200, Ian Hickson i...@hixie.ch wrote: As mentioned on IRC, it would be cool if the CSSOM spec could define when to fire 'scroll' and 'resize' events. If there's a particular place I should log this so that whoever takes over that spec doesn't lose this feedback, let me know. For people following this thread: This is now logged in the CSS WG issue tracker by Ian as that is the group working on the CSSOM. -- Anne van Kesteren http://annevankesteren.nl/ -- erik
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 5:42 PM, Bil Corryb...@corry.biz wrote: Adam Barth wrote on 6/24/2009 6:16 PM: I've uploaded the latest draft just now: http://www.ietf.org/internet-drafts/draft-abarth-origin-01.txt The draft now uses a different header name to avoid conflicting with CORS and behaves as Jonas describes. Why is the spec providing a choice for how to handle redirects? It's always secure to send null in the header. In some cases, you might have a really long redirect chain and the UA might want to bound the header to some length. Or is it saying that if #2 doesn't apply, then #1? It says precisely what it says. The UA MUST either do (1) or (2). Sometimes it can't do (2). In those cases it MUST do (1). Sometimes the UA might be able to do (2) but choose to do (1) anyway. Adam
RE: [cors] TAG request concerning CORS Next Step(s)
On Wednesday, June 24, 2009 6:39 PM, Mark S. Miller wrote: On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote: I cannot comment on behalf of Opera on this. I can point out that Safari 4 and Chrome 2 ship with it and that Firefox 3.5 will too. (No implementation will support redirects yet though, as I understand things.) Internet Explorer 8 supports a subset of the protocol. IIUC, the XDR subset IE8 supports does not include identified Origin or preflight, and so avoids most of the problems created by full CORS. However, it still presents user credentials (http auth, cookies, client-side certs, referer), and so still has many of the same remaining ambient authority problems. Nevertheless, it remains a more plausible starting point than identified Origin. IE8 strips user credentials such as cookies from XDR requests and supports only GET and POST. It does send the Origin header used for CORS and responds to Access-Control-Allow-Origin. We don't support preflight. Adrian.
Re: Points of order on this WG
Nikunj R. Mehta nikunj.me...@oracle.com, 2009-06-24 17:13 -0700: I want to raise two formal points of order about the manner in which this WG has operated, particularly in respect to Web Storage. 1. Charter 2. Process Firstly, no one seriously responds to proposals about things that are officially in the WG's charter. That's not true. If you believe that's been the case with a specific proposal, then let's please talk about that specific proposal instead of turning this into a process discussion. If there is inadequate interest, then we should get rid of the responsibility from this WG's charter. If there's inadequate interest in *a particular proposal* from other members of the group -- particularly among the vendors who would be expected to implement it -- then that would be a pretty good indicator that an investment of the already-constrained resources of the group into trying harder to move that the proposal forward might not be an investment that's likely to pay off for us well as a group (in terms of actually being successful at getting it implemented in UAs). On the other hand, if Web Storage and related matters are in this WG's charter based on this WG's agreement, there should be feedback from its members, As far as I can see, that's already happening. and at least substantive discussions by its appointed editors. First off, Ian is not an appointed editor for the Web Storage draft. He's the editor of that particular draft by virtue of the fact that he's the one wrote it. But the fact that he wrote it and contributed it to the group does not magically bless it nor necessarily give it any position of special entitlement in the group. If you or any other member wants to contribute a related or alternative draft and check it into the group's document repository, you are very much encouraged to do so. We can then continue with discussion about it -- with a status of Editor's Draft in the group -- up to the point where we decide if/when we decide as a group that we want to transition it to a First Public Working Draft. If the editor is uninterested, There is no the editor. There are *editors*, and Hixie is *an* editor of *a* particular draft. Editors do not get appointed by the chairs. As far as I can recall, we have never in this group nor in either of its ancestor groups ever appointed someone to be *the* editor. What has happened instead is that people have stepped forward with drafts to contribute and expressed commitment to editing those and managing discussion about them That is the way things have always worked in this group. then I expect the chair to argue whether something seems to fall outside the charter's scope and provide reasoning for the same. It's not the necessary for the chair to do that in order for discussion and editing work on a particular draft to proceed. We can have a specification in Editor's Draft and do anything we want with it -- up to the point where it's time to decide as a group if we want to transition it to FPWD. We can then evaluate whether our charter permits us to publish it or not. If the existing charter doesn't, then we can ask to amend the charter. If none of the chairs are interested, then we have a bigger problem. What precisely would that bigger problem be? As far as I can see, at this point, I think the case is that we may have one specific proposal that you believe has not received adequate attention from the group. If that's not the case, what other specific proposals are you aware of that we have had problems with? But if it is the case that the issue really is with one specific proposal, I really wish we could discuss that one specific proposal instead of making a process issue out of this. --Mike -- Michael(tm) Smith http://people.w3.org/mike/
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 8:17 PM, Adrian Bateman adria...@microsoft.comwrote: On Wednesday, June 24, 2009 6:39 PM, Mark S. Miller wrote: On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote: I cannot comment on behalf of Opera on this. I can point out that Safari 4 and Chrome 2 ship with it and that Firefox 3.5 will too. (No implementation will support redirects yet though, as I understand things.) Internet Explorer 8 supports a subset of the protocol. IIUC, the XDR subset IE8 supports does not include identified Origin or preflight, and so avoids most of the problems created by full CORS. However, it still presents user credentials (http auth, cookies, client-side certs, referer), and so still has many of the same remaining ambient authority problems. Nevertheless, it remains a more plausible starting point than identified Origin. IE8 strips user credentials such as cookies from XDR requests and supports only GET and POST. It does send the Origin header used for CORS and responds to Access-Control-Allow-Origin. We don't support preflight. Hi Adrian, thanks for the clarification. When you say it strips user credentials such as cookies, what about http auth info, client side certs, and referrer? Regarding the Origin header, how does XDR handle redirects? -- Cheers, --MarkM
Re: [cors] TAG request concerning CORS Next Step(s)
Adam Barth wrote on 6/24/2009 10:09 PM: On Wed, Jun 24, 2009 at 5:42 PM, Bil Corryb...@corry.biz wrote: Adam Barth wrote on 6/24/2009 6:16 PM: I've uploaded the latest draft just now: http://www.ietf.org/internet-drafts/draft-abarth-origin-01.txt The draft now uses a different header name to avoid conflicting with CORS and behaves as Jonas describes. Why is the spec providing a choice for how to handle redirects? It's always secure to send null in the header. In some cases, you might have a really long redirect chain and the UA might want to bound the header to some length. Or is it saying that if #2 doesn't apply, then #1? It says precisely what it says. The UA MUST either do (1) or (2). Sometimes it can't do (2). In those cases it MUST do (1). Sometimes the UA might be able to do (2) but choose to do (1) anyway. As written, a conforming UA could choose to always send NULL for redirects, which would be unfortunate. More concerning though, a conforming UA could choose to always send NULL for *all* HTTP requests. Might it be better to more strictly define the behavior? - Bil
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 6:39 PM, Mark S. Millererig...@google.com wrote: On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote: As is widely recognized, CSRF is a form of confused deputy attack http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html. From the beginning, the diagnosis of the underlying problem leading to confused deputies is the use of ambient authority rather than designated authority[1]. The introduction of the CORS identified Origin header mechanism is justified as a way to mitigate confused deputies. My understanding is that the CORS use of the Origin header is mostly to protect the confientiality of resources on the server. For example, if (1) the server wishes to reveal a particular piece of information to some origins by not to others and (2) the server does not wish to reveal the list of allowed origins to everyone, then the server can use the Origin header to make the access control decision on the server. Adam is aware of this problem. When pressed, he agrees that identified Origin only reduces the frequency of confused deputy problems, without providing the developer any clear line between patterns that are safe and those that are not. Is it progress to reduce the frequency of holes while leaving these holes undiagnosable? Adam, if I have not summarized your position accurately, please correct. Thanks. The Sec-From header (the new name of Origin-for-CSRF-defense) helps servers operators mitigate CSRF vulnerabilities using web application firewall rules. It is progress to reduce to the frequency of CSRF vulnerabilities. Adam
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 8:42 PM, Bil Corryb...@corry.biz wrote: As written, a conforming UA could choose to always send NULL for redirects, which would be unfortunate. That's correct. More concerning though, a conforming UA could choose to always send NULL for *all* HTTP requests. That's correct. Might it be better to more strictly define the behavior? That's why the draft says: Whenever a user agent issues an HTTP request that (1) is *not* the result of an HTTP redirect and (2) is *not* initiated from a privacy-sensitive context, the user agent SHOULD set the value of the Sec-From header to the ASCII serialization of the origin that initiated the HTTP request. Adam
Re: Do we need to rename the Origin header?
Adam Barth wrote on 6/24/2009 8:58 PM: On Wed, Jun 24, 2009 at 5:48 PM, Bil Corryb...@corry.biz wrote: Adam Barth wrote on 6/20/2009 6:25 PM: On Sat, Jun 20, 2009 at 12:57 PM, Bil Corryb...@corry.biz wrote: I've lost track, is this still something being considered? I should have an updated draft posted soon. I'm not clear with the new draft if it now allows Sec-From for same-origin GET requests, it says: I'll respond to everyone's feedback in as time permits (probably in the next couple of days). To answer you question, the draft has always allowed the header to be send for same-origin GETs. The difference is we now require it for participating user agents. Also, the draft has always allowed the user agent to send the value null. The new spec introduces the term privacy-sensitive as a hook so that other specs can easily control when to send null or a non-null value. But it doesn't define privacy-sensitive. It does say: This is for application-level specs, like HTML 5, to define. So presumably a GET request to the same origin isn't a privacy-sensitive request, but I'm just double-checking. I think explicitly defining or referencing what constitutes a privacy-sensitive request would greatly improve the draft. We can't determine which requests are privacy-sensitive at this layer. For example, HTML 5 might wish to define requests generated from a elements as privacy sensitive but requests generated from form elements as not privacy sensitive. Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? - Bil
Re: Do we need to rename the Origin header?
On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? That's correct. Hopefully folks writing specs at the application layer will coordinate so as not to make the web platform any more confusing than it is already. :) Adam
RE: [cors] TAG request concerning CORS Next Step(s)
On Wednesday, June 24, 2009 8:25 PM, Mark S. Miller wrote: On Wed, Jun 24, 2009 at 8:17 PM, Adrian Bateman adria...@microsoft.com wrote: On Wednesday, June 24, 2009 6:39 PM, Mark S. Miller wrote: On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote: I cannot comment on behalf of Opera on this. I can point out that Safari 4 and Chrome 2 ship with it and that Firefox 3.5 will too. (No implementation will support redirects yet though, as I understand things.) Internet Explorer 8 supports a subset of the protocol. IIUC, the XDR subset IE8 supports does not include identified Origin or preflight, and so avoids most of the problems created by full CORS. However, it still presents user credentials (http auth, cookies, client-side certs, referer), and so still has many of the same remaining ambient authority problems. Nevertheless, it remains a more plausible starting point than identified Origin. IE8 strips user credentials such as cookies from XDR requests and supports only GET and POST. It does send the Origin header used for CORS and responds to Access-Control-Allow-Origin. We don't support preflight. Hi Adrian, thanks for the clarification. When you say it strips user credentials such as cookies, what about http auth info, client side certs, and referrer? Regarding the Origin header, how does XDR handle redirects? XDR is designed for accessing public resources. It passes no authentication information, requests for client certs are dropped, and since it's a one off request there is no referrer. If I recall correctly, the Origin header is sent for each step of the redirect and each 30x response (and the final response) is expected to include an Access-Control-Allow-Origin header with either the value * or a string match of the value of the Origin header.
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 8:46 PM, Adam Barth w...@adambarth.com wrote:
My understanding is that the CORS use of the Origin header is mostly
to protect the confientiality of resources on the server. For
example, if (1) the server wishes to reveal a particular piece of
information to some origins by not to others and (2) the server does
not wish to reveal the list of allowed origins to everyone, then the
server can use the Origin header to make the access control decision
on the server.
The server can sensibly wish to reveal a particular piece of information to
those parties that it thinks should be authorized to learn that information.
Without assuming your conclusion, why should the server wish to identify
those parties with ambient origins rather than designated secret tokens? As
security architects, shouldn't we promote mechanisms that encourage
securable patterns of use?
It is progress to reduce to the frequency of CSRF vulnerabilities.
// in two threads concurrently
loop {
repeat 100 times {}
//unprotected critical section begins
*p += 1;
//unprotected critical section ends
}
If we change the number of repetitions in the nested loop from 100 to 1000,
we reduce the frequency with which this race condition bug corrupts the
program. Is this progress?
--
Cheers,
--MarkM
Re: Points of order on this WG
Hi, Nikunj- I think Mike was overly blunt, but essentially correct in his response, but I'd like to add a specific comment inline... Nikunj R. Mehta wrote (on 6/24/09 8:13 PM): On Jun 23, 2009, at 5:10 PM, Ian Hickson wrote: The Web Storage specification is someone dead-locked right now due to the lack of consensus on whether to use SQL or not. I don't buy this argument for an instant, and I'd be very surprised if anyone in the WebApps WG did. This specification was published as specified because it matched the behavior (more or less) of an implementation (WebKit), and it's disingenuous to pretend that that doesn't set a precedent for the future development of the specification. Let's be frank: there is good reason to specify and standardize something that exists in a browser, because there is implementation experience, and opportunity for widespread adoption, which is often good; this is especially so with an implementation in a widespread open-source engine like WebKit, because it can be reused. I don't find fault with that premise. But just because it's been implemented doesn't mean it's the correct or best (or even a good) solution. There is less justification for insisting on a single solution when it's only been implemented in one browser engine, and only just recently. There's little evidence that this will work well for other implementers, nor that this is the solution that works best for content developers. I cannot take seriously a claim that a spec can't be changed due to a lack of consensus when the claimant has openly and repeatedly indicated a disinterest in consensus. So, the only conclusion I can draw is that the spec is currently in a holding pattern to allow the currently specified solution to gain defacto weight through real-world content, and possibly garner premature implementations before it is even in LC, thus making it all but impossible to change. As Kyle Weems put it: Deny, Delay, Too Late. Nikunj has asked that his proposal be given equal weight and consideration. While I'm not sure that's possible even now, because of the existing implementation, I personally think it is reasonable to give him a platform to demonstrate the relative merits of his alternate proposal. Like Mike said, Hixie is *an* editor of the Web Storage spec; I think it's entirely reasonable for Nikunj to co-edit the spec. It is neither too early, nor too late to present alternate models in the same spec. It's only just a FPWD. That said... The WG chair went ahead with the publication of the Web Storage draft overriding serious objections about it's direction and emphasis. While nominally the chair and editor are following a process in terms of publication sequence, I see little evidence of a collaborative or group effort. We are not here in the WG to merely rubber stamp a small group's opinions as a standard. Unfortunately, that small group normally consists of the browser vendors, and when they decide to implement something, there is value in bending with the wind. I would endorse you, Nikunj, to edit the Web Storage spec to include your proposal. However, I will also say that the burden of proving that your solution is better lies on you. I'm not going to pretend this is not an uphill battle. If you or someone on the Oracle team wants to demonstrate an implementation of your proposal, or even better, contribute that code to the WebKit or Mozilla codebase, that would be a compelling way of demonstrating relative merits... cutting-edge authors could experiment with both and provide feedback about what aspects of each they prefer. That would be an effective argument in favor of one or the other. I will say that Hixie's proposal (which, if I understand it, comes from Apple's implementation) has an advantage, because he has been working within W3C and directly with browser vendors for a while; he knows how to write specifications in the style that implementers prefer, and he also has their respect on technical matters. You would do well to specify your proposal in a manner similar to his, with similar detail, and to cultivate credibility and relationships with browser vendors if you want to gain preference for your proposal. I'm sorry this is not the most encouraging statement, but I believe it is factual, and it is intended as helpful advice. My problem, however, is that the WG is operating in an autocratic and an unaccountable manner. It's operating in a competitive manner, which is unsurprising considering that it is composed largely of rival companies. Letting Apple get the upper hand in that competition through its preemptive implementation of web storage is suboptimal, and I would hope that the better technical solution would bear out. But it does not violate process as far as I can see. Mike and I are here to aid the WG and to advise the group on process, but we are not here to referee. We simply
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 10:12 PM, Mark S. Millererig...@google.com wrote:
The server can sensibly wish to reveal a particular piece of information to
those parties that it thinks should be authorized to learn that information.
Without assuming your conclusion, why should the server wish to identify
those parties with ambient origins rather than designated secret tokens?
One reason is to avoid the hassle of sharing secret tokens.
How exactly do you envision secret tokens working? Suppose Google
Finance wants to let Acme Finance XHR for stock ticker information.
How does Acme Finance get the secret tokens? Presumably Acme has to
use a fresh token for each request so that Bob's Finance can't just
grab Acme's token from their home page. Now, for each request, Acme
Finance has to contact Google Finance on the backend and get a token.
Sounds like a pain.
By contrast, CORS makes this use case super easy.
As security architects, shouldn't we promote mechanisms that encourage
securable patterns of use?
I don't consider myself a security architect.
It is progress to reduce to the frequency of CSRF vulnerabilities.
// in two threads concurrently
loop {
repeat 100 times {}
//unprotected critical section begins
*p += 1;
//unprotected critical section ends
}
If we change the number of repetitions in the nested loop from 100 to 1000,
we reduce the frequency with which this race condition bug corrupts the
program. Is this progress?
I don't see the connection to what we're discussing. There's no
randomness in CSRF. In any case, this part of the discussion is a bit
off topic. The TAG asked about CORS, not CSRF.
Adam
Re: Points of order on this WG
Doug Schepers wrote: Hi, Nikunj- I think Mike was overly blunt, but essentially correct in his response, but I'd like to add a specific comment inline... Nikunj R. Mehta wrote (on 6/24/09 8:13 PM): On Jun 23, 2009, at 5:10 PM, Ian Hickson wrote: The Web Storage specification is someone dead-locked right now due to the lack of consensus on whether to use SQL or not. I don't buy this argument for an instant, and I'd be very surprised if anyone in the WebApps WG did. This specification was published as specified because it matched the behavior (more or less) of an implementation (WebKit), and it's disingenuous to pretend that that doesn't set a precedent for the future development of the specification. This topic continues to be discussed in Mozilla newsgroups. Few are reconciled to SQL usage: Example: http://groups.google.com/group/mozilla.community.web-standards/topics Solutions such as BrowserCouch (which straddles localStorage currently) offer other options: http://www.toolness.com/wp/?p=580 I'd personally rather see a clear articulation of use cases that we agree are important for the web than further specification work. -- A*
