Re: [FileAPI] Latest Revision of Editor's Draft
On Mon, Oct 26, 2009 at 5:24 AM, Arun Ranganathan a...@mozilla.com wrote: The latest revision of the FileAPI editor's draft is available here: http://dev.w3.org/2006/webapi/FileAPI/ A few comments: * loadend should fire after load/error/abort. * I'm not sure i love the name 'fileData'. Maybe 'result' or simply 'data' is better. * Whatever the name, I don't see why 'fileData' should only be readable while an event is being fired. That seems unnecessarily complicated, doesn't match XHR and seems less useful. * fileData should probably be null rather than the empty string during on error and before data is read. * The second argument to 'splice' should be called 'length' rather than 'offset'. * I think someone had brought up a good argument for *not* throwing when slice is called with start+offset size. One of the main use cases for slice is to slice up a file in several chunks when sending with XHR. When that is done it's easy to end up with rounding errors resulting in a slightly to large length being requested. In this case it makes sense to just clamp to size rather than throwing an error. / Jonas
Re: [FileAPI] Latest Revision of Editor's Draft
On Mon, 26 Oct 2009, Arun Ranganathan wrote: 2. Interface names have changed (notably FileData -- Blob) since the underlying FileData interface had uses on the platform beyond a file read API. Blob as an interface name was first introduced by a Google Gears API, which I cite as an informative reference. Updated HTML5 and related specs. 3. The event model resembles that of XHR2, with a few differences. Notably, the APIs differ in their use of the 'loadend' ProgressEvent. I think this spec needs examples. I think the examples would show that the current design requires far too many lines of code to do something that really should only need one or two statements. (I think XHR is a very poor model to follow.) 4. A suggestion to *not* have a separate scheme (filedata:) in lieu of urn:uuid:uuid[2] has been the basis of a rewrite of that feature in this version of the specification. I would like to see implementation feedback on this. I don't understand why we would want to assign semantics to urn:uuid: URLs that are so specific -- that seems completely wrong. It also seems really awkward from an implementation perspective to forgo the normal extension mechanism (schemes) and have implementations give special (and non-trivial) semantics to a subset of another scheme. Why are we doing this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
TPAC agenda - APIs
Hi folks, there is a proposed timeline at http://www.w3.org/2008/webapps/wiki/TPAC2009APIs#Agenda_Items Please have a look, and if you think your input is important for any session but you will be in a different session, or only participating remotely, please let us know ASAP so we can attempt to make necessary arrangements (dial-up might be hard, but we can move the sessions that are not joint sessions). Note that some sessions have fairly small things in them. It would be nice to have some more free time, although we will probably manage to soak it up with discussion of other issues. 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: Value of Server-Sent Events
On Mon, 26 Oct 2009 22:57:56 +0100, Jonas Sicking jo...@sicking.cc wrote: So what do you propose in order to better support streaming downloads? Or are you arguing that streaming downloads is not a feature important enough to support at this time? What exactly do you mean with streaming downloads? For the use cases I can think of it seems that video, audio, Server-Sent Events, and Web Sockets address them quite nicely. -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] Security Guidelines for Widgets? [Was: Re: [widgets] viewmodes spec]
On Tue, Oct 27, 2009 at 4:26 PM, Arthur Barstow art.bars...@nokia.com wrote: On Oct 26, 2009, at 5:23 AM, ext David Rogers wrote: Do you know if anybody has started work on any security guidelines for widgets? I am not aware of any such work. Please see: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0364.html This is now in the spec. I've requested people contribute some text. -- Marcos Caceres http://datadriven.com.au
RE: [WARP] UPnP LAN
Hi, Additionally to the below addresses we shall probably consider IPv6 addresses. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcin Hanclik Sent: Tuesday, October 27, 2009 3:24 PM To: public-webapps Subject: [WARP] UPnP LAN Hi All, These are some comments about the requirements for WARP to handle the UPnP traffic. 1. UPnP uses multicast address 239.255.255.250. 2. UPnP uses UDP-based HTTP (GENA, SSDP). 3. The UPnP traffic takes place in local networks (LAN), therefore we shall assume that the host addresses will be from one of the private IP ranges [1]: 10.0.0.0- 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) a. We shall be able to assume that all private LANs are configured correctly with the above addresses and exclude other considerations/misconfigurations (alternatively we could mandate checking the DHCP configuration - masks etc. in the host to derive what the local network is, but it may lead us nowhere) 4. It is a security-related decision whether an application / widget may access both the Internet and the LAN network at the same time. a. Some interesting use cases may be realized. i. E.g. storage of the Internet-downloaded content (e.g. XHR's GET) onto UPnP device or e.g. SVN repository in LAN. b. Privacy is a concern. Thanks, Marcin [1] http://tools.ietf.org/html/rfc1918 Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you. Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
RE: [Widgets] Security Considerations
Hi Marcos, I think the section below is ok. FWIW: 1. As in [1] we could add more detailed statements about HTML tags. 2. Also together with the term security we could add privacy. So e.g. we may have another paragraph like this (the below text may need more details): Widget packages may contain content that is able to interact both with the remote host and local device. Therefore, implementers need to take into account the privacy-related implications resulting from the potential exposure of private information to the remote host given the relevant programming interface / model is defined. 3. [2] has a more thorough list of considerations that seem to be related to widgets, but more in the context of DAP. Anyway some of them could be reflected in the registration of application/widget. [1] http://tools.ietf.org/html/rfc4287#section-8 [2] http://dev.w3.org/geo/api/spec-source.html#security Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: Monday, October 26, 2009 6:46 PM To: public-webapps; Thomas Roessler Subject: [Widgets] Security Considerations In order to register application/widgets as an official MIME type with IANA, we need to have a section in the spec that outlines the security considerations. I've made a first stab at this section (below)... but I'm no security peep, so I would appreciate some input from those that know better... [[ Security considerations This section is non-normative. In addition to the security considerations specified for Zip files in the [Zip-MIME] registration, there are a number of security considerations that need to be taken into account when dealing with widget packages and configuration documents. As the configuration document format is [XML] and [Unicode], the security considerations described in [XML-MIME] and [UTR36] apply. The configuration document allows authors, through the feature element, to request permission to enable third-party runtime components and APIs. As these features are outside the scope of this specification, significant caution needs to be taken when granting a widget the capability to use a feature. Features themselves define their own security considerations. Widget packages will generally contain ECMAscript, HTML, CSS files, and other media, which are executed in a sand boxed environment. As such, implementers need to be aware of the security implications for the types they support. Specifically, implementers need to consider the security implications outlined in the [CSS-MIME] specification, the [ECMAScript-MIME], and the [HTML-MIME] specification. As this specification relies on the standardized heuristics for determining the content type of files defined in the SNIFF specification, implementers need to consider the security considerations discussed in the [SNIFF] specification. As this specification allows for the declaration of IRIs within certain elements of a configuration documents, implementers need to consider the security considerations discussed in the [IRI] specification. ]] -- Marcos Caceres http://datadriven.com.au Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [cors] unaddressed security concerns
On Sat, 24 Oct 2009 19:07:24 +0200, Adam Barth w...@adambarth.com wrote: On Fri, Oct 23, 2009 at 11:07 PM, David-Sarah Hopwood david-sa...@jacaranda.org wrote: The specific risk is quite clear: it's the risk of CSRF attacks that are currently prevented (or mitigated) by the same-origin policy. These won't be prevented or mitigated to the same extent by browsers that implement CORS. The reason the risk is unclear is because this scenario requires servers to opt-in to this behavior. It's hard for us to know what else server operators will do when they opt in to CORS. What is clear, however, is that in the simple cases, there is no additional CSRF risk because the set of requests an attacker can generate is not expanded by CORS. This is not limited to the simple cases, for what it's worth. It requires opt-in in all cases. By default everything is pretty much the same and the same as far as servers are concerned. -- Anne van Kesteren http://annevankesteren.nl/
Re: [Widgets] Security Considerations
On Tue, Oct 27, 2009 at 5:38 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Marcos, I think the section below is ok. FWIW: 1. As in [1] we could add more detailed statements about HTML tags. I could, but this might be mostly outdated because of HTML5. 2. Also together with the term security we could add privacy. Added. So e.g. we may have another paragraph like this (the below text may need more details): Widget packages may contain content that is able to interact both with the remote host and local device. Therefore, implementers need to take into account the privacy-related implications resulting from the potential exposure of private information to the remote host given the relevant programming interface / model is defined. I tried to shorten it and included it... details below... 3. [2] has a more thorough list of considerations that seem to be related to widgets, but more in the context of DAP. Anyway some of them could be reflected in the registration of application/widget. [1] http://tools.ietf.org/html/rfc4287#section-8 [2] http://dev.w3.org/geo/api/spec-source.html#security Ok, I took from [2] and got: As widget packages can contain content that is able to simultaneously interact with the local device and a remote host, implementers need to consider the privacy implications resulting from exposing private information to a remote host. Mitigation and in-depth defensive measures are an implementation responsibility and not prescribed by this specification. However, in designing these measures, implementers are advised to enable user awareness of information sharing, and to provide easy access to interfaces that enable revocation of permissions. -- Marcos Caceres http://datadriven.com.au
RE: [Widgets] Security Considerations
Hi Marcos, Fine for me. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Tuesday, October 27, 2009 5:23 PM To: Marcin Hanclik Cc: public-webapps; Thomas Roessler Subject: Re: [Widgets] Security Considerations On Tue, Oct 27, 2009 at 5:38 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Marcos, I think the section below is ok. FWIW: 1. As in [1] we could add more detailed statements about HTML tags. I could, but this might be mostly outdated because of HTML5. 2. Also together with the term security we could add privacy. Added. So e.g. we may have another paragraph like this (the below text may need more details): Widget packages may contain content that is able to interact both with the remote host and local device. Therefore, implementers need to take into account the privacy-related implications resulting from the potential exposure of private information to the remote host given the relevant programming interface / model is defined. I tried to shorten it and included it... details below... 3. [2] has a more thorough list of considerations that seem to be related to widgets, but more in the context of DAP. Anyway some of them could be reflected in the registration of application/widget. [1] http://tools.ietf.org/html/rfc4287#section-8 [2] http://dev.w3.org/geo/api/spec-source.html#security Ok, I took from [2] and got: As widget packages can contain content that is able to simultaneously interact with the local device and a remote host, implementers need to consider the privacy implications resulting from exposing private information to a remote host. Mitigation and in-depth defensive measures are an implementation responsibility and not prescribed by this specification. However, in designing these measures, implementers are advised to enable user awareness of information sharing, and to provide easy access to interfaces that enable revocation of permissions. -- Marcos Caceres http://datadriven.com.au Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Fwd: Rich Web Application Backplane XG Final Report Published
FYI, the Rich Web Application Backplane XG's Final Report has been published: http://www.w3.org/2005/Incubator/app-backplane/XGR-app- backplane-20091030/ Keywords: Javascript, Web Application Begin forwarded message: From: ext Ian Jacobs i...@w3.org Date: October 27, 2009 12:05:50 PM EDT Subject: Rich Web Application Backplane XG Final Report Published; XG closed I'm pleased to announce publication of: Rich Web Application Backplane XG Final Report http://www.w3.org/2005/Incubator/app-backplane/XGR-app- backplane-20091030/ Authors: Charlie Wiecha, Chair (IBM) Mark Birbeck (Invited Expert, Backplane Ltd.) John Boyer (IBM) Jack Jansen (CWI) Steven Pemberton (CWI) Gregory Rosmaita (Invited Expert) The report describes two areas of work undertaken by the XG; authoring patterns helpful in supporting high-function web applications in managing client-side data and user interaction control. In addition, a range of methods are considered for implementing such patterns in current browsers without requiring plug-ins or extensions using javascript-based markup behaviors. The Backplane XG recommends that a workshop be organized bringing together interested parties with an aim to creating a Working Group to define a standardized architecture and API for XML and HTML interaction formats implemented in Javascript. Read more in their conclusion: http://www.w3.org/2005/Incubator/app-backplane/XGR-app- backplane-20091030/#Conclusion
[widgets] PC Last Call 3
Hi All, After a successful CR period, PC is now ready to go to LC3 (should be out by friday). http://dev.w3.org/2006/waf/widgets/ The last call period will end on the 19th of Nov. Below is the list of changes form last pub (taken from the spec). [[ This section describes the high level changes that have occurred since this document was last published. This list is not exhaustive, but gives a general overview of what changed and anything new that was added. For a complete view of all the changes, please see the differences between the last published draft and this document. Conformance checker requirements are no longer part of this specification. The conformance checker requirements will be worked on independently from this document. An unpublished draft is available. A number of bugs were fixed. The details can be found in the following emails: [widgets] PC BUG ALERT: Conformance checker behavior intermixed with UA behavior [widgets] BUG ALERT for P+C spec: Try to fallback to default start files when src path is invalid or not existing [widgets] BUG ALERT for P+C spec: deprecated, grandfathered, and redundant tags should be skipped. [widgets] Potential bug in Rule for Identifying the Media Type of a File [widgets] Preference element is underspecified :( ITS is no longer marked as being at risk. ITS will remain the recommended technology to allow localization of certain localized text nodes within a configuration document. The document no longer defines conformance criteria for Zip archives: most archives are valid, but some may not be supported. The ABNF for zip relative path has been updated to address a number of issues. To reduce verbosity in the specification, the reserved folder names table was merged into the reserved file names table. It is no longer a normative requirement that PC user agents behave as a policy enforcement point with regards to scripts accessing the content of a digital signature. In addition, it is no longer a normative requirement that PC user agents behave as a policy enforcement point with regards to scripts running in SVG icons. These requirements may appear in other specifications at a future date, however. Removed assertions that were repetitions of functionality defined in the steps for processing a widget package. Added more text that is required for MIME type registration, including security considerations, interoperability issues, and encoding considerations. The icon element no longer supports xml:lang for internationalization proposes. The relax NG schema was removed from the spec. It will be maintained separately so it can be updated as the various specs that depend on it mature. The rule for identifying the media type of an image was merged with the rule for identifying the media type of a file. The definition of the widget family of specifications was moved to the working group's wiki. This specification now only defines conformance criteria for one class of products (User Agents). In previous drafts, it included conformance checkers and documents. Zip archives can no longer claim conformance to this specification. A user agent is now more clearly defined in terms of what other specifications one must support. Validity of zip relative paths is no longer dependent on encoding. Validity is now simply based on whether a zip path matches the ABNF for a zip relative path. ]] -- Marcos Caceres http://datadriven.com.au
Re: [FileAPI] Latest Revision of Editor's Draft
Jonas Sicking wrote: On Mon, Oct 26, 2009 at 5:24 AM, Arun Ranganathan a...@mozilla.com wrote: The latest revision of the FileAPI editor's draft is available here: http://dev.w3.org/2006/webapi/FileAPI/ A few comments: * loadend should fire after load/error/abort. Currently it *only* fires when error and abort events fire. I felt that 'load' was sufficient for successful reads into memory, while 'loadend' was useful for unsuccessful ones. This differs from XHR2's definition of 'loadend'[1]: When the request has completed (either in success or failure). [1] When loadend was removed from media elements [2] I wished to determine whether it was event overkill to also fire at successful reads. Sounds like you want it back for successful reads as well? * I'm not sure i love the name 'fileData'. Maybe 'result' or simply 'data' is better. I'm happy to change it to a better name, but chose 'fileData' since in the original version of the draft, with asynchronous callbacks [3], we had an interface called FileData which represented the actual file data (in the present and current version of the editor's draft -- http://dev.w3.org/2006/webapi/FileAPI/ -- FileData is called Blob) . Of the two names you suggest, do you feel strongly about one over the others? I'm not sure I love 'result' (it isn't intuitive as a response to a read), and 'data' is used in other contexts on the platform and so may be confusing. If you feel strongly (stronger than a 'maybe' ;-) ) about a different name, I'm happy to change it. * Whatever the name, I don't see why 'fileData' should only be readable while an event is being fired. That seems unnecessarily complicated, doesn't match XHR and seems less useful. Nothing in the present draft prohibits that -- I only left an editor's note as an open question. I agree with you about the desired behavior, and so I'll remove the editor's note. * fileData should probably be null rather than the empty string during on error and before data is read. Done * The second argument to 'splice' should be called 'length' rather than 'offset'. Done * I think someone had brought up a good argument for *not* throwing when slice is called with start+offset size. One of the main use cases for slice is to slice up a file in several chunks when sending with XHR. When that is done it's easy to end up with rounding errors resulting in a slightly to large length being requested. In this case it makes sense to just clamp to size rather than throwing an error. OK -- sounds like slice should NOT throw an INDEX_SIZE_ERR at all, and only clamp on size? / Jonas Current editor's draft: http://dev.w3.org/2006/webapi/FileAPI/ [1] http://www.w3.org/TR/XMLHttpRequest2/#loadend-event [2] http://dev.w3.org/cvsweb/html5/spec/Overview.html?r1=1.3290r2=1.3291f=h [3] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Re: [FileAPI] Latest Revision of Editor's Draft
On Tue, Oct 27, 2009 at 12:36 AM, Ian Hickson i...@hixie.ch wrote: 3. The event model resembles that of XHR2, with a few differences. Notably, the APIs differ in their use of the 'loadend' ProgressEvent. I think this spec needs examples. I think the examples would show that the current design requires far too many lines of code to do something that really should only need one or two statements. (I think XHR is a very poor model to follow.) I was as surprised as you, but the feedback we consistently received, both here and when talking directly to developers, was that using an events-based model was preferable to using callbacks. We also received the feedback that following XHR was good because authors were used to this model. I agree that especially the common simple use case results in more lines of code, but it doesn't need to be as complicated as the example in the beginning of the spec: r = new FileReader; r.readAsText(file); r.onload = fileIsRead; 4. A suggestion to *not* have a separate scheme (filedata:) in lieu of urn:uuid:uuid[2] has been the basis of a rewrite of that feature in this version of the specification. I would like to see implementation feedback on this. I don't understand why we would want to assign semantics to urn:uuid: URLs that are so specific -- that seems completely wrong. It also seems really awkward from an implementation perspective to forgo the normal extension mechanism (schemes) and have implementations give special (and non-trivial) semantics to a subset of another scheme. Why are we doing this? I'd like to hear implementation feedback here too. I'm especially worried that implementations might not be able to use the urn scheme due to limitations in the network stacks they are using. But like Arun, I suspect that this feature is the most controversial in the spec. Apple expressed concern about having a string represent a handle to a resource, and when we talked to Microsoft they briefly mentioned that they has concerns about this feature too, though I don't know specifically what their concerns were. I don't think we are assigning specific semantics to another scheme that aren't already there. All we're saying is that urn:uuid represents a specific chunk of data with a specific mimetype. This seems like something that's already there with urn:uuid. Arguably the status codes is something that urn:uuid doesn't already have. Arun mentioned that we could possibly get rid of that. / Jonas
Re: [FileAPI] Latest Revision of Editor's Draft
On Tue, 27 Oct 2009, Jonas Sicking wrote: All we're saying is that urn:uuid represents a specific chunk of data with a specific mimetype. This seems like something that's already there with urn:uuid. We're also saying that urn:uuid: has special semantics in the same-origin model, and that it has an expiration model. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [FileAPI] Latest Revision of Editor's Draft
On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 27 Oct 2009, Jonas Sicking wrote: All we're saying is that urn:uuid represents a specific chunk of data with a specific mimetype. This seems like something that's already there with urn:uuid. We're also saying that urn:uuid: has special semantics in the same-origin model, and that it has an expiration model. The expiration model is just that when the Document goes away the urn:uuid is changed to no longer represent that chunk of data. The origin is something that at least in gecko we build on top of the URI, i.e. the URI itself doesn't contain any origin information. If you consider it to be part of the URI, then why wouldn't each urn:uuids already have an origin? / Jonas
Re: [FileAPI] Latest Revision of Editor's Draft
On Tue, 27 Oct 2009, Jonas Sicking wrote: On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 27 Oct 2009, Jonas Sicking wrote: All we're saying is that urn:uuid represents a specific chunk of data with a specific mimetype. This seems like something that's already there with urn:uuid. We're also saying that urn:uuid: has special semantics in the same-origin model, and that it has an expiration model. The expiration model is just that when the Document goes away the urn:uuid is changed to no longer represent that chunk of data. The origin is something that at least in gecko we build on top of the URI, i.e. the URI itself doesn't contain any origin information. If you consider it to be part of the URI, then why wouldn't each urn:uuids already have an origin? I just mean that if someone else decides that they are going to resolve urn:uuid:s in some way or other, the origin model they would use will almost certainly be quite different to the origin model we are using here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [FileAPI] Latest Revision of Editor's Draft
On Tue, Oct 27, 2009 at 3:26 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 27 Oct 2009, Jonas Sicking wrote: On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 27 Oct 2009, Jonas Sicking wrote: All we're saying is that urn:uuid represents a specific chunk of data with a specific mimetype. This seems like something that's already there with urn:uuid. We're also saying that urn:uuid: has special semantics in the same-origin model, and that it has an expiration model. The expiration model is just that when the Document goes away the urn:uuid is changed to no longer represent that chunk of data. The origin is something that at least in gecko we build on top of the URI, i.e. the URI itself doesn't contain any origin information. If you consider it to be part of the URI, then why wouldn't each urn:uuids already have an origin? I just mean that if someone else decides that they are going to resolve urn:uuid:s in some way or other, the origin model they would use will almost certainly be quite different to the origin model we are using here. This doesn't seem to be a problem as long as the two specs don't mandate the exact same uuids. But again, I'd like feedback from other implementations with different network stacks. / Jonas
Re: [FileAPI] Latest Revision of Editor's Draft
Ian Hickson wrote: On Tue, 27 Oct 2009, Jonas Sicking wrote: On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 27 Oct 2009, Jonas Sicking wrote: All we're saying is that urn:uuid represents a specific chunk of data with a specific mimetype. This seems like something that's already there with urn:uuid. We're also saying that urn:uuid: has special semantics in the same-origin model, and that it has an expiration model. The expiration model is just that when the Document goes away the urn:uuid is changed to no longer represent that chunk of data. The origin is something that at least in gecko we build on top of the URI, i.e. the URI itself doesn't contain any origin information. If you consider it to be part of the URI, then why wouldn't each urn:uuids already have an origin? I just mean that if someone else decides that they are going to resolve urn:uuid:s in some way or other, the origin model they would use will almost certainly be quite different to the origin model we are using here. Yes; that is true, and is a concern. However, my reading of: http://www.ietf.org/rfc/rfc4122 (which describes urn:uuid) suggest that namespace resolution for UUIDs, coupled with general stipulations for namespace resolution, make this a manageable problem. From RFC4122, Section 3: Process for identifier resolution: Since UUIDs are not globally resolvable, this is not applicable. Moreover, in http://www.ietf.org/rfc/rfc2141.txt (which describes URN syntax), we find that: ... Namespace registration must include guidance on how to determine functional equivalence for that namespace, i.e. when two URNs are identical within a namespace. We're unlikely to have *identical URNs* in the uuid namespace. One reason I chose UUID is because the identical URN problem is unlikely. That leaves the problem of persistence (which is also a stipulation on URNs) but I think that we are entitled to define persistence in terms of the Document's persistence. I'd like to hear from implementors, and of course those that disagree with my reading of these specifications. I'm amenable to dropping the HTTP responses if that helps. -- A*
FW: Feedback on the Strict-Transport-Security specification
Forwarding at the request of the STS-draft authors. From: Eric Lawrence Sent: Friday, October 09, 2009 11:42 AM To: 'Steingruebl, Andy'; 'a...@adambarth.com' Cc: Hodges, Jeff; 'Collin Jackson' Subject: RE: Strict-Transport-Security specification Hey, guys! You both asked me for feedback on the STS spec a while ago and I've finally managed to dig out enough to provide some feedback. I'm excited to see the progress here, and most of the issues I've noted are quite minor. I am a bit concerned that the spec doesn't mandate behavior for mixed-content; I know such requirements would be controversial and non-trivial, but without the behavior being mandated by the spec, I think we're likely to see divergent and incompatible behavior on STS sites. Thanks, Eric Hopefully this is still the latest draft? http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html Editorial issues [Section: Abstract] defines a mechanism to enabling Web sites [Section 1: Introduction] I've never seen a spec use the word annunciate before. Any reason not to prefer announce or display? [Section 1: Introduction] or if a server's domain namehttp://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html#domain-name appears incorrectly. Isn't the problem here typically that the domain name does not appear at all? [Section 1 : Introduction] a HTTP request header field is used to convey site policy to the UA. This specification proposes a HTTP response header, not a request header. [Section 2.2: Policy Summary] terminates, without user recourse, any secure transport connection attempts upon any and all errors. I'm not convinced that any and all is the right way to go here. Shouldn't this spec call out each certificate and certificate chain error? Otherwise, should I consider the failure in a different protocol level (e.g. gateway or DNS hiccup) as a fatal error? [Section 2.4.2: Detailed Core Requirements]: 4.UAs need to re-write all insecure UA http URI loads to use the https secure scheme for those web sites for which secure policy is enabled. This requirement is insufficiently specific and does not really explain what rewrite means? Does this mean that the HTML parser will detect any insecure-but-should-be URIs and rewrite them within the markup, such that JavaScript could observe the change in the HREF attribute? Or does it simply mean that upon de-reference the URI is automatically upgraded to HTTPS with no notice to the caller? [Section 2.4.2: Detailed Core Requirements]: Requirements #5 and #6 are problematic because browsers (generally speaking) often don't have rock solid knowledge of where the proper private domain / public suffix transitionhttp://blogs.msdn.com/ieinternals/archive/2009/09/19/Private-Domain-Names-and-Public-Suffixes-in-Internet-Explorer.aspx occurs. [Section 4: Terminology] The production of the Effective Request URI omits the protocol scheme. I assume this was inadvertent and that the protocol scheme was meant to be included. [Section 5.1: Syntax] The spec should probably specify whether the delta-seconds value expected to be adjusted by the HTTP Age response header, if present. [Section 5.1: Syntax] Are the tokens intended to be interpreted case-sensitively? [Section 5.1: Syntax] What should be done if the server has multiple Strict-Transport-Security response header fields of different values? [Section 5.1 Syntax] Typo: Strict-Transport-Sec HTTP Response Header [Section 6.1: HTTP-over-Secure-Transport Request Type] Why must the server include this header on every response? This seems likely to prove prohibitively difficult across, say, Akamai load balancers for images, etc. What happens if the server fails to include the response header on a given response? [Section 6.2] I'm not sure why the spec contains the confusing terminology HTTP-over-Secure-Transport whilst simultaneously demanding that various URLs be converted to specifically HTTPS, which would preclude the flexibility allowed by the more awkward terminology? [Section 6.2] A STS Server must not include the Strict-Transport-Security HTTP Response Header in HTTP responses conveyed over a non-secure transport. Why not? It seems harmless to include if the UA doesn't respect it. [Section 7.1] What if the STS response header is present but contains no tokens? 7.1 suggests that the header alone indicates an STS server. [Section 7.1.1; Design Decision #4] I know there are reasons to avoid using secure protocols to IP-literal addressed servers, but in Intranet environments this may be expected and desirable. Why forbid it here? [Section 7.1.2] While I understand the restrictions imposed here, it is something of a shortfall that https://www.example.com cannot enforce STS for requests to http://example.com. The threat here is obvious: the user typically visits
Re: [widgets] Comments on LCWD #3
Hi Marcos, Marcos Caceres a écrit : Hi Cyril, Thank you for again taking the the time to review the PC spec... comments below. 2009/10/25 Cyril Concolato cyril.concol...@enst.fr: Dear all, I made a review of the current specification [1] and I have some comments. I realize that I'm sending these comments quite late in the process but I couldn't make an earlier review. The purpose of these comments is not to delay the publication of the specification. The purpose is more to understand the rationale behind the technical choices that have been made and to facilitate implementation. Here are my comments: 1. The handling of localization is different between the icon element and the content element. The icon element does allow element-based localization using the xml:lang attribute and it also allows folder based localization, while the content element only allows folder-based localization. Is it an error or can you give the rationale? Removed xml:lang support (we actually did this a while ago, but in the test suite version of the spec - this will be in the new LCWD to be published tomorrow): http://dev.w3.org/2006/waf/widgets/Overview_TSE.html I don't understand what you mean. The discrepancy between the two elements is still there in this version. Is your plan to remove also xml:lang on the icon element and rely on folder-based localization? 2. The use of media types. 2.a The content element defines a type attribute. Why doesn't the icon element do the same? Yes, it probably should. No one requested this feature and [SNIFF] (see spec for link) covers most of the use cases. Yes, I think it should, relying on sniffing does not seem to me to be a good practice. 2.b Why is section 9.1.10 Rule for Identifying the Media Type of a File needed? This seems akward to do type sniffing. Why not using a media type given in the configuration file? Because content's @type is an optional attribute, hence you need sniffing. There is no other way to determine the type. That's exactly my question. Why @type is not mandatory ? 2.c From 7.11.2, it seems that there can be several icon elements (zero or more) differing by their media types (SVG, PNG ...). Why is this not allowed for the content element (zero or one), e.g. HTML, SVG ...? Please explain the use cases you have in mind (this is on the V2 roadmap, btw - but would like to hear what ideas you have). I'm thinking about widget packages which can contain multiple representation of the widgets in different formats (HTML, SVG or proprietary) so that a User Agent which does not support one of the format, e.g. HTML, can use an alternative, e.g. SVG. 3. Unpackaged widgets. Have you envisaged delivery of unpackaged widgets? Is it in the roadmap of the group? If I understand what you mean, this is already supported: Google for Apache Wookie project and Opera Unite. Another interpretation of the above is: http://some.place/widget.wgt!/some/data That is, accessing stuff in a package as as if it was a resource via a URI (like its done with Jar files). I personally don't think this is good use case for widgets. If they are on a server, then they should just be served as resources. Anyway, I'll let you tell us what you mean. I meant that widgets may not be delivered in a package but as separate individual resources. This would imply changes to the current spec because for instance one cannot do localization by checking each locale subfolders but one can use e.g. HTTP headers. For example, have you envisaged registering a media type for the XML configuration file? No, not yet. However, I don't think it's necessary as it can just be served as application/xml and semantics acted upon from interpreting the namespace. I see but I was mentionning it in the context of unpackaged delivery, ie. you need to identify that you're downloading a widget so the mime type could be useful. Best regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: FW: Feedback on the Strict-Transport-Security specification
Thanks for your feedback. Comments inline. (I've skipped the editorial comments.) On Tue, Oct 27, 2009 at 5:01 PM, Eric Lawrence eric...@exchange.microsoft.com wrote: I am a bit concerned that the spec doesn’t mandate behavior for mixed-content; I know such requirements would be controversial and non-trivial, but without the behavior being mandated by the spec, I think we’re likely to see divergent and incompatible behavior on STS sites. There's a tension about what to put in STS and what is more appropriate for a more general policy delivery mechanism, like Content-Security-Policies https://wiki.mozilla.org/Security/CSP. The main reason not to include STS in CSP that the browser needs to know the STS policy before it receives the CSP header because the browser needs to hand errors during the SSL / TLS handshake. In the case of mixed content, we can wait until we receive an HTTP header, so we don't need to play tricks with time scoping (i.e., Max-Age) or URL scoping (i.e., includeSubDomains). I'd like to see browser vendors expose policy levers for controlling mixed content, but I'm not sure whether STS or CSP is a better home for that directive. Hopefully this is still the latest draft? http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html I believe it is. [Section 2.4.2: Detailed Core Requirements]: 4.UAs need to re-write all insecure UA http URI loads to use the https secure scheme for those web sites for which secure policy is enabled. This requirement is insufficiently specific and does not really explain what “rewrite” means? Does this mean that the HTML parser will detect any insecure-but-should-be URIs and rewrite them within the markup, such that JavaScript could observe the change in the HREF attribute? This is how our original prototype worked, but I don't think that's how the real implementations should work. Or does it simply mean that upon de-reference the URI is automatically “upgraded” to HTTPS with no notice to the caller? What I'd recommend here is to treat the HTTP-to-HTTPS rewrite as a simulated 307 redirect, like the one the site is supposed to provide if we actually retrieved the HTTP URL. [Section 2.4.2: Detailed Core Requirements]: Requirements #5 and #6 are problematic because browsers (generally speaking) often don’t have rock solid knowledge of where the proper “private domain” / “public suffix” transition occurs. I think there might be some confusion about what higher-level means in this context. The intent is that: 1) both example.com and foo.example.com could set policy for bar.foo.example.com. 2) Neither bar.foo.example.com nor foo.example.com could set policy for example.com. 3) bar.foo.example.com cannot set policy for foo.example.com. 4) foo.example.com cannot set policy for qux.example.com. etc. I don't think we need a notion of a public suffix to enforce these rules. [Section 5.1: Syntax] Are the tokens intended to be interpreted case-sensitively? Yes. I think this is implied but the grammar style Jeff using, but it might be worth noting for us non-ABNF experts. [Section 5.1: Syntax] What should be done if the server has multiple Strict-Transport-Security response header fields of different values? My opinion is we should honor the most recently received header, both within a request and between requests. [Section 6.1: HTTP-over-Secure-Transport Request Type] Why must the server include this header on every response? This seems likely to prove prohibitively difficult across, say, Akamai load balancers for images, etc. What happens if the server fails to include the response header on a given response? I think that's a server conformance requirement. The UA conformance requirements are set up so that this doesn't matter too much. As long as you get your entry in the STS cache, you'll be fine. [Section 6.2] A STS Server must not include the Strict-Transport-Security HTTP Response Header in HTTP responses conveyed over a non-secure transport. Why not? It seems harmless to include if the UA doesn’t respect it. Again, this is a server conformance requirement that doesn't affect UAs. It doesn't make sense to send the header here. We might as well prohibit servers from sending it. [Section 7.1] What if the STS response header is present but contains no tokens? 7.1 suggests that the header alone indicates an STS server. That sounds like a bug. An empty header should be a no-op. [Section 7.1.1; Design Decision #4] I know there are reasons to avoid using secure protocols to IP-literal addressed servers, but in Intranet environments this may be expected and desirable. Why forbid it here? I don't think there's any way to provide security in this case. My understanding is that anyone can get these certificates. Is there some benefit to supporting these cases? Maybe CAs might change their policies in the future? [Section 7.1.2] While I
RE: TPAC agenda - APIs
Hi Charles, I have an agenda item for the AOB section or wherever it can fit. I will be spending most of the time with DAP and part with Webapps (Widgets), but will try to balance the agendas to be in the APIs meeting as much as possible. The basic question I have is what is the relationship of the following specs to the HTML5 package (being normatively referenced by HTML5). Is it expected that they will reach LCWD stage along with HTML5? - Cross-Origin Resource Sharing (CORS) - Server-Sent Events - Web Sockets - Web Workers These are not normatively referenced by HTML5: - Web Database - WebSimpleDB API There does not seem to be a lot of discussion on some of these specs, although there are periodic updates. Is there expected to be a period of more active group discussion prior to LCWD for those that have been moving along more quietly? I have some specific questions on the specs, that I will send in separate emails. It would be helpful to be able to discuss some of these points in a F2F setting, at least any significant ones that can't be resolved by email in advance. Best regards, Bryan Sullivan | ATT -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Charles McCathieNevile Sent: Tuesday, October 27, 2009 4:09 AM To: WebApps WG Subject: TPAC agenda - APIs Hi folks, there is a proposed timeline at http://www.w3.org/2008/webapps/wiki/TPAC2009APIs#Agenda_Items Please have a look, and if you think your input is important for any session but you will be in a different session, or only participating remotely, please let us know ASAP so we can attempt to make necessary arrangements (dial-up might be hard, but we can move the sessions that are not joint sessions). Note that some sessions have fairly small things in them. It would be nice to have some more free time, although we will probably manage to soak it up with discussion of other issues. 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
