Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
On Mon, Dec 14, 2009 at 6:14 PM, Jonas Sicking wrote: > For what it's worth, I'm not sure that "eliminating" is correct here. > With UM, I can certainly see people doing things like using a wrapping > library for all UM requests (very commonly done with XHR today), and > then letting that library add the security token to the request. There are real examples of this exact vulnerably occurring in CSRF defenses based on secret tokens. There's no silver bullet for security. Adam
Re: [widgets] test suite, the width/height attribute
Hi Marcos, Le 14/12/2009 16:49, Marcos Caceres a écrit : On Fri, Dec 4, 2009 at 5:04 PM, Cyril Concolato wrote: Dear Widgets-experts, While checking some of the tests, I found some unclear processing with regards to the width and height attribute of widget element. The spec says: "If the width attribute is used, then let normalized width be the result of applying the rule for parsing a non-negative integer to the value of the attribute. If the normalized width is not in error and greater than 0, then let widget width be the value of normalized width. If the width attribute is in error, then the user agent must ignore the attribute." It explicitely says "greater than 0" which means that 0 should not be allowed, but the test suite says for c9.wgt that the result should be 0. Argh. Right. This seems inconsistent. On top of that, the spec seems to make the distinction between 'null' (when in error) and '0' (not specified). From an implementation point of view, I would prefer two cases: - specified, not in error, greater than 0, width = the specified value - in error or not specified, width = null, empty or 0. Actually, I would prefer 0 since then the attribute can be implemented as an integer not as a string. What do you think ? Given that a number of UAs have implemented support for getting back the value "0", I think we should just say "greater than or equal to 0". So: = Error. value remains null. = Error, value remains null. returns 0, value is 0. returns 100, value is 100. returns 100, value is 100. However, I'm open to just saying return 0 upon error. That's what I would prefer. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
[XHR] Small text correction.
The third sentence in section 4.1 reads: When the XMLHttpRequest object used in other contexts their values will have to be defined as appropriate for that context. I think the word "is", is missing in the first part of it: When the XMLHttpRequest object is used in other contexts their values will have to be defined as appropriate for that context. Regards, Huub
Re: [AC/CORS] Proper behavior for user agents who return 'null' Access-Control-Allow-Origin
On Mon, 14 Dec 2009 11:03:27 +0100, Jonas Sicking wrote: My recollection from the meeting in seattle was that we did not want to allow this. In any case, it does seem like a very strange feature to me. Sending Access-Control-Allow-Origin: null would then mean essentially, "allow access to everyone who I don't know who it is". I can't think of a situation where this makes sense. The use case we discussed was allowing e.g. personalized search results even from things that do not have an origin. (You cannot do that with * because we explicit disallowed credentials there.) -- Anne van Kesteren http://annevankesteren.nl/
Re: CfC: to publish LCWD of: Server-Events, Web {SQL Database, Sockets, Storage, Worker}; deadline 15 December
On Dec 7, 2009, at 7:46 PM, Barstow Art (Nokia-CIC/Boston) wrote: This is a Call for Consensus (CfC) to publish a Last Call Working Draft of the following specs: 1. Server-Sent Events http://dev.w3.org/html5/eventsource/ 2. Web SQL Database http://dev.w3.org/html5/webdatabase/ 3. Web Sockets API http://dev.w3.org/html5/websockets/ 4. Web Storage http://dev.w3.org/html5/webstorage/ 5. Web Workers http://dev.w3.org/html5/workers/ I support the publication of all of these specs as LCWDs except Web SQL Database. I agree with the concerns raised by others re the normative "User agents must implement the SQL dialect supported by Sqlite 3.6.19" requirement and the lack of a commitment for a second implementation of this requirement. -Art Barstow
Re: [public-webapps] Comment on Widget URI (7)
Hi Larry, On Dec 9, 2009, at 19:20 , Larry Masinter wrote: > In general, I support appropriate use of version numbers in > languages and language specifications, especially since > documents and file formats have ample opportunities for > in-band version indicators. It's unfortunate that URIs, > being compact strings, have no place for version indicators. Thank you for your response. We therefore consider this comment disposed of with the commenter's approval. -- Robin Berjon - http://berjon.com/
Re: [public-webapps] Comment on Widget URI (7)
Hi Marcin, On Dec 9, 2009, at 22:37 , Marcin Hanclik wrote: > WOW: > It's a pity you were not involved in the discussions around P&C's version > attribute. Heh :) I doubt it would have made much of a difference; usage of version identifiers in XML languages has been a topic for almost a decade and has yet to produce much of a use for them that take the X in XML into account! -- Robin Berjon - http://berjon.com/
Re: [public-webapps] Comment on Widget URI (4)
On Dec 9, 2009, at 19:15 , Larry Masinter wrote: >>> 4) ** EDITORIAL RE OTHER SCHEME ** >>> >>> "In fact, it is possible that both this scheme and another defined to >>> access Zip archive content would be used jointly, with little or no overlap >>> in functionality." >>> >>> Without any other context, this is incomprehensible. >>> >>> Suggestion: remove sentence. >> >> Fair enough. The entire section has been removed. > > I looked for a version of the document in which the entire > section has been removed. It's still there in > http://www.w3.org/TR/widgets-uri/, and the "Latest Editor's > Draft" link supplied is 404 Not Found. Sorry about that, I'm not sure how this went through PubRules! The ED is at: http://dev.w3.org/2006/waf/widgets-uri/ -- Robin Berjon - http://berjon.com/
Re: [public-webapps] Comments on Widget URI (General)
Hi Larry,
On Dec 7, 2009, at 20:03 , Larry Masinter wrote:
> I'll ask the TAG to review your responses at our F2F this week.
> Sorry for the delay.
Has there been any output from the TAG's meeting? I see from the minutes that
there is some discussion but it seems to be erroneous in parts ("widget URIs
are used in a 'manifest' contained within a widget package"). There seems to be
no specific resolution, action, or documented consensus. Are we to expect later
input?
--
Robin Berjon - http://berjon.com/
Re: [public-webapps] Comment on Widget URI (1)
Hi Larry, On Dec 7, 2009, at 19:59 , Larry Masinter wrote: > If the purpose of the authority and query components is that they are > supposed to be processed by scripts in pages that use widget URIs, > then the specification should say so. Opaque fields with no semantics > and no identified purpose are not "well-defined", in my opinion. > > There is some reasonable risk that implementors will take what > is currently defined as "opaque" in the authority field and use > it for cross-widget references. Without clear definition of these > semantics, to merely leave it as "out of scope" introduces a > security risk. > > If implementations MUST completely ignore the authority field > and MUST treat any reference as if it ONLY applied to the local > widget, then that would address the security concern. The intent is that they are reserved for future use (and therefore that implementers doing anything with them now do so at the risk of being railroaded later). Would making this clearer address your concerns? -- Robin Berjon - http://berjon.com/
Re: [public-webapps] Comment on Widget URI (2)
Hi Larry, On Dec 9, 2009, at 17:55 , Larry Masinter wrote: > http://tools.ietf.org/html/draft-duerst-iri-bis-07#section-5 > > gives several different examples of normalization and > comparison of strings for the purpose of identification. Yes. That's why we indicate that "A producer MUST generate URIs that are normalised according to chapter 5.3.2. "Syntax-Based Normalization" of [RFC3987]." RFC 3987 further states that "IRIs already in Unicode MUST NOT be normalized before parsing or interpreting." It goes on to add further details in the rest of 5.3.2.2. > I can't figure out from the document of the > Widget: URI scheme which, if any, of the comparison > algorithms are recommended. In fact, the assertion > that using UTF-8 is "recommended" seems like it would > result in ambiguous interpretation of URIs if some > implementations use UTF-8 and others don't. I'm sorry, I can't find a single location in either the published draft nor the editor's draft that states that for widget URIs UTF-8 is "recommended". The Widget P+C specification states that it is recommended to use UTF-8 for the file name field of the local file header of a file entry. One may indeed be able to use something else, and user agents may indeed be able to do something with that, but really all bets are off. > So, if I have a file named Voß.html and a relative > IRI that points to voss.html, do they match or not? > You say "case sensitive", do you mean "byte for byte"? > Do half-width romaji characters match the full-width > romaji characters? Does anyone ever really mean byte for byte in string comparisons? Since these IRIs are not normalised, would you prefer "codepoint for codepoint" appended to "case sensitive"? Or am I missing something in your comment? > Perhaps it's necessary to dig further into the > widget spec to insure this is not an ambiguity, but > the question was whether the widget specification > was "well-defined", and my comment was that it > didn't seem to be. P+C is a separate specification over which WURIs are but a layer, but likewise is indicating codepoint-matching what you are requesting there? Sorry for being thick but it is hard to be certain what the desired outcome from your comment is. -- Robin Berjon - http://berjon.com/
Re: [widgets] test suite, the width/height attribute
On Tue, Dec 15, 2009 at 9:57 AM, Cyril Concolato wrote: > Hi Marcos, > > Le 14/12/2009 16:49, Marcos Caceres a écrit : >> >> On Fri, Dec 4, 2009 at 5:04 PM, Cyril Concolato >> wrote: >>> >>> Dear Widgets-experts, >>> >>> While checking some of the tests, I found some unclear processing with >>> regards to the width and height attribute of widget element. The spec >>> says: >>> >>> "If the width attribute is used, then let normalized width be the result >>> of >>> applying the rule for parsing a non-negative integer to the value of the >>> attribute. If the normalized width is not in error and greater than 0, >>> then >>> let widget width be the value of normalized width. If the width attribute >>> is >>> in error, then the user agent must ignore the attribute." >>> >>> It explicitely says "greater than 0" which means that 0 should not be >>> allowed, but the test suite says for c9.wgt that the result should be 0. >> >> Argh. Right. >> >>> This seems inconsistent. On top of that, the spec seems to make the >>> distinction between 'null' (when in error) and '0' (not specified). From >>> an >>> implementation point of view, I would prefer two cases: >>> - specified, not in error, greater than 0, width = the specified value >>> - in error or not specified, width = null, empty or 0. >>> Actually, I would prefer 0 since then the attribute can be implemented as >>> an >>> integer not as a string. >>> >>> What do you think ? >> >> Given that a number of UAs have implemented support for getting back >> the value "0", I think we should just say "greater than or equal to >> 0". >> >> So: >> >> = Error. value remains null. >> >> = Error, value remains null. >> >> returns 0, value is 0. >> >> returns 100, value is 100. >> >> returns 100, value is 100. >> >> However, I'm open to just saying return 0 upon error. > > That's what I would prefer. > Me too, that's what the spec says now. -- Marcos Caceres http://datadriven.com.au
[widgets] test suite: br.wgt
Hi all, In the test suite, the test br.wgt leads to a widget with no valid start file. I think this should be considered an invalid widget because a Widget UA will not be able to display it, the user may see an icon but nothing happening when activating it. WDYT ? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/widgets
Re: [public-webapps] Comment on Widget URI (3)
Hi Larry, On Dec 9, 2009, at 19:08 , Larry Masinter wrote: > Your reference to 'every drive-by "you should use this!" argument' > is mainly irrelevant to my comment and I assume your goal was > to be insulting, alluding to > http://en.wikipedia.org/wiki/Drive-by_shooting -- unless you have > some other explanation for your intent? I am sorry that you perceived my intent as being one of insult. I have nothing if not respect for you. Rather, my intent was merely to proffer a candid characterisation of your comment, as originally phrased. The term "drive-by comment" is one made against a specification in passing without the diligence and conscientiousness to participate in the follow-up discussion; and typically to then re-iterate it later. I believe that the term was coined during the denial of service by LC-comment conducted against SVG Tiny 1.2 — I may have mistakenly taken its usage to be more widespread. Since you had made this comment before, and since it had been argued against, doing the same thing yet again while presumably expecting different results can be understood as either 1) a lack of diligence in paying attention to the outcome from the same action performed previously (i.e. a "drive-by" comment); 2) the proverbial madness; or 3) deliberate process-based obstruction. Given the options, I elected to consider you neither mad nor deliberately obstructive. Thank you for now taking the time to discuss our previous response as part of this comment. > Your previous reply: > > http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0972.html > > contains interestingly the statement that: > > # I think that this demonstrates that, technically speaking, > # reusing thismessage: *can* be done. > > It does go on to discuss the costs of doing so, but the > costs are all a matter of writing technical specifications > and updating the "thismessage" definition to clarify the > ambiguities which you alluded to, and not technical > impediments. I had frankly taken your previous note as > indicating that you would consider "thismessage:/" > more carefully. It appears that my non-native and therefore imperfect command of the many English vernaculars has led me to the mistaken belief that emphasising "can" was rather universally used as an elided apophasis to strongly imply "should not". Since apparently that is not the case, I apologise for the confusion and shall endeavour to speak more clearly in future. That having been said, the sentence after the one you cite is "I am very much unconvinced that the cost/benefit analysis weighs in its favour"; and the conclusion of my post is "there is such a thing as reuse for reuse's sake. We're obviously fully open to other opinions, but for the time being we will stick to "widget:". The same message further indicates at the very least that thismessage: is so unclearly specified that its definition could be vastly improved simply by existing; that it appears to be unclear how relative URIs are resolved; that I cannot find a clear interpretation of what it does without exegesis through elimination and even then remain uncertain; that we'd have to map a widget package onto multipart/related messages (with no obvious benefit and potential incompatibilities); that bringing in MIME baggage is hardly something one feels comfortable doing nowadays; that our L10N model has no correlate in RFC 2557; that the implementation status of thismessage is pretty much unknown; and that all we get from the reuse is a label. The length of the analysis I provided in the message you quote is several times the length of what I will stretch generosity to call the "definition" of thismessage that RFC 2557 provides. I must admit to being rather baffled that you concluded from that that I would consider thismessage more carefully. I am not sure how much more carefully it could be considered without appealing to Deconstructionism, and one is generally fond of not going there. The one and only thing that thismessage has going for it is that it is registered. Frankly, that's not much to go on. Given that we thankfully now have higher standards for registering schemes, I would content that the best path forward would be to clean up and unregister "thismessage". > If you replace the string "widget" with the string "thismessage" We could certainly change the string of the scheme's name, but what of the MIME baggage that thismessage brings in? We certainly want none of it; and to be honest why should we? At some abstract distance they can be seen to be somewhat vaguely related, but then again so are HTTP and FTP. Should we also have FTP use HTTP URIs? After careful analysis, informed by your comments, all I can find to say about thismessage is that it's utterly underspecified, related to MIME somehow, and has its name in the registry's parking lot; while the widget URI scheme is far better specified even if perhaps imperfectly and enti
Re: [public-webapps] Comment on Widget URI (5)
Robin Berjon wrote: Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 5) ** EDITORIAL USE OF URI FOR IRI ** "Throughout this specification, wherever the term URI [URI] is used, it can be replaced interchangeably with the term IRI [RFC3987]. All widget URIs are IRIs, but the term URI is more common and was therefore preferred for readability." Seriously, do we need a W3C Guideline or Finding to cover "DO NOT REDEFINE TERMS"? There's glory for you! (see http://www.sabian.org/Alice/lgchap06.htm ). Suggestion: Use "IRI" since that's what is meant. It seems that we seriously need a finding explaining to specification authors that creating new terms where existing widely used ones can be made to work is a bad idea that will most likely fail. Most technically savvy people I have ever met don't know what an IRI is, and of the happy few who do I've seen many a native English speaker stumble while trying to speak of them orally. All that is needed for interoperability is for implementers to know that widget URIs are IRIs, and the document addresses that. Importing the "IRI" term into our space would have as sole further benefit to import the confusion and tongue-twisting that surround it. I recommend that while IRIs are being reinvestigated at the IETF, the naming issue be addressed. Meta-comment: this is why I think re-defining things to make things "less confusing" is the wrong approach. Please-coordinate with HTML5's Ian Hickson, who thinks that "URL" is the right term to use, rather than "URI" (here), and the proper terminology. Best regards, Julian
Re: [widgets] test suite: br.wgt
Hi Cyril On Tue, Dec 15, 2009 at 4:41 PM, Cyril Concolato wrote: > Hi all, > > In the test suite, the test br.wgt leads to a widget with no valid start > file. I think this should be considered an invalid widget because a Widget > UA will not be able to display it, the user may see an icon but nothing > happening when activating it. WDYT ? > Looking at the test description from the test suite: "br.wgt (source files) Tests the UA's ability to ignore subsequent repetitions of the content element. To pass, the widget start file must treated by the user agent as an invalid widget. " So yes, it is required to be treated as invalid? I checked the config.xml and it seem to be ok? : http://www.w3.org/ns/widgets";> br -- Marcos Caceres http://datadriven.com.au
Re: [widgets] test suite: br.wgt
Hi, Le 15/12/2009 18:00, Marcos Caceres a écrit : Hi Cyril On Tue, Dec 15, 2009 at 4:41 PM, Cyril Concolato wrote: Hi all, In the test suite, the test br.wgt leads to a widget with no valid start file. I think this should be considered an invalid widget because a Widget UA will not be able to display it, the user may see an icon but nothing happening when activating it. WDYT ? Looking at the test description from the test suite: "br.wgt (source files) Tests the UA's ability to ignore subsequent repetitions of the content element. To pass, the widget start file must treated by the user agent as an invalid widget. " My mistake, I must have misread with one of the above or below example... BTW, maybe you can improve the sentence: "Tests the UA's ability to ignore subsequent repetitions of the content element. To pass, the widget must *be* treated by the user agent as an invalid widget." remove 'start file' and add 'be' Cyril So yes, it is required to be treated as invalid? I checked the config.xml and it seem to be ok? : http://www.w3.org/ns/widgets";> br -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [public-webapps] Comments on Widget URI (General)
On Tue, Dec 15, 2009 at 2:52 PM, Robin Berjon wrote:
> Hi Larry,
>
> On Dec 7, 2009, at 20:03 , Larry Masinter wrote:
>> I'll ask the TAG to review your responses at our F2F this week.
>> Sorry for the delay.
>
> Has there been any output from the TAG's meeting? I see from the minutes that
> there is some discussion but it seems to be erroneous in parts ("widget URIs
> are used in a 'manifest' contained within a widget package"). There seems to
> be no specific resolution, action, or documented consensus. Are we to expect
> later input?
>
To be clear, AFAIK, there are no use cases for using a WURI in a
configuration document (which is what I assume was meant by a
'manifest'). Widget config docs use "zip-relative-paths" to point to
files in a widget package. And, I'll add, Zip-relative-paths are not
URI references, in case anyone was wondering (they map character per
character to file paths in the zip archive).
--
Marcos Caceres
http://datadriven.com.au
Re: [public-webapps] Comment on Widget URI (5)
Hi Julian, On Dec 15, 2009, at 17:34 , Julian Reschke wrote: > Robin Berjon wrote: >> It seems that we seriously need a finding explaining to specification >> authors that creating new terms where existing widely used ones can be made >> to work is a bad idea that will most likely fail. Most technically savvy >> people I have ever met don't know what an IRI is, and of the happy few who >> do I've seen many a native English speaker stumble while trying to speak of >> them orally. >> All that is needed for interoperability is for implementers to know that >> widget URIs are IRIs, and the document addresses that. Importing the "IRI" >> term into our space would have as sole further benefit to import the >> confusion and tongue-twisting that surround it. >> I recommend that while IRIs are being reinvestigated at the IETF, the naming >> issue be addressed. > > Meta-comment: this is why I think re-defining things to make things "less > confusing" is the wrong approach. > > Please-coordinate with HTML5's Ian Hickson, who thinks that "URL" is the > right term to use, rather than "URI" (here), and the proper terminology. I think that solving the URL/URI/IRI/whatever else terminology issue for everyone else is not within our mandate (and I think I speak for many when I say we're quite happy about that). Both URL and URI are nowadays in reasonably wide usage in the technical community so I don't think that it matters much if HTML5 uses one and widgets the other. When the IETF, the TAG, or whoever else takes it upon themselves to finally tackle this universally I am sure that we'll be happy to align. -- Robin Berjon - http://berjon.com/
Re: [widgets] test suite: br.wgt
Cyril Concolato wrote: Hi, Le 15/12/2009 18:00, Marcos Caceres a écrit : Hi Cyril On Tue, Dec 15, 2009 at 4:41 PM, Cyril Concolato wrote: Hi all, In the test suite, the test br.wgt leads to a widget with no valid start file. I think this should be considered an invalid widget because a Widget UA will not be able to display it, the user may see an icon but nothing happening when activating it. WDYT ? Looking at the test description from the test suite: "br.wgt (source files) Tests the UA's ability to ignore subsequent repetitions of the content element. To pass, the widget start file must treated by the user agent as an invalid widget. " My mistake, I must have misread with one of the above or below example... BTW, maybe you can improve the sentence: "Tests the UA's ability to ignore subsequent repetitions of the content element. To pass, the widget must *be* treated by the user agent as an invalid widget." remove 'start file' and add 'be' Fixed.
Re: [public-webapps] Comment on Widget URI (2)
Hi Larry, On Tue, Dec 15, 2009 at 3:52 PM, Robin Berjon wrote: > Hi Larry, > > On Dec 9, 2009, at 17:55 , Larry Masinter wrote: >> http://tools.ietf.org/html/draft-duerst-iri-bis-07#section-5 >> >> gives several different examples of normalization and >> comparison of strings for the purpose of identification. > > Yes. That's why we indicate that "A producer MUST generate URIs that are > normalised according to chapter 5.3.2. "Syntax-Based Normalization" of > [RFC3987]." > > RFC 3987 further states that "IRIs already in Unicode MUST NOT be normalized > before parsing or interpreting." It goes on to add further details in the > rest of 5.3.2.2. > >> I can't figure out from the document of the >> Widget: URI scheme which, if any, of the comparison >> algorithms are recommended. In fact, the assertion >> that using UTF-8 is "recommended" seems like it would >> result in ambiguous interpretation of URIs if some >> implementations use UTF-8 and others don't. > > I'm sorry, I can't find a single location in either the published draft nor > the editor's draft that states that for widget URIs UTF-8 is "recommended". > > The Widget P+C specification states that it is recommended to use UTF-8 for > the file name field of the local file header of a file entry. One may indeed > be able to use something else, and user agents may indeed be able to do > something with that, but really all bets are off. > Zip 6.3 only supports UTF-8 and CP437. When UTF-8 is used, it must be implicitly marked as such. Hence, you always know which encoding you are getting: http://www.pkware.com/documents/casestudies/APPNOTE.TXT >> So, if I have a file named Voß.html and a relative >> IRI that points to voss.html, do they match or not? >> You say "case sensitive", do you mean "byte for byte"? >> Do half-width romaji characters match the full-width >> romaji characters? > > Does anyone ever really mean byte for byte in string comparisons? Since these > IRIs are not normalised, would you prefer "codepoint for codepoint" appended > to "case sensitive"? Or am I missing something in your comment? > >> Perhaps it's necessary to dig further into the >> widget spec to insure this is not an ambiguity, but >> the question was whether the widget specification >> was "well-defined", and my comment was that it >> didn't seem to be. > > P+C is a separate specification over which WURIs are but a layer, but > likewise is indicating codepoint-matching what you are requesting there? > Sorry for being thick but it is hard to be certain what the desired outcome > from your comment is. > Agreed. It might be a help to check the following algorithm in P&C: http://dev.w3.org/2006/waf/widgets/#rule-for-finding-a-file-within-a-widget-0 And the definition of a zip relative path: http://dev.w3.org/2006/waf/widgets/#zip-relative-path -- Marcos Caceres http://datadriven.com.au
Re: [public-webapps] Comment on Widget URI (5)
Robin Berjon wrote: Hi Julian, On Dec 15, 2009, at 17:34 , Julian Reschke wrote: Robin Berjon wrote: It seems that we seriously need a finding explaining to specification authors that creating new terms where existing widely used ones can be made to work is a bad idea that will most likely fail. Most technically savvy people I have ever met don't know what an IRI is, and of the happy few who do I've seen many a native English speaker stumble while trying to speak of them orally. All that is needed for interoperability is for implementers to know that widget URIs are IRIs, and the document addresses that. Importing the "IRI" term into our space would have as sole further benefit to import the confusion and tongue-twisting that surround it. I recommend that while IRIs are being reinvestigated at the IETF, the naming issue be addressed. Meta-comment: this is why I think re-defining things to make things "less confusing" is the wrong approach. Please-coordinate with HTML5's Ian Hickson, who thinks that "URL" is the right term to use, rather than "URI" (here), and the proper terminology. I think that solving the URL/URI/IRI/whatever else terminology issue for everyone else is not within our mandate (and I think I speak for many when I say we're quite happy about that). Both URL and URI are nowadays in reasonably wide usage in the technical community so I don't think that it matters much if HTML5 uses one and widgets the other. When the IETF, the TAG, or whoever else takes it upon themselves to finally tackle this universally I am sure that we'll be happy to align. Well, for now the answer is in RFC 3986 and 3987, and I currently do not see any attempt to change what URI or IRI mean, just new terms defined on top of it. BR, Julian
Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
On Mon, Dec 14, 2009 at 6:14 PM, Jonas Sicking wrote: > On Mon, Dec 14, 2009 at 4:52 PM, Tyler Close wrote: >> On Sun, Dec 13, 2009 at 6:15 PM, Maciej Stachowiak wrote: >>> There seem to be two schools of thought that to some extent inform the >>> thinking of participants in this discussion: >>> 1) Try to encourage capability-based mechanisms by not providing anything >>> that lets you extend the use of origins and cookies. >>> 2) Try to build on the model that already exists and that we are likely >>> stuck with, and provide practical ways to mitigate its risks. >> >> My own perspective on this is: >> 3) In scenarios involving more than 2 parties, the ACL model is >> inherently vulnerable to CSRF-like problems. So, for cross-origin >> scenarios, a non-ACL model solution is needed. >> >> The above is a purely practical perspective. When writing or auditing >> code, UM provides a way to eliminate an entire class of attacks. I >> view it the same way I do moving from C to a memory safe language to >> avoid buffer overflow and related attacks. > > For what it's worth, I'm not sure that "eliminating" is correct here. > With UM, I can certainly see people doing things like using a wrapping > library for all UM requests (very commonly done with XHR today), and > then letting that library add the security token to the request. Yes, I said "provides a way to eliminate". I agree that UM doesn't by itself eliminate CSRF in a way that can't be undone by poor application design. The UM draft we sent to this list covers this point in the "Security Considerations" section. See the second to last paragraph in that section: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/att-0931/draft.html#security That paragraph reads: """ Application designers should design protocols that transmit only those permissions justified by the purpose of each request. These permissions should not be context sensitive, such as "apply delete permission to any identifier in this request". Such a permission creates the danger of a CSRF-like attack in which an attacker causes an unexpected identifier to be in the request. Instead, a permission should be specific, such as "apply delete permission to resource foo". """ UM provides a safe substrate for application protocols that are invulnerable to CSRF-like attacks. Without UM, this can't be done since the browser automatically adds credentials to all requests. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
On Mon, Dec 14, 2009 at 4:26 PM, Tyler Close wrote: > On Mon, Dec 14, 2009 at 2:38 PM, Adam Barth wrote: >> On Mon, Dec 14, 2009 at 2:13 PM, Tyler Close wrote: >>> For example, the >>> User Consent Phase and Grant Phase above could be replaced by a single >>> copy-paste operation by the user. >> >> Any design that involves storing confidential information in the >> clipboard is insecure because IE lets arbitrary web sites read the >> user's clipboard. You can judge that to be a regrettable choice by >> the IE team, but it's just a fact of the world. > > And so we use the alternate, no-copy-paste design on IE while waiting > for a better world; one in which users can safely copy data between > web pages. Just so that everyone knows, IE has changed this policy, so it's not a situation where we'll be waiting forever. See: http://msdn.microsoft.com/en-us/library/bb250473(VS.85).aspx Adam, were you aware of this policy change? --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
On Tue, Dec 15, 2009 at 10:12 AM, Tyler Close wrote: > Just so that everyone knows, IE has changed this policy, so it's not a > situation where we'll be waiting forever. See: > > http://msdn.microsoft.com/en-us/library/bb250473(VS.85).aspx > > Adam, were you aware of this policy change? Nope. I'm glad to see IE is making progress. I suspect a large percentage of users will click through that dialog, but that gives us hope that the IE team will eventually remove the dialog as well. Adam
Re: [AC/CORS] Proper behavior for user agents who return 'null' Access-Control-Allow-Origin
On Tue, Dec 15, 2009 at 4:10 AM, Anne van Kesteren wrote: > On Mon, 14 Dec 2009 11:03:27 +0100, Jonas Sicking wrote: >> >> My recollection from the meeting in seattle was that we did not want >> to allow this. >> >> In any case, it does seem like a very strange feature to me. Sending >> >> Access-Control-Allow-Origin: null >> >> would then mean essentially, "allow access to everyone who I don't >> know who it is". I can't think of a situation where this makes sense. > > The use case we discussed was allowing e.g. personalized search results even > from things that do not have an origin. (You cannot do that with * because > we explicit disallowed credentials there.) Hmm.. ok, i guess i buy that. / Jonas
Re: [public-webapps] Comment on Widget URI (3)
On Tue, Dec 15, 2009 at 6:09 PM, Robin Berjon wrote: > The term "drive-by comment" is one made against a specification in passing > without the diligence and conscientiousness to participate in the follow-up > discussion; and typically to then re-iterate it later. I believe that the > term was coined during the denial of service by LC-comment conducted against > SVG Tiny 1.2 — I may have mistakenly taken its usage to be more widespread. For the record, drive-by commenting exists in bugzilla.mozilla.org, along with drive-by reviewing (a form of commenting where one gives a review, typically negative).
RE: Microsoft pre-LCWD feedback on WebSocket API
Hi Ian, Thanks for your response. I've included the feedback that I've captured from some groups at Microsoft below. Cheers, Adrian. On Thursday, December 03, 2009 5:20 PM, Ian Hickson wrote: > On Thu, 19 Nov 2009, Adrian Bateman wrote: > > > > 1) In the WebSocket constructor, we think it would make sense to limit > > the optional protocol string to a set of characters that is easier to > > secure. The UI never surfaces this string and having something that > > doesn't require processing the full set of strings into UTF-8 > > shouldn't be a significant restriction. We also think that specifying > > length constraints would be useful. For example, stipulating the > > minimum length that conforming implementations must be able to handle. > > One suggestion was to re-use the same criteria as a valid scheme name > > as defined in section 3.1 of RFC 3986. > > I don't see why we'd make it _that_ restricted, but I do agree that it > needs to be restricted to at least disallow non-ASCII characters and > CRLF, since that would break the handshake. I've updated the spec > accordingly. Our general feeling was that having it be fairly restrictive was unlikely to be problematic and it is easier to relax the constraints if it becomes apparent that it is necessary than to try to constrain further in future. > > 3) The spec uses many terms that the HTML5 spec defines. As far as I > > can tell, there isn't a definitive list of these. The 2.1 dependencies > > section notes that many concepts come from HTML5 but not saying which > > ones seems insufficient for spec moving to Last Call. Most of the > > people who looked at this spec had never looked at HTML5 before and > > their feedback was simply that many terms were undefined. > > I recommend using the WHATWG "complete.html" version of the spec, which > integrates all of HTML5 and both the Web Sockets API and Web Socket > protocol specs (and a few others) into a single document: > >http://www.whatwg.org/specs/web-apps/current- > work/complete.html#network > > The cross-references in that document mean that all the terms defined in > HTML5 are clearly referenced. > > I am hoping that we will be able to make the postprocessor generate > appropriate cross-references even in the case of the split specs. This seems like something that should be done before the spec proceeds. Our reviewers were reading the spec linked to from the pre-LCWD feedback call. Suggesting they in fact review a different document that combines a number of different specs from different working groups (and that is also huge in comparison) isn't very practical. > > 4) In step 2 of the UA steps for the WebSocket() constructor, the spec > > calls for an exception to be thrown if the user agent chooses to block a > > well-known port. We think that web developers will often miss this case > > because it will be hard to test the error case and may be an unusual > > failure. We propose that the UA signal this condition in the same way as > > failing to connect to a service which will be much more common and more > > likely to be handled by web developers. > > Wouldn't this error be caught very early in development, when the > connection just wasn't established? > > It seems unlikely that non-hostile authors will ever run into this > anyway, since they shouldn't be using these ports. It's not clear that all user agents would impose the same rules so there's no guarantee this would be caught. It's entirely possible someone might legitimately host a WebSocket service on a well-known port believing this to be an appropriate strategy without realising that some user agents might block that. Our feedback is that it is a best practice in library design to encourage developers to handle unusual cases without the need to write extra code. It is common for developers to measure the success of their testing with code coverage - we prefer to avoid trying to get our test teams to have to set up weird test beds to construct obscure test cases to test unusual scenarios. > > 5) It is not clear precisely where the '"fail the Web Socket > connection" algorithm' is defined. > > Section 4.3. "Closing the connection" of the Web Socket protocol spec. I can't see the text "4.3" in the spec at http://dev.w3.org/html5/websockets/. Am I looking in the wrong place for section 4.3? > > 7) It is not clear exactly how to implement the bufferedAmount property > > and be interoperable. Where is the queue of bytes not yet sent? Is this > > at the application layer, in the networking stack, on the network card, > > or somewhere else? > > Any of the above that are likely to have significant caching ability. The > idea is to make it possible to write code that doesn't oversaturate the > network. > > > We propose removing the bufferedAmount property. > > What would you replace it with? We need _something_ to handle the case of > rate-limiting an infinite amount of data (e.g. sending mouse position > data
RE: CfC: to publish LCWD of: Server-Events, Web {SQL Database, Sockets, Storage, Worker}; deadline 15 December
On Saturday, December 12, 2009 11:27 AM, Arun Ranganathan wrote: > Charles McCathieNevile wrote: > > On Mon, 07 Dec 2009 16:46:12 -0800, Arthur Barstow > > wrote: > > > >> This is a Call for Consensus (CfC) to publish a Last Call Working > >> Draft of the following specs: > >> > >> 1. Server-Sent Events > >>http://dev.w3.org/html5/eventsource/ > >> > >> 2. Web SQL Database > >>http://dev.w3.org/html5/webdatabase/ > >> > >> 3. Web Sockets API > >>http://dev.w3.org/html5/websockets/ > >> > >> 4. Web Storage > >>http://dev.w3.org/html5/webstorage/ > >> > >> 5. Web Workers > >>http://dev.w3.org/html5/workers/ > >> > >> This CfC satisfies the group's requirement to "record the group's > >> decision to request advancement" to LCWD. Note that as specified in > >> the Process Document [PD], a Working Group's Last Call announcement > >> is a signal that: > > > > Opera is not convinced that webdatabase is sufficiently clear and > > supported to be a last call draft. However we support the publication > > of the other drafts mentioned as last call working drafts. > > > > My personal position is the same as the above. While I support all the > other specifications proceeding to LC, I think that more work needs to be > done in order for webdatabase to proceed to the next step. Punting to a > particular implementation (in this case, a version of SQLite) as a > normative part of a specification is unprecedented in standards that this > WG has released. At Microsoft, our position is similar on Web Database. We don't believe that relying on a particular version of SQLite is a good basis for long term interoperability. My opinion is that the database industry has spent a lot of time trying to standardise a dialect of SQL with only limited success and there's no reason to believe the WebApps working group is a good venue to try to do better. If this was a goal, we probably wouldn't start with the SQLite flavour of SQL either. We don't believe that the WebSockets API spec is sufficiently mature to move to Last Call. I don't think "Many fundamental concepts from HTML5 are used by this specification" is an adequate reference for the language included in a standalone W3C document intended to become a standard. Ian's recommendation to "[use] the WHATWG "complete.html" version of the spec" implies to me that the document is incomplete as it stands. Also, if the protocol and the API specs should be treated as part of the same thing even though published in different venues then doesn't it make sense to keep them in lock-step together? I'd appreciate some guidance from the chairs about whether they consider a document with this structure ready to move forward. Cheers, Adrian.
