Re: [access-control] Rename spec?
Being external to it all, i.e. just reading the mailing-list with the spec-title mentioned just about everytime, it clearly seems like a good move to me: that specs starts to taste interesting whereas, before, it seemed to be unrelated to my tasks! ;-) paul Le 13-janv.-09 à 17:50, Anne van Kesteren a écrit : I know some people (e.g. Ian) don't like the idea, but it seems the name Access Control for Cross-Site Requests confuses people, especially the Access Control part: http://www.w3.org/2001/tag/2008/12/10-minutes#item03 'TBL: Calling it Access Control is misleading. It's about privacy.' Henri Sivonen suggested Cross-Origin Data Sharing on IRC the other day: http://krijnhoetmer.nl/irc-logs/whatwg/20090112#l-139 Since it can be about more than just data, e.g. images, Cross- Origin Resource Sharing might be more appropriate. Keeping the header names the same seems fine, they're just opague strings, but at least making it more clear what the specification is about might help people. smime.p7s Description: S/MIME cryptographic signature
Re: [access-control] Header definitions
On Mon, 20 Oct 2008 17:32:03 +0200, Nikunj Mehta nikunj.me...@oracle.com wrote: The headers defined in this specification must be registered with IANA. See permanent [1] managed by IETF under RFC 3864 [2]. Ideally, this specification would have gone to IETF, but it looks like this WG has defined that there is no problem in going ahead with the work in W3C. The headers are provisionally registered. They will be in the permanent registry when the specification reaches a more stable state. Could you elaborate on why you think this specification should be done by the IETF? The reason for doing this work at the W3C is that it has close ties with other specifications developed here and the specifications it is intended for, e.g. XMLHttpRequest, CSS, and HTML5, are all also at the W3C. [1] http://www.iana.org/assignments/message-headers/perm-headers.html [2] http://www.rfc-editor.org/rfc/rfc3864.txt -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Rename spec?
Hi, On Jan 13, 2009, at 11:50 AM, ext Anne van Kesteren wrote: I know some people (e.g. Ian) don't like the idea, but it seems the name Access Control for Cross-Site Requests confuses people, especially the Access Control part: http://www.w3.org/2001/tag/2008/12/10-minutes#item03 'TBL: Calling it Access Control is misleading. It's about privacy.' Henri Sivonen suggested Cross-Origin Data Sharing on IRC the other day: http://krijnhoetmer.nl/irc-logs/whatwg/20090112#l-139 Since it can be about more than just data, e.g. images, Cross- Origin Resource Sharing might be more appropriate. Keeping the header names the same seems fine, they're just opague strings, but at least making it more clear what the specification is about might help people. It's been over a year since we last changed the name of this spec so I guess it's about time we renamed it again :-): [[ Authorizing Read Access to XML Content Using the ?access-control? Processing Instruction 1.0 Enabling Read Access for Web Resources Access Control for Cross-site Requests ]] I do agree the title is important and support either of the proposed new titles (preference goes with Resource). One question I have here is whether Domain would be more accurate than Origin. The only concern I have is whether a name change would be problematic to anyone that may have implemented the latest Draft. OTOH, a WD is always at risk of being substantially changed. -Regards, Art Barstow
Re: [access-control] Rename spec?
On Wed, 14 Jan 2009 14:28:49 +0100, Arthur Barstow art.bars...@nokia.com wrote: It's been over a year since we last changed the name of this spec so I guess it's about time we renamed it again :-): [[ Authorizing Read Access to XML Content Using the ?access-control? Processing Instruction 1.0 Enabling Read Access for Web Resources Access Control for Cross-site Requests ]] Yeah... :-) I do agree the title is important and support either of the proposed new titles (preference goes with Resource). One question I have here is whether Domain would be more accurate than Origin. Domain does not capture significance of the scheme and port, while Origin does. I'm updating the draft to use terminology a bit more consistent now so it should become less confusing. (E.g. I'm removing cross-site in favor of cross-origin as the latter has a clearly defined meaning and the former is just used on blogs.) The only concern I have is whether a name change would be problematic to anyone that may have implemented the latest Draft. OTOH, a WD is always at risk of being substantially changed. The change will only affect the name of the specification. Header names will most definitely not change and I wasn't planning on changing the names of definitions either, to be honest. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[widgets] Agenda for 15 January 2009 Voice Conference
Below is the draft agenda for the January 15 Widgets Voice Conference (VC). Inputs and discussion on the agenda topics before the meeting is encouraged. Logistics: Time: 24:00 Tokyo; 17:00 Helsinki; 16:00 Paris; 15:00 London; 10:00 Boston; 07:00 Seattle Duration = 60 minutes 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 Last Call WD (published 22 Dec 2008): a. Discuss any new contentious comments (if any): http://www.w3.org/TR/2008/WD-widgets-20081222/ b. Comments from Boris: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 0046.html 4. Widget Testing: update/status on Widget testing assuming Kai, Dom or someone from MWTS WG can join: http://dev.w3.org/cvsweb/2006/waf/widgets/tests/ 5. API and Events spec: agetting to FPWD: http://dev.w3.org/2006/waf/widgets-api/ 6. AOB
[widgets] PC 1.0 Last Call WD: localization comments
Hi Marcos, I have (still) a couple of concerns about the localization section of Widgets Packaging Configuration Last Call WD of 20081222. /1/ Is the following statement in [1] as it should be? Author requirements: Localized folders must be at the root of the widget (a localized folder not at the root of the widget will be treated as an arbitrary folder). I think it should now read: Localized folders must be placed inside the container for localized content (...). /2/ I was looking at the localized widget example in the same section (it's non-normative, but important nonetheless), and it seems that the left and right sides of the example don't agree. The paths on the right are absolute from the root, not the container. The right side shows en-au, but that is not found on the left side. The first bullet of the example mentions Korean, but that does not seem to be present. Should it be Spanish instead? Finally, it's not obvious which of the files shown (if any) is the start file, because the content of config.xml is not shown. /3/ This is a potentially confusing statement: At runtime, the widget user agent will set the (HTML or XML) base of the start file to the localized folder (even if the start file does not reside inside the localized folder). I assume in this case the localized folder means the one determined in Step 6, right? This might not be obvious from the context, it requires a trip to the text of Step 6. /4/ Since BCP47 tags are case-insensitive, it might be good to normalise all their occurrences to lowercase, to avoid any confusion. /5/ Is there value in being able to have multiple config.xml documents, instead of just one, and tagging the relevant elements with a BCP47 tag? The example mentions different author and license, which could be expressed in one file. If you have a pointer to some earlier discussion that resolves this, it's fine. Or do you think it would make the config.xml document too bulky? --Jere [1] http://www.w3.org/TR/2008/WD-widgets-20081222/#content-localization
http://dev.w3.org/2006/waf/widgets/#the-widget-element height and width default values
Suggestion for http://dev.w3.org/2006/waf/widgets/#the-widget-element When the value is missing or invalid, the widget user agent will assume the value 300. And perhaps reference http://dev.w3.org/2006/waf/widgets/#step-3-set-the-configuration-defaults Was wondering how you came up with 150x300 as the default size for a widget. How does that work for scalability and what not? Perhaps pixel definitions are scalable in reality nowadays by UAs and that's just an indicator of dimensions, 1:2? This might be addressed in R16 http://www.w3.org/TR/widgets-reqs/#visual but I don't quite understand it. Is there an example? Thanks guys,
[access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
I wanted to let the WG members know that we have completed our support for Access-Control in IE8 for the Simple Cross-Site Access Request. We support the Access-Control-Allow-Origin: * wildcard as we did in Beta 2 but in the next public release of IE8, our Release Candidate, we have also added support for the string comparison to the ascii-origin. I want to thank the members of this group who gave us feedback about making this change. Making changes to our implementation now will be costly and I'd prefer if this part of the draft didn't have to change significantly. On the subject of renaming the Origin header, we'd prefer the option to keep it as is and have the name for CSRF changed in HTML 5 as Ian raised [1] if possible. Cheers, Adrian. [1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0060.html -- Adrian Bateman Program Manager - Internet Explorer - Microsoft Corporation Phone: +1 (425) 538 5111 E-mail: mailto:adria...@microsoft.com
Re: [access-control] Rename spec?
I do agree the title is important and support either of the proposed new titles (preference goes with Resource). One question I have here is whether Domain would be more accurate than Origin. Domain does not capture significance of the scheme and port, while Origin does. I'm updating the draft to use terminology a bit more consistent now so it should become less confusing. (E.g. I'm removing cross-site in favor of cross-origin as the latter has a clearly defined meaning and the former is just used on blogs.) This seems both condescending and useless. Nearly everyone knows what cross domain and same domain policy mean, whereas cross origin is just what language lawyers say to make regular web developers feel bad (AFICT). Please end the madness. Regards
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
On Wed, 14 Jan 2009 19:53:42 +0100, Jonas Sicking jo...@sicking.cc wrote: What do other people think? If we really think they should be different (and at least Adam Barth suggests that might not be needed) I would really like to rename this header to make it consistent with the rest of the API. (Of course, the semantics would be identical to what they are now.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Rename spec?
On Wed, 14 Jan 2009 17:52:50 +0100, Alex Russell a...@dojotoolkit.org wrote: I do agree the title is important and support either of the proposed new titles (preference goes with Resource). One question I have here is whether Domain would be more accurate than Origin. Domain does not capture significance of the scheme and port, while Origin does. I'm updating the draft to use terminology a bit more consistent now so it should become less confusing. (E.g. I'm removing cross-site in favor of cross-origin as the latter has a clearly defined meaning and the former is just used on blogs.) This seems both condescending and useless. Nearly everyone knows what cross domain and same domain policy mean, whereas cross origin is just what language lawyers say to make regular web developers feel bad (AFICT). Please end the madness. Well, both are important (and different, origin is a superset), no? E.g. document.domain clearly represents a domain, where as the MessageEvent interface has an origin attribute that gives back an origin. This very draft defines two headers with the name origin in them. It seems to me that developers will quickly pick up the difference. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Do we need to rename the Origin header?
Thomas Roessler wrote on 1/12/2009 8:02 PM: Having the CSRF-Origin defined in an RFC or another separate spec is a good idea independently of whether or not it ends up being the same header that's used for cross-site XHR. If someone wants to form an Origin BOF at the next IETF meeting in March (with the idea of creating a RFC), I'll attend. I'm already planning to be there for the Cookie BOF. - Bil
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
On Wed, 14 Jan 2009 20:36:12 +0100, Bil Corry b...@corry.biz wrote: Jonas Sicking wrote on 1/14/2009 12:53 PM: The problem I think is that the current name, 'Origin', is extremely generic and so it's likely to cause confusion once we get other headers containing origins. That said, I do understand that this is a very late change for you guys. Developers will code to what works, so as long as things work the same across browsers, with regards to this and the CSRF protection header, things should be mostly ok. What do other people think? I liked your suggestion that would marry the two: Jonas Sicking wrote on 1/12/2009 7:22 PM: That said, here is a solution that might work for both Access-Control and CSRF protection: Site A makes a request to site B, the UA adds the header Origin: A Site B redirects the request to site C, the UA adds the header Origin: A, B This would mean significant changes to the draft which would not work well for Microsoft. Renaming I would like to consider, changing the semantics drastically seems out of order at this point. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
On Wed, Jan 14, 2009 at 11:45 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 14 Jan 2009 20:36:12 +0100, Bil Corry b...@corry.biz wrote: Jonas Sicking wrote on 1/14/2009 12:53 PM: The problem I think is that the current name, 'Origin', is extremely generic and so it's likely to cause confusion once we get other headers containing origins. That said, I do understand that this is a very late change for you guys. Developers will code to what works, so as long as things work the same across browsers, with regards to this and the CSRF protection header, things should be mostly ok. What do other people think? I liked your suggestion that would marry the two: Jonas Sicking wrote on 1/12/2009 7:22 PM: That said, here is a solution that might work for both Access-Control and CSRF protection: Site A makes a request to site B, the UA adds the header Origin: A Site B redirects the request to site C, the UA adds the header Origin: A, B This would mean significant changes to the draft which would not work well for Microsoft. Renaming I would like to consider, changing the semantics drastically seems out of order at this point. Yup, I agree. / Jonas
RE: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
On January 14, 2009 11:45 AM, Anne van Kesteren [mailto:ann...@opera.com] wrote: On Wed, 14 Jan 2009 20:36:12 +0100, Bil Corry b...@corry.biz wrote: Jonas Sicking wrote on 1/14/2009 12:53 PM: The problem I think is that the current name, 'Origin', is extremely generic and so it's likely to cause confusion once we get other headers containing origins. What do other people think? I liked your suggestion that would marry the two: Jonas Sicking wrote on 1/12/2009 7:22 PM: That said, here is a solution that might work for both Access- Control and CSRF protection: Site A makes a request to site B, the UA adds the header Origin: A Site B redirects the request to site C, the UA adds the header Origin: A, B This would mean significant changes to the draft which would not work well for Microsoft. Renaming I would like to consider, changing the semantics drastically seems out of order at this point. Changing the semantics would unfortunately likely mean that IE8 would ship with behaviour that would be different to the spec. We probably won't be able to make that kind of change. I actually don't think that the generic name is a problem as long as the CSRF solution uses a different name for a different meaning. The value really is an Origin and could potentially be used for more than just participation in the Access Control negotiation. It could still be meaningful in other scenarios in future which would otherwise now have to define a new header with the same meaning. If the header name does change then we will cost out the work to make this change to see if we can do it. Clearly changing the strings used in the browser is a relatively constrained change but I'm concerned about the amount of churn in our test automation infrastructure that would be required and the risks involved. Cheers, Adrian.
Re: Do we need to rename the Origin header?
On Tue, 13 Jan 2009, Jonas Sicking wrote: On Tue, Jan 13, 2009 at 5:09 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 13 Jan 2009, Jonas Sicking wrote: It's not just POST that we need to worry about, ideally we should cover the GET case as well. Or at least it's quite likely that we will want to. My understanding was that we didn't want to include Origin in GET requests. In fact HTML5 right now goes out of its way to avoid including it in GET requests. We've been debating this both ways at mozilla, no decision has been made yet regarding what we'll recommend. I've renamed it to XXX-Origin in HTML5. I haven't changed its behavior (it is still only sent for non-GET). I'm trying to bring HTML5 to last call by October. Who owns this issue? Do we have an ETA on resolving it? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [access-control] Rename spec?
Feels like URL vs. URI to me, which for the 80% case is simply bike- shedding. I appreciate that there is a question of specificity and that your clarification is more correct...but is that a good enough reason to do it? Regards On Jan 14, 2009, at 11:14 AM, Anne van Kesteren wrote: On Wed, 14 Jan 2009 17:52:50 +0100, Alex Russell a...@dojotoolkit.org wrote: I do agree the title is important and support either of the proposed new titles (preference goes with Resource). One question I have here is whether Domain would be more accurate than Origin. Domain does not capture significance of the scheme and port, while Origin does. I'm updating the draft to use terminology a bit more consistent now so it should become less confusing. (E.g. I'm removing cross-site in favor of cross-origin as the latter has a clearly defined meaning and the former is just used on blogs.) This seems both condescending and useless. Nearly everyone knows what cross domain and same domain policy mean, whereas cross origin is just what language lawyers say to make regular web developers feel bad (AFICT). Please end the madness. Well, both are important (and different, origin is a superset), no? E.g. document.domain clearly represents a domain, where as the MessageEvent interface has an origin attribute that gives back an origin. This very draft defines two headers with the name origin in them. It seems to me that developers will quickly pick up the difference.
Re: [access-control] Rename spec?
On Wed, 14 Jan 2009 23:25:43 +0100, Alex Russell a...@dojotoolkit.org wrote: Feels like URL vs. URI to me, which for the 80% case is simply bike- shedding. To be honest, I never quite understood the difference between those two. The difference between a domain and an origin however, is very clear: domain dojotoolkit.org origin https://dojotoolkit.org:9000 I appreciate that there is a question of specificity and that your clarification is more correct...but is that a good enough reason to do it? I would say yes, especially given that since it is a superset, things like https://google.com and http://google.com are same domain, but definitely not same origin. The distinction is pretty important. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
On Jan 14, 2009, at 3:45 PM, Bil Corry wrote: Adrian Bateman wrote on 1/14/2009 3:18 PM: I actually don't think that the generic name is a problem as long as the CSRF solution uses a different name for a different meaning. The value really is an Origin and could potentially be used for more than just participation in the Access Control negotiation. It could still be meaningful in other scenarios in future which would otherwise now have to define a new header with the same meaning. I'm thinking out loud here, making sure I have the distinction between the two correct: With Access Control, Origin represents the initial request, which survives through a redirect. So as Adrian points out, it really is an Origin. With CSRF mitigation, Origin represents the immediately-preceding request, which for obvious reasons does not survive through a redirect. That's why I liked the idea of just including the chain of requests within Origin, you can then easily find the one you want. But since that isn't on the table, I'm attracted to renaming the CSRF Origin to something like Request-Origin. Whatever name is chosen, it then has to be added to the XHR spec as a header that can not modified/created via XHR. Given this behavior, it sounds to me like the Access Control related header is more deserving of the term Origin, since it represents the true origin of the request. I am not sure what the other header could be called to make the difference clear. Perhaps Redirect-Origin? Why does the CSRF defense header need to change on redirect? Regards, Maciej
Re: Copyright license for ElementTraversal Java interface
Cameron McCormack: The question then is whether we want to include it. I don’t see how it would be beneficial for anyone to redistribute one of the interface files if it has been changed incompatibly, so I guess I don’t see the need for it. Some further off-list discussion regarding general policy for this issue: http://lists.w3.org/Archives/Public/www-archive/2009Jan/0003.html -- Cameron McCormack ≝ http://mcc.id.au/
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
On Jan 14, 2009, at 5:32 PM, Bil Corry wrote: Maciej Stachowiak wrote on 1/14/2009 6:14 PM: Why does the CSRF defense header need to change on redirect? Because to the site on the far end, it would appear the request came from somewhere it didn't, effectively hiding the real source of the request. This probably explains it better: - When an honest site initiates a request to a dishonest site (for example because the user followed a hyperlink), the dishonest site can redirect the request back to the honest site. If the redirected request carries the same Origin header as the original request, the request will implicate the honest site as generating the request. To protect the honest site, the user agent replaces the Origin header with null, so a conforming server will not modify state in response to a redirect. http://crypto.stanford.edu/websec/specs/origin-header/ - So one thing to keep in mind is that any POST-based form would not be vulnerable to this kind of attack unless the victim site actually submits a form to an untrusted site. There is no way for a GET request to be redirected to a POST, and it seems to me the practice of Site A submitting a form to untrusted site B is likely to be quite rare and easily avoidable. Furthermore, HTML5 specifies that the XXX-Origin (or whatever it might get renamed to) header should not be sent for GET requests, the only kind of request where it would plausibly help anything. Thus, the difference in behavior of the CSRF-prevention Origin does not do any good, and so we may as well use just one Origin header. Regards, Maciej
