Re: [XHR] chunked requests
On Sat, Dec 17, 2011 at 6:11 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 09 Dec 2011 19:54:31 +0100, Eric Rescorla e...@rtfm.com wrote: Unfortunately, many servers do not support TLS 1.1, and to make matters worse, they do so in a way that is not securely verifiable. By which I mean that an active attacker can force a client/server pair both of which support TLS 1.1 down to TLS 1.0. This may be detectable in some way, but not by TLS's built-in mechanisms. And since the threat model here is an active attacker, this is a problem. It seems user agents are addressing this issue in general by simply removing support for those servers so we might not have to define anything here and just leave it to the TLS standards: http://my.opera.com/securitygroup/blog/2011/12/11/opera-11-60-and-new-problems-with-some-secure-servers Sorry, I forgot to mention the 1/n+1 splitting countermeasure in my response. With that said, this isn't TLS 1.1, but rather a specific, more backwards-compatible countermeasure. It's fine for the security considerations section to say here that browsers must do either TLS 1.1 or 1/n+1 splitting, but it should say something, since it's not like 1/n+1 splitting is required by TLS (any version). -Ekr
Re: XBL2, Component Model and WebApps' Rechartering [Was: Re: Consolidating charter changes]
On Sat, 17 Dec 2011 16:24:47 +0100, Olli Pettay olli.pet...@helsinki.fi wrote: On 12/17/2011 04:30 PM, Anne van Kesteren wrote: On Thu, 24 Nov 2011 14:08:55 +0100, Arthur Barstow art.bars...@nokia.com wrote: All - What are the opinions on what, if anything, to do with XBL2 vis-a-vis the charter update? Leave it on the REC track, stop work and publish it as a WG Note, something else? I would leave it as, but add a note we might abandon it at some point in favor of Components. No need to make an early call on that. That sounds good to me. Yeah, in drafting the new charter I think that is the approach I took. I'll check again when we have figured out what teh story is with things people wanted but needed to provide more info for... cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
Undated references (what you are suggesting) has the MAJOR PROBLEM that it makes it DIFFICULT/IMPOSSIBLE to do validation of any product that claims conformance to a standard – since it's impossible to determine which version of each undated reference they used. Additionally, it makes interoperability difficult/impossible since you can have multiple valid conforming implementations BUT they don't actually interoperate due to changes between revisions (and algo changes would be a good example of such an interoperability issue). Leonard From: Marcos Caceres marcosscace...@gmail.commailto:marcosscace...@gmail.com Date: Fri, 16 Dec 2011 22:49:01 -0800 To: Marcos Caceres w...@marcosc.commailto:w...@marcosc.com Cc: Rigo Wenning r...@w3.orgmailto:r...@w3.org, frederick.hir...@nokia.commailto:frederick.hir...@nokia.com frederick.hir...@nokia.commailto:frederick.hir...@nokia.com, art.bars...@nokia.commailto:art.bars...@nokia.com art.bars...@nokia.commailto:art.bars...@nokia.com, Thomas Roessler t...@w3.orgmailto:t...@w3.org, Doug Schepers schep...@w3.orgmailto:schep...@w3.org, p...@w3.orgmailto:p...@w3.org p...@w3.orgmailto:p...@w3.org, public-webapps@w3.orgmailto:public-webapps@w3.org public-webapps@w3.orgmailto:public-webapps@w3.org, public-xml...@w3.orgmailto:public-xml...@w3.org public-xml...@w3.orgmailto:public-xml...@w3.org Subject: Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG? I think I have a better solution... 1. Widgets points to unversioned: http://www.w3.org/TR/xmldsig-core/ 2. when XML dig sig pag finishes and spec goes to rec, XML Dig Sig 1.X (and future versions) gets put at http://www.w3.org/TR/xmldsig-core/ 3. Done. That way widgets always just depend on latest and greatest version of XML dig sig and are not locked into 1.1 (I just finished slamming the XHTML guys for locking into XML 4ed, so it would be ironic/moronic for me to then do the same with widget's dependency on XML Dig Sig 1.1 - so I simply won't do that). I think that solves the problem much more elegantly both for widgets, and for everyone else waiting for the PAG to progress. What is needed from the XML Security Group is assurance that all future Recs of XML Dig Sig will be published at http://www.w3.org/TR/xmldsig-core/ (or http://www.w3.org/TR/xmldsig-latest/ if you don't want to obsolete 1.0 with 1.1 - though that would be confusing given that 1.1 fixes 1.0 hence making 1.0 obsolete). Unicode, SVG, and WHATWG HTML use this model effectively already, so it would be good if XML dig sigs did the same. It solves the problem now and for all future versions without need to wait on the resolution of the PAG... And the automatically benefits once the PAG sorts itself out. Simple and beautiful! :) Kind regards, Marcos On Thursday, December 15, 2011, Marcos Caceres w...@marcosc.commailto:w...@marcosc.com wrote: On Wednesday, December 14, 2011 at 10:31 PM, Marcos Caceres wrote: On Wednesday, 14 December 2011 at 21:06, Rigo Wenning wrote: Hi all, as the PAG chair of this XMLSEC PAG, let me tell you that support from the industry in sorting this out was low so far. What I heard through the grapevine was more or less: We know, but we can't tell you. For the moment, W3C is asking for cost estimates to figure out what most of the members already know (as they have done the analysis on ECC long ago). Taking into account the complexity of the subject matter and also the delays due to messaging to the AC etc, I'm rather pessimistic about a quick resolution. That's fine. That just makes for a stronger case to put to the Director (or for doing what Artb suggested, and moving the ECC to a future version of XML Dig Sig). FYI, document is ready to be published as REC: http://dev.w3.org/2006/waf/widgets-digsig/ -- Marcos Caceres
[Bug 15257] Should synchronous flag be cleared after state is set to UNSENT or DONE?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15257 Anne ann...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Anne ann...@opera.com 2011-12-18 18:23:32 UTC --- Oops, you're right! http://dvcs.w3.org/hg/xhr/rev/38004ff3f26d -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [From-Origin] on privacy leakage
On Tue, 04 Oct 2011 22:41:58 +0200, Karl Dubost ka...@opera.com wrote: in http://www.w3.org/TR/from-origin/#introduction Suggestion for rewriting privacy leakage: Privacy leakage — Web sites often provide services depending on third party Web sites (such as social network sign-in for commenting). These systems are storing credentials using cookies. It makes it possible to trigger the download of certain resources from the 1st party Web site. With this mechanism, the third party Web sites can gain knowledge on which first party Web site the visitor is signed on. I tweaked the wording somewhat. I think your suggestion is less clear than what we have now. -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
On Sunday, December 18, 2011 at 5:45 PM, Leonard Rosenthol wrote: Undated references (what you are suggesting) has the MAJOR PROBLEM that it makes it DIFFICULT/IMPOSSIBLE to do validation of any product that claims conformance to a standard – since it's impossible to determine which version of each undated reference they used. That's a FEATURE, not a problem. Makes it inexcusable not to keep up with specs (same design built into HTML5, SVG, etc.). See also how this de-cupling worked for XML: http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0192.html http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0201.html Additionally, it makes interoperability difficult/impossible since you can have multiple valid conforming implementations BUT they don't actually interoperate due to changes between revisions (and algo changes would be a good example of such an interoperability issue). I don't see how that is possible: if your spec does not conform to /latest/, then you are non-conforming. If you were conforming yesterday, but a new version of the a spec comes out tomorrow, then you update your software to conform to the latest version. As an example, almost all Browsers are on a 6 week release cycle now: so it's quite inexcusable to expect to just conform to some dates draft and then expected to never have to update the software (i.e., conformance is an ongoing living process: specs are buggy, tests are buggy, and software is buggy… any of those can affect an conformance over time: the are all living things). Pretending that slapping a date on spec means anything is unhelpful (and actually harmful, because all specs contain bugs and hence must be continuously maintained). -- Marcos Caceres
Re: [FileAPI] Remove readAsBinaryString?
What's the point of having deprecated features in a spec? If the purpose of a specification is to get interoperability, then a UA either does or doesn't need to implement the feature. There's no point in keeping a feature that we think should be killed and there's no point in removing a feature that can't be killed because too much web content relies on it. DOM4 does mark some things as historical, but DOM4's use of historical is different than deprecating it in a subtle but important way. The historical bits in DOM4 will still need to be implemented by all UAs, but the features they correspond to won't (e.g. enums for node types that we're killing are kept). On Fri, Dec 16, 2011 at 8:42 AM, Arun Ranganathan aranganat...@mozilla.comwrote: I'm happy to remove this from the specification. Right now this is marked as deprecated, which I suppose isn't strong enough discouragement? :) - Original Message - Another topic that came up at TPAC was readAsBinaryString [1]. This method predates support for typed arrays in the FileAPI and allows binary data to be read and stored in a string. This is an inefficient way to store data now that we have ArrayBuffer and we'd like to not support this method. At TPAC I proposed that we remove readAsBinaryString from the spec and there was some support for this idea. I'd like to propose that we change the spec to remove this. Thanks, Adrian. [1] http://dev.w3.org/2006/webapi/FileAPI/#readAsBinaryString
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
On 12/18/11 2:31 PM, Marcos Caceres w...@marcosc.com wrote: On Sunday, December 18, 2011 at 5:45 PM, Leonard Rosenthol wrote: Undated references (what you are suggesting) has the MAJOR PROBLEM that it makes it DIFFICULT/IMPOSSIBLE to do validation of any product that claims conformance to a standard since it's impossible to determine which version of each undated reference they used. That's a FEATURE, not a problem. Makes it inexcusable not to keep up with specs (same design built into HTML5, SVG, etc.). Keeping up with the specs is a business decision NOT something that is tied to compliance with a standard. In fact, in some cases, it may be mandated (by law or commerce) that one does NOT keep up and instead relies on a specific version. Use of undated resources prevents that. In what way do you believe that it is built into HTML5 or SVG? Both of those W3C documents use dated references. Additionally, it makes interoperability difficult/impossible since you can have multiple valid conforming implementations BUT they don't actually interoperate due to changes between revisions (and algo changes would be a good example of such an interoperability issue). I don't see how that is possible: if your spec does not conform to /latest/, then you are non-conforming. That's one way to read it, mine is the other way. If you were conforming yesterday, but a new version of the a spec comes out tomorrow, then you update your software to conform to the latest version. As an example, almost all Browsers are on a 6 week release cycle now: Browsers are just one of MANY types of software in the world that may choose to adopt this standard. Some of those other types may not be on such short cycles. Some of those other types may not be ABLE to rev often (think hardware/firmware, medical devices, etc.). Some of those other types may be operating in mandated environments (think government). Pretending that slapping a date on spec means anything is unhelpful (and actually harmful, because all specs contain bugs and hence must be continuously maintained). A spec, probably true. An international standard from a reputable SDO - EXACTLY THE OPPOSITE! It is a REQUIREMENT that standards issues by SDO's be dated and frozen at a given point in time in order for them to be implemented, validated and approved for use in mandated environments. But then the living standard argument continues to wage in many places and I don't see a need to continue it here. Leonard
Re: [FileAPI] Remove readAsBinaryString?
I don't think it's practical for developers to follow the change logs. I've certainly missed a few. While readAsBinaryString and readAsDataURL are very rarely used, it seems to me that editors should take some extra effort to help out developers who have in good faith, jumped on the HTML5 bandwagon. Web Apps and HTML5 seem to me, to be quite different than other specs. I think they're a special case. Google code search shows readAsDataURL to be about as popular as the deprecated readAsBinaryString. It'd be nice if somewhere, near the spec but not in it, this history was maintained in a readable and index-able form. Change logs do accomplish that, but they are more difficult to get to. http://www.google.com/search?q=readAsBinaryString I do think that this deprecated feature can be removed from the File API spec altogether. I'd still like a human-usable place to point to. Scenario: Alice, a random developer, sends a note to Bob a phonegap committer about readAsBinaryString being deprecated. Bob is surprised, looks at the File API spec and sees that the method indeed is missing. What happened?, wonders Bob. Bob knows the specs are in constant flux, and doesn't know what to do. Bob is scared. Even a simple Editors log supplemental would give some credibility and explanation for the change, allowing Bob to feel more confident in removing hooks, even allowing Bob to update his own change logs with references to the editor's changes. It's just a bit more formal than pointing to VCS revision markers. I hope I've helped a little here. To be absolutely clear: I'm fine with the method being removed, and I'm not demanding the editor stash the old IDL, text nor reason in any particular place. I'm just requesting we consider that, as part of this living spec process, we maintain a living journal of deprecated APIs. -Charles On 12/18/11 11:42 AM, Ojan Vafai wrote: What's the point of having deprecated features in a spec? If the purpose of a specification is to get interoperability, then a UA either does or doesn't need to implement the feature. There's no point in keeping a feature that we think should be killed and there's no point in removing a feature that can't be killed because too much web content relies on it. DOM4 does mark some things as historical, but DOM4's use of historical is different than deprecating it in a subtle but important way. The historical bits in DOM4 will still need to be implemented by all UAs, but the features they correspond to won't (e.g. enums for node types that we're killing are kept). On Fri, Dec 16, 2011 at 8:42 AM, Arun Ranganathan aranganat...@mozilla.com mailto:aranganat...@mozilla.com wrote: I'm happy to remove this from the specification. Right now this is marked as deprecated, which I suppose isn't strong enough discouragement? :) - Original Message - Another topic that came up at TPAC was readAsBinaryString [1]. This method predates support for typed arrays in the FileAPI and allows binary data to be read and stored in a string. This is an inefficient way to store data now that we have ArrayBuffer and we'd like to not support this method. At TPAC I proposed that we remove readAsBinaryString from the spec and there was some support for this idea. I'd like to propose that we change the spec to remove this. Thanks, Adrian. [1] http://dev.w3.org/2006/webapi/FileAPI/#readAsBinaryString
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
On Dec 18, 2011, at 8:49 PM, Leonard Rosenthol lrose...@adobe.com wrote: On 12/18/11 2:31 PM, Marcos Caceres w...@marcosc.com wrote: On Sunday, December 18, 2011 at 5:45 PM, Leonard Rosenthol wrote: Undated references (what you are suggesting) has the MAJOR PROBLEM that it makes it DIFFICULT/IMPOSSIBLE to do validation of any product that claims conformance to a standard since it's impossible to determine which version of each undated reference they used. That's a FEATURE, not a problem. Makes it inexcusable not to keep up with specs (same design built into HTML5, SVG, etc.). Keeping up with the specs is a business decision NOT something that is tied to compliance with a standard. If it is in the spec, then it's a spec decision. In fact, in some cases, it may be mandated (by law or commerce) that one does NOT keep up and instead relies on a specific version. Use of undated resources prevents that. Seem like that kind of practice is misguided. Law makers and govs are not know for understanding software development. Removing dates would stop such harmful practices. In what way do you believe that it is built into HTML5 or SVG? Both of those W3C documents use dated references. I only see one date at: http://dev.w3.org/html5/spec/Overview.html#references ... Because e doc is not online. All references point to latest version. Where possible, edition info and version info has been removed (e.g., XML, Unicode, XML NS). SVG [1] used to serve 1.0, but now points to 1.1 ... And when 1.2 is done, [1] will be used. http://www.w3.org/TR/SVG/ Additionally, it makes interoperability difficult/impossible since you can have multiple valid conforming implementations BUT they don't actually interoperate due to changes between revisions (and algo changes would be a good example of such an interoperability issue). I don't see how that is possible: if your spec does not conform to /latest/, then you are non-conforming. That's one way to read it, mine is the other way. If you were conforming yesterday, but a new version of the a spec comes out tomorrow, then you update your software to conform to the latest version. As an example, almost all Browsers are on a 6 week release cycle now: Browsers are just one of MANY types of software in the world that may choose to adopt this standard. Some of those other types may not be on such short cycles. Some of those other types may not be ABLE to rev often (think hardware/firmware, medical devices, etc.). Some of those other types may be operating in mandated environments (think government). If its using widgets, then it's 99% chance it is using a browser. Not updating browsers every few months is known to be harmful... Like not updating Flash would be extremely dangerous, hence getting thankfully bugged about every few weeks on my windows machine. Now, I'm not asking that XML Sec WG stop with dated/versioned specs. I'm asking that a /latest/ version be provided for spec (such as mine) where dates and versions are irrelevant and seem as harmful. Pretending that slapping a date on spec means anything is unhelpful (and actually harmful, because all specs contain bugs and hence must be continuously maintained). A spec, probably true. An international standard from a reputable SDO - EXACTLY THE OPPOSITE! Funny then that XML, for instance, is on its 5th Ed. And that C10N is now on 2.0, and that all Recs have to include a link to an errata page. So, pretending work stops or specs are stable when the reach Rec is simply not true. It is a REQUIREMENT that standards issues by SDO's be dated and frozen at a given point in time in order for them to be implemented, validated and approved for use in mandated environments. That's maybe true for nuts, bolts, and bottle caps... But at the w3c I see nothing but a continual effort to improve and refine specs long after Rec - a good thing. The only specs that get frozen are dead specs, because there is no interest in maintaining them. Also, the fact that there needs to be two interoperable implementations before you go to Rec undermines you argument: HTML 5 again is a good case in point. It's being implemented by many people long before it is done. But then the living standard argument continues to wage in many places and I don't see a need to continue it here. Leonard
