[widgets] Jar signing vs. XML signatures
I noticed that widget packaging uses XML signatures (notorious for bugs in canonicalization/reserialization code) for signing zip files. However, signing zip files has been solved long ago for Java jar files. The mechanism or a variation of it is also used for Mozilla xpi files and ODF documents. Wouldn't it be simpler to use jar signing instead of inventing a new way of signing zip files with implementation dependencies on XML signatures and spec dependencies on XSD? (Why does the spec have dependencies on XSD?) Jar signing is pretty simple compared to XML canonicalization reserialization. When you need to reserialize XML, you import all the troubles of serializing XML (see e.g. https://issues.apache.org/bugzilla/buglist.cgi?query_format=advancedproduct=Securitycomponent=Canonicalizationcmdtype=doit ). The META-INF folder is ugly, but unsigned widgets could omit it, and it isn't much uglier than an XML signature file on the top level of the zip archive. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [widgets] Jar signing vs. XML signatures
On Apr 14, 2009, at 11:57, Thomas Roessler wrote: On 14 Apr 2009, at 10:27, Henri Sivonen wrote: Wouldn't it be simpler to use jar signing instead of inventing a new way of signing zip files with implementation dependencies on XML signatures and spec dependencies on XSD? (Why does the spec have dependencies on XSD?) Which XSD dependency do you mean? The only XSD dependencies I could think of right now are ones that say things like the value of this attribute is of type anyURI or the value space of this element is a restriction on the base64Binary XSD type. XML Signature does not require schema validation, or anything like that. Hence, spec dependencies. I don't find the string anyURI in the spec, but anyURI is a great example of why defining syntax in terms of XSD datatypes is a bad idea: http://hsivonen.iki.fi/thesis/html5-conformance-checker#iri XSD datatypes are too vague, allow whitespace where the spec writer didn't mean to allow whitespace or allow surprising values (like 0 and 1 when the spec writer though (s)he'd be allowing true and false). It is much safer to define datatypes in precise English prose like HTML5 does than to expect XSD to match what is really meant. When you need to reserialize XML, you import all the troubles of serializing XML (see e.g. https://issues.apache.org/bugzilla/buglist.cgi?query_format=advancedproduct=Securitycomponent=Canonicalizationcmdtype=doit ). The only place where you actually need canonicalization is when hashing the SignedInfo element inside the signature file (i.e., once per signature verification). Given that the signature format is profiled down pretty heavily in the widget signing spec, I'd dare a guess that most of the complexity isn't ever used, so a careful implementation might be able to write a c14n implementation that bails out on anything that doesn't look like a signature that follows the constraints in this format. If you need to do canonicalization even in one place, you need a properly debugged implementation of it. If the signature format is profiled heavily, doesn't it mean you can't even use an off-the-shelf implementation of XML signatures? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [widgets] Jar signing vs. XML signatures
On 14 Apr 2009, at 11:42, Henri Sivonen wrote: I don't find the string anyURI in the spec, but anyURI is a great example of why defining syntax in terms of XSD datatypes is a bad idea: http://hsivonen.iki.fi/thesis/html5-conformance-checker#iri anyURI is used in XML Signature. I don't know off-hand whether or not it's used within the widget signature profile. XSD datatypes are too vague, allow whitespace where the spec writer didn't mean to allow whitespace or allow surprising values (like 0 and 1 when the spec writer though (s)he'd be allowing true and false). It is much safer to define datatypes in precise English prose like HTML5 does than to expect XSD to match what is really meant. There's an interesting discussion to be had here; however, I doubt it's in scope for this WG. (In other words, this strikes me as a rathole.) When you need to reserialize XML, you import all the troubles of serializing XML (see e.g. https://issues.apache.org/bugzilla/buglist.cgi?query_format=advancedproduct=Securitycomponent=Canonicalizationcmdtype=doit ). The only place where you actually need canonicalization is when hashing the SignedInfo element inside the signature file (i.e., once per signature verification). Given that the signature format is profiled down pretty heavily in the widget signing spec, I'd dare a guess that most of the complexity isn't ever used, so a careful implementation might be able to write a c14n implementation that bails out on anything that doesn't look like a signature that follows the constraints in this format. If you need to do canonicalization even in one place, you need a properly debugged implementation of it. If the signature format is profiled heavily, doesn't it mean you can't even use an off-the- shelf implementation of XML signatures? Much of the complexity of canonicalization (and signature in general) comes from the need to deal with pretty arbitrary nodesets generated by transform chains. The widget signature profile does not use (i.e., it's a MUST NOT) any transform chains. Since the use of transforms is a choice of the signature application, you shouldn't have any trouble using existing toolkits.
Re: Simple approach for access
On Thu, Mar 26, 2009 at 6:04 PM, Robin Berjon ro...@berjon.com wrote: Hi, in the same spirit of the resolution that we made with L10N based on the principle that we define something simple now and add more complex stuff once developers have described real-world issues that we don't address, I would like to propose a similarly simple approach for access. I think there are three primary use cases which we genuinely need to address: - a widget that access a single source, or a small set of sources (e.g. three servers for a mashup, or http and https on the same); - a widget like the above, but the service uses multiple subdomains to distribute its load (e.g. web42.example.org, web2017.images.example.org...); - a widget that has to access pretty much any HTTP resource (e.g. an RSS reader). There are possibly cases in which we might want to allow a widget to access ports 8042 through to 8077, and 99, 1010, 2017, on some combinations of gopher and sftp for all of dahut.fr, dahut.org, and dahut.com but I don't think that those fall in the 80%. So here goes (not in spec-ese): The access element is used to restrict a widget's access to a limited set of network resources. In the absence of an access element, all access to network resources is forbidden. The access element has a single @href attribute the content of which is an IRI-like string. The access opening that is specified by that string is defined as follows: - the scheme component MUST be present, and access is granted only for that scheme; and - the host component MUST be present. If it begins with *. then the host that follows the *. is granted access to, as well as all of its lower-level domains; otherwise access is only granted for that domain; and - if the port component is absent, it is considered to be specified to be the default for the provided scheme. Access is granted only to that port; and - if the path and query string component is present, then access is granted for any path and query string that starts with the specified string. It is treated as an opaque string, no attempt must be made to map to potential directories on the remote server; and - if a fragment component is specified, it must be ignored. I think that the above, once tightened up for proper spec wording, gives us our basic three use cases (given that one can easily specify a handful of access elements) at a minimal cost. Derived on the above, once we see which paths are trodden and what people complain about (and we can rely on complaints to reach us) we can extend the element to provide it with much more granular matching (simply by giving it children or other attributes that override href). The point here is not to make it perfect, but to make it good enough to ship. Comments? This seems to be inline with where we were heading. Please go forth and spec it and re-post the the text here. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Jar signing vs. XML signatures
On Apr 14, 2009, at 13:01, Thomas Roessler wrote: On 14 Apr 2009, at 11:42, Henri Sivonen wrote: XSD datatypes are too vague, allow whitespace where the spec writer didn't mean to allow whitespace or allow surprising values (like 0 and 1 when the spec writer though (s)he'd be allowing true and false). It is much safer to define datatypes in precise English prose like HTML5 does than to expect XSD to match what is really meant. There's an interesting discussion to be had here; however, I doubt it's in scope for this WG. (In other words, this strikes me as a rathole.) I don't see why widgets need to depend on XML signatures at all. When you need to reserialize XML, you import all the troubles of serializing XML (see e.g. https://issues.apache.org/bugzilla/buglist.cgi?query_format=advancedproduct=Securitycomponent=Canonicalizationcmdtype=doit ). The only place where you actually need canonicalization is when hashing the SignedInfo element inside the signature file (i.e., once per signature verification). Given that the signature format is profiled down pretty heavily in the widget signing spec, I'd dare a guess that most of the complexity isn't ever used, so a careful implementation might be able to write a c14n implementation that bails out on anything that doesn't look like a signature that follows the constraints in this format. If you need to do canonicalization even in one place, you need a properly debugged implementation of it. If the signature format is profiled heavily, doesn't it mean you can't even use an off-the- shelf implementation of XML signatures? Much of the complexity of canonicalization (and signature in general) comes from the need to deal with pretty arbitrary nodesets generated by transform chains. The widget signature profile does not use (i.e., it's a MUST NOT) any transform chains. Since the use of transforms is a choice of the signature application, you shouldn't have any trouble using existing toolkits. This all seems like needless complexity to me. To sign a zip archive, one needs a manifest file that contains digests for all the other zip entries and a signature for the manifest file. Even if widgets use an XML manifest instead of a jar-style plaintext manifest (which would be supported by existing jar signing tools; analogously to the zip format itself having been chosen due to pre-existing tool support), why would one want to sign the manifest XML with the XML signature machinery instead of signing it as a sequence of bytes using a well-established detached signature format for signing a file of bytes? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [cors] security issue with XMLHttpRequest API compatibility
So, to pick up on this discussion again -- I don't think we've had a useful conclusion whether or not the client-side JavaScript code ought to explicitly enable cross-site requests (as Tyler suggests, and as IE implements in XDR) or not. All things considered, any thoughts? -- Thomas Roessler, W3C t...@w3.org On 8 Apr 2009, at 20:07, Jonas Sicking wrote: On Wed, Apr 8, 2009 at 2:23 AM, Thomas Roessler t...@w3.org wrote: Incidentally, just framing this as XHR vs XDR is a bit simplistic: E.g., one could imagine a method enableCrossSiteRequests (or something like that) which needs to be invoked before XHR can do cross site requests. Oh, indeed. I didn't mean to frame it as an XHR vs XDR thing. There's certainly other ways of doing it. Tyler also proposed adding an argument to the XHR constructor. / Jonas
Re: [widgets] Jar signing vs. XML signatures
On 14 Apr 2009, at 10:27, Henri Sivonen wrote: Wouldn't it be simpler to use jar signing instead of inventing a new way of signing zip files with implementation dependencies on XML signatures and spec dependencies on XSD? (Why does the spec have dependencies on XSD?) Which XSD dependency do you mean? The only XSD dependencies I could think of right now are ones that say things like the value of this attribute is of type anyURI or the value space of this element is a restriction on the base64Binary XSD type. XML Signature does not require schema validation, or anything like that. When you need to reserialize XML, you import all the troubles of serializing XML (see e.g. https://issues.apache.org/bugzilla/buglist.cgi?query_format=advancedproduct=Securitycomponent=Canonicalizationcmdtype=doit ). The only place where you actually need canonicalization is when hashing the SignedInfo element inside the signature file (i.e., once per signature verification). Given that the signature format is profiled down pretty heavily in the widget signing spec, I'd dare a guess that most of the complexity isn't ever used, so a careful implementation might be able to write a c14n implementation that bails out on anything that doesn't look like a signature that follows the constraints in this format.
Re: [widgets] Jar signing vs. XML signatures
Hi Henri, On Tue, Apr 14, 2009 at 12:22 PM, Henri Sivonen hsivo...@iki.fi wrote: On Apr 14, 2009, at 13:01, Thomas Roessler wrote: On 14 Apr 2009, at 11:42, Henri Sivonen wrote: XSD datatypes are too vague, allow whitespace where the spec writer didn't mean to allow whitespace or allow surprising values (like 0 and 1 when the spec writer though (s)he'd be allowing true and false). It is much safer to define datatypes in precise English prose like HTML5 does than to expect XSD to match what is really meant. There's an interesting discussion to be had here; however, I doubt it's in scope for this WG. (In other words, this strikes me as a rathole.) I don't see why widgets need to depend on XML signatures at all. When you need to reserialize XML, you import all the troubles of serializing XML (see e.g. https://issues.apache.org/bugzilla/buglist.cgi?query_format=advancedproduct=Securitycomponent=Canonicalizationcmdtype=doit ). The only place where you actually need canonicalization is when hashing the SignedInfo element inside the signature file (i.e., once per signature verification). Given that the signature format is profiled down pretty heavily in the widget signing spec, I'd dare a guess that most of the complexity isn't ever used, so a careful implementation might be able to write a c14n implementation that bails out on anything that doesn't look like a signature that follows the constraints in this format. If you need to do canonicalization even in one place, you need a properly debugged implementation of it. If the signature format is profiled heavily, doesn't it mean you can't even use an off-the-shelf implementation of XML signatures? Much of the complexity of canonicalization (and signature in general) comes from the need to deal with pretty arbitrary nodesets generated by transform chains. The widget signature profile does not use (i.e., it's a MUST NOT) any transform chains. Since the use of transforms is a choice of the signature application, you shouldn't have any trouble using existing toolkits. This all seems like needless complexity to me. To sign a zip archive, one needs a manifest file that contains digests for all the other zip entries and a signature for the manifest file. Even if widgets use an XML manifest instead of a jar-style plaintext manifest (which would be supported by existing jar signing tools; analogously to the zip format itself having been chosen due to pre-existing tool support), why would one want to sign the manifest XML with the XML signature machinery instead of signing it as a sequence of bytes using a well-established detached signature format for signing a file of bytes? Although I agree that it was probably a short-sightedness mistake on our part to not have looked at JAR signing at the start of this process, I think it is too late for you to ask us to dump over a year worth of work on this spec - especially as we are about to go to Last Call and have significant industry support (BONDI) for using XML Signatures. Although I also agree that there are issues with canonicalization, I find it hard to believe that JAR signatures are not without their own problems. I think it would be more productive to help us address the issues that you mentioned, instead of asking us to dump everything and start again. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
FYI: chartering discussion re security policy for APIs
FYI, the message below just went to the public-device-a...@w3.org list. Please follow up there. http://lists.w3.org/Archives/Public/public-device-apis/2009Apr/ Regards, -- Thomas Roessler, W3C t...@w3.org Begin forwarded message: From: Thomas Roessler t...@w3.org Date: 14 April 2009 13:34:12 GMT+02:00 To: public-device-a...@w3.org Subject: Starting the chartering discussion -- security policy for APIs Hello, it's about time that we start a chartering discussion. Fundamentals that we need to sort out in order to get from here to there: - general scope of the work (and things that are out of scope) - basic principles for the work - deliverables and milestones - resources - input documents Based on the outcomes from the workshop [1] and the notes from the mobile web breakout session at the AC meeting [2], I'd propose the following in terms of a (rough) mission and scope, and would appreciate your feed-back on this mailing list: 1. The group would be chartered to produce a framework for the expression of security policies that govern access of Web applications and widgets to security-critical APIs. To achieve this goal, the group will need to deal with the following items: - policy expression proper - identification of APIs - identification of web applications and Widgets 2. Out of scope: - concrete APIs - policy management and discovery - fundamental changes to JavaScript 3. Principles: - before inventing a new policy expression language, existing languages (such as XACML) should be reviewed for suitability - the resulting policy model must be compatible with the existing same origin policy (as documented in the HTML5 specification) - the work should not be specific to either mobile or desktop environments, but may take differences between the environments into account 4. Liaisons: - PLING (W3C Policy Languages Interest Group) - HTML WG - WebApps WG - geolocation WG - Mobile Web Best Practices WG - BONDI - OpenAjaxAlliance Note that this would be a good time for interested members to indicate *privately* whether they're willing to make chairing or editing resources available. This would also be a good time for those members who presented concrete technical proposals at the workshop to indicate whether they'll be interested in putting these proposals on the table as a basis for the work proposed here. [1] http://www.w3.org/2008/security-ws/report [2] http://lists.w3.org/Archives/Member/w3c-archive/2009Apr/0094.html Note: [2] is member-only; I'll circulate a publicly visible summary some time soon. -- Thomas Roessler, W3C t...@w3.org
Re: [cors] security issue with XMLHttpRequest API compatibility
On Apr 14, 2009, at 6:33 AM, ext Thomas Roessler wrote: So, to pick up on this discussion again -- I don't think we've had a useful conclusion whether or not the client-side JavaScript code ought to explicitly enable cross-site requests (as Tyler suggests, and as IE implements in XDR) or not. All things considered, any thoughts? I tend to think that when adding new semantics, it generally makes sense to add new syntax to support those semantics and in this case that it would be better to err on the side of caution even if the mechanism chosen isn't particularly friendly to the app developer. Yes, it would be good to get others thoughts on this, particularly those that have implemented CORS. -Regards, Art Barstow -- Thomas Roessler, W3C t...@w3.org On 8 Apr 2009, at 20:07, Jonas Sicking wrote: On Wed, Apr 8, 2009 at 2:23 AM, Thomas Roessler t...@w3.org wrote: Incidentally, just framing this as XHR vs XDR is a bit simplistic: E.g., one could imagine a method enableCrossSiteRequests (or something like that) which needs to be invoked before XHR can do cross site requests. Oh, indeed. I didn't mean to frame it as an XHR vs XDR thing. There's certainly other ways of doing it. Tyler also proposed adding an argument to the XHR constructor. / Jonas
Re: [widgets] Jar signing vs. XML signatures
Marcos Caceres marc...@opera.com wrote: Although I agree that it was probably a short-sightedness mistake on our part to not have looked at JAR signing at the start of this process, I think it is too late for you to ask us to dump over a year worth of work on this spec - especially as we are about to go to Last Call and have significant industry support (BONDI) for using XML Signatures. Although I also agree that there are issues with canonicalization, I find it hard to believe that JAR signatures are not without their own problems. I think it would be more productive to help us address the issues that you mentioned, instead of asking us to dump everything and start again. I'm willing to drop XML signing :) I guess I never really understood enough about why we went off on XML signing and didn't think to ask why we didn't look at JAR signing :(
Re: [widgets] Jar signing vs. XML signatures
On 4/14/09 2:51 PM, timeless wrote: Marcos Caceresmarc...@opera.com wrote: Although I agree that it was probably a short-sightedness mistake on our part to not have looked at JAR signing at the start of this process, I think it is too late for you to ask us to dump over a year worth of work on this spec - especially as we are about to go to Last Call and have significant industry support (BONDI) for using XML Signatures. Although I also agree that there are issues with canonicalization, I find it hard to believe that JAR signatures are not without their own problems. I think it would be more productive to help us address the issues that you mentioned, instead of asking us to dump everything and start again. I'm willing to drop XML signing :) I guess I never really understood enough about why we went off on XML signing and didn't think to ask why we didn't look at JAR signing :( I guess it was it was not done here (w3c) syndrome. Kind regards, Marcos
Re: [widgets] Jar signing vs. XML signatures
On Tue, Apr 14, 2009 at 2:56 PM, Marcos Caceres marc...@opera.com wrote: On 4/14/09 2:51 PM, timeless wrote: Marcos Caceresmarc...@opera.com wrote: Although I agree that it was probably a short-sightedness mistake on our part to not have looked at JAR signing at the start of this process, I think it is too late for you to ask us to dump over a year worth of work on this spec - especially as we are about to go to Last Call and have significant industry support (BONDI) for using XML Signatures. Although I also agree that there are issues with canonicalization, I find it hard to believe that JAR signatures are not without their own problems. I think it would be more productive to help us address the issues that you mentioned, instead of asking us to dump everything and start again. I'm willing to drop XML signing :) I guess I never really understood enough about why we went off on XML signing and didn't think to ask why we didn't look at JAR signing :( I guess it was it was not done here (w3c) syndrome. Having said that, XML Sig meets our Requirements [1]. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-reqs/#security-and-digital-signatures -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Jar signing vs. XML signatures
On Apr 14, 2009, at 14:38, Marcos Caceres wrote: I think it would be more productive to help us address the issues that you mentioned, instead of asking us to dump everything and start again. So the issues were: 1) The complexity of canonicalization/reserialization of XML. 2) Spec dependency on XSD. 3) Inability to use existing jar signing tools. If you are already profiling XML signature a lot and are already using a detached signature file, it seems to me that you are one step away from optimizing away canonicalization: Instead of canonicalizing the manifest XML and using XML signature, you could treat the manifest XML as a binary file and sign it the traditional way leaving a detached binary signature in the format customary for the signing cipher in the zip file. This would address issues #1 and #2. But then if you are signing the XML manifest file the traditional way, you are a step away from using jar-compatible manifests. :-) This would address issue #3. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [widgets] Jar signing vs. XML signatures
On 14 Apr 2009, at 16:19, Henri Sivonen wrote: Instead of canonicalizing the manifest XML and using XML signature, you could treat the manifest XML as a binary file and sign it the traditional way leaving a detached binary signature in the format customary for the signing cipher in the zip file. This would address issues #1 and #2. The manifest isn't the issue, part of the signature itself is. The widget signing proposal already makes minimal use of canonicalization.
Re: Web Storage SQL
On Apr 11, 2009, at 12:39 AM, Jonas Sicking wrote: On Fri, Apr 10, 2009 at 10:55 PM, Nikunj Mehta nikunj.me...@oracle.com wrote: On Apr 10, 2009, at 3:13 PM, Ian Hickson wrote: On Fri, 10 Apr 2009, Nikunj Mehta wrote: Can someone state the various requirements for Web Storage? I did not find them enunciated anywhere. There's only one requirement that I know of: * Allow Web sites to store structured data on the client. There are many use cases, e.g. Google is interested in this to enable its applications to be taken offline. We recently released offline GMail using this SQL backend; one could easily imagine other applications like Calendar, Reader, DocsSpreadsheets, etc, supporting offline mode. A while back we released a demo of Reader using Gears' SQL database. Last time I tried this trick I was asked to come back with more precise use cases [1]. Then I put together more detailed use cases [2], and even those were not considered to be written precisely enough. So it looks like the bar for what constitutes a use case or requirement seems to be quite high. [1] http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0079.html [2] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0104.html As far as I am concerned the use cases you enumerate in [2] were fine. However note that even the current WebStorage API makes it possible to address those use cases. Just in a way that is vastly different than the solution that you propose in [2]. Do you not agree? WebStorage does not, or for that matter any other speced API, make it possible to intercept PUT/POST/DELETE requests to perform offline behavior that can be later synchronized to the server. However there are some requirements that I think you have which were not enumerated in [2] and that are not fulfilled by the current API. Specifically the ability to use the same code to implement a strictly online application, as one that supports seamless online/offline transitions. That is correct. I.e. the WebStorage APIs require that you monitor all submissions and loads to and from the server and redirect the save/load into queries into the WebStorage API. It would also be responsible for detecting when a user goes online again after having stored data and synchronize that to the server as needed. Your requirements include that a lot of that happens seamlessly, is that correct? Yes. I think the main road block to accepting something like that is simply needing more experience in the WG. Since your requirement, or at least your proposed solution, require that the standard design how the synchronization should work, I personally would like to know more about other synchronization technologies before accepting your proposal. I have been working to simplify the requirements to allow application- specified synchronization provided: 1. The browser stores/caches certain URLs à la Gears LocalServer and the browser responds to GET/HEAD requests for those URLs 2. The browser allows JS interception of requests for non-GET/HEAD requests to certain URLs 3. The browser enforces cookie requirements for accessing those URLs 4. The browser provides some structured storage JS API for storing synchronization state (not the contents of the data itself) 5. The browser provides JS to contribute content to the browser store/ cache as text (or blob) So it has nothing to do with lack of use cases, much more to do with that we're designing a different very API, and so we need different expertise and background data. At this point, the API that is required for BITSY is far simpler than it used to be - you can just think of it as a couple of extra methods to the Gears LocalServer API. That means we have a fair amount of expertise within this WG - both Google and Oracle have toyed with slightly different parts of this problem. Oracle has implemented the browser mechanisms above as a plug-in for both Safari and Firefox. Oracle can provide this specification as a member submission if that helps the WG. But we would rather use a standard API than rely on Gears. I think if we are serious about building a good foundation for local persistence, then we should have more precise requirements for Web Storage. Otherwise, we risk prematurely standardizing some dialect of SQL supported by SQLite as Web Storage. Not sure if it makes a difference, but I would be very surprised if we ended up with the same SQL dialect as what SQLite uses. I haven't worked with SQLite personally, but from what I understand it uses some extensions that doesn't exist in many other database engines. It's important to me that we don't lock ourselves into any particular database and so we should restrict ourselves to a dialect that is widely supported. So for example if you couldn't use an Oracle DB as a backend I would be very disappointed. Here's a compilation of requirements from what I have read in this
[widgets] Agenda for 16 April 2009 Voice Conference
Below is the draft agenda for the April 16 Widgets Voice Conference (VC). Inputs and discussion before the meeting on all of the agenda topics via public-webapps is encouraged (as it can 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 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. DigSig spec http://dev.w3.org/2006/waf/widgets-digsig/ a. Feedback sought on ECDSA Curves: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0094.html b. ISSUE-83 - Instantiated widget should not be able to read digital signature http://www.w3.org/2008/webapps/track/issues/83 4. PC spec http://dev.w3.org/2006/waf/widgets/ a. Simple approach for access; see Robin's proposal http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 0943.html b. I18N proposal from Marcos: http://dev.w3.org/cvsweb/2006/waf/widgets/i18n.html 5. AE spec http://dev.w3.org/2006/waf/widgets-api/ a. preferences attribute and the Storage interface; http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0040.html b. Plan to get inputs and closure on the Red Block issues 6. Window Modes spec: status and plans 7. Updates spec: PAG status from Mike 8. AOB
Re: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]
+1 I do not understand the attack, but can envision cases where precluding access could cause problems. Examples might be user see what is signed or access to signature properties. Is this an access control issue rather than a general specification rule? regards, Frederick Frederick Hirsch Nokia On Apr 13, 2009, at 7:03 AM, Barstow Art (Nokia-CIC/Boston) wrote: On Apr 9, 2009, at 1:44 PM, ext Marcos Caceres wrote: On 4/9/09 3:56 PM, Arthur Barstow wrote: On Apr 9, 2009, at 9:52 AM, ext Marcos Caceres wrote: On Thu, Apr 9, 2009 at 2:17 PM, Priestley, Mark, VF-Group mark.priest...@vodafone.com wrote: Hi Art, All, If there is no use case for accessing this information (I was after why you would want to access this information because I think just saying it might be interesting to do so isn't justification enough), then I think my original proposal holds - make the signature files unavailable to the widget at runtime. For clarification I was not suggesting that an API should be added to the DigSig spec but rather that some of the information could be exposed via an API defined in the APIs and Events spec. But I don't think this is necessary or worth the additional specification effort. FWIW, I agree with Mark. Please propose text that will address your concerns. In the PC spec, I would add something like: A user agent MUST make the digital signature available only to implementations of the [Widgets-DigSig] specification. I don't understand why we would want to create this type for a PC UA. A user agent MUST NOT allow read access to any digital signature in the widget package at runtime. I think this conflates requirements for a PC UA with the requirements for Widget [Runtime] UA. As such, I disagree with what you are trying to prescribe here and think the specs should remain silent on this (or perhaps defer this to a definition of a Widgets UA runtime model). I still cannot understand why you want to preclude a widget from being able to access *all* of its resources. Perhaps it would be helpful if you would elaborate on the risk(s) you are trying to mitigate. -Regards, Art Barstow In other words, a user agent MUST NOT allow a start file, or any other file or resource inside or outside the context of the widget (e.g., a script or stylesheet), or API, or feature, to read any digital signature file within the widget package. At runtime, a user agent MUST make it seem as if digital signatures do not exist in the widget package by, for example, excluding them from any file listings, and not allowing them to be accessed via a URI. That's just some quick draft text, please feel free to change, add, or whatever.
Re: [Selectors] Selectors to Proposed Rec - call for consensus
On Wed, 04 Mar 2009 12:00:44 +0200, Anopti mist cha...@opera.com wrote: Hi folks, It would appear that the Selectors API is done... or nearly so. Since the call for consensus to produce a Candidate Recommendation following the Last Call and resolution of comments received, there has been one substantive change to the document - removing [Null] and [Undefined] extended attributes from IDL, added note about handling null and undefined. It seems that there is general agreement that this change does not materially impact the specification in practice, and we can therefore request Proposed Recommendation. ... This is a call for consensus on the question: ... the group should request Proposed Recommendation status for the Selectors API spec, based on the Editor's draft version 1.97[1] This question did not receive sufficient support. We will therefore publish a Candidate Recommendation. 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
New CfC Re: [Selectors API] Call for Consensus - approve John Resig's tests
ages ago I cha...@opera.com wrote: Thanks to great work by John Resig, informative analysis by Travis, and implementatio work by many, it seems this is the case. To clarify that, this is a call for consensus on the following question: The test suite by John Resig, 2009-02-19 version[1] is a sufficiently complete test suite for the editor's draft version 1.97[2] of Selectors API [1] http://github.com/jeresig/selectortest/blob/4827dedddaea6fa0b70cfdaadeeafef0d732a753/index.html [2] http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.97content-type=text/html;%20charset=iso-8859-1 Note that while silence will be taken as assent, this question will not be held to have carried without significant explicit agreement. Nor will it be held to have carried if there is any dissent. It would appear that there was not consent that the tests there were sufficient. It appears that consensus is that they are all valid, which is good :) However, we now have additional tests proposed by Erik Dahlström[1] and Ian Hickson[2,3]. In addition Lachy identified missing tests that show bugs in existing implementations[4]. So we have a new call for consensus on each of four questions: Should we make Erik's proposed changes[1] to the test suite? Should we add Hixie's first test[2]? Should we add Hixie's second test[3]? Do we need tests as described by Lachy[4] [1] http://www.w3.org/mid/op.uqxrarbjgqi...@gnorps.linkoping.osa [2] http://www.hixie.ch/tests/adhoc/dom/selectors/001.html [3] http://www.hixie.ch/tests/adhoc/dom/selectors/002.html [4] http://www.w3.org/mid/49b91637.3050...@lachy.id.au Please reply before 1 May - silence will be assent, positive early answers are preferred (especially if you think there is something we should be discussing still). 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: New CfC Re: [Selectors API] Call for Consensus - approve John Resig's tests
On Wed, 15 Apr 2009, Charles McCathieNevile wrote: So we have a new call for consensus on each of four questions: Should we make Erik's proposed changes[1] to the test suite? Should we add Hixie's first test[2]? Should we add Hixie's second test[3]? Do we need tests as described by Lachy[4] [1] http://www.w3.org/mid/op.uqxrarbjgqi...@gnorps.linkoping.osa [2] http://www.hixie.ch/tests/adhoc/dom/selectors/001.html [3] http://www.hixie.ch/tests/adhoc/dom/selectors/002.html [4] http://www.w3.org/mid/49b91637.3050...@lachy.id.au Please reply before 1 May - silence will be assent, positive early answers are preferred (especially if you think there is something we should be discussing still). I defer to Lachy's expertise on this question. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
