[Widgets] Requirements LC Comment Tracker
Mike(tm) Smith has set up a Last Call comments tracker for the Widgets 1.0: Requirements document: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-reqs-20080625 All comments will be tracked through there. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Agenda and logistics...
On Tue, 24 Jun 2008 20:16:46 +0200, Arun Ranganathan [EMAIL PROTECTED] wrote: chaals et al., Yep. I am waiting for people to comment on whether they are happy to roll up about 11 on Tuesday I am happy enough with an 11a.m. start time; I suspect, however, that our discussions will run over a bit, and thus, I think we ought to be prepared for that. I believe that we have a stop time imposed by the venue. And on Thursday, by a couple of people leaving at lunchtime and one not being there at all. 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 9.5: http://snapshot.opera.com
RE: Need PDF of MS' input [Was Re: Seeking earlier feedback from MS]
I want to re-emphasize that XDR is targeting cross-domain access of public data only. One can already access those public data on the server anonymously. XDR allows this to be done from within the browser rather than through server side proxy or custom applications. The custom header is simply additional measure to allow server explicitly opt-in. CS-XHR, on the other hand, appears to be trying to handle cross-domain access of private data. I don't know if the private data is meant to be something similar to personal photo album or someone's private bank account information. I would assume they have different security requirements. I don't have a clear picture how banks can utilize CS-XHR to handle their private data. Trying to provide a general solution here is bound to have a lot of pitfalls. I know this may sound a bit vague and doesn't address the questions below. But this is a long conversion and I am not sure if we can sort out all without face to face discussions. So I wanted to get the meta points across and this may be of interest. Thanks! Zhenbin -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Monday, June 16, 2008 10:00 PM To: Sunava Dutta Cc: Arthur Barstow; Marc Silbey; public-webapps; Eric Lawrence; Chris Wilson; David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu; Michael Champion Subject: Re: Need PDF of MS' input [Was Re: Seeking earlier feedback from MS] Hi Sunava et Al, Thanks for the feedback! This is a great start for a discussion. I hope we can get to more concrete discussions about the various issues that microsoft is seeing and try to figure out ways to address them. There is a lot of experience at microsoft on these issues, especially as first deployers of the XMLHttpRequest API, so I'm greatly looking forward to using that experience to improve the Access-Control spec. Hopefully we can get to those meaty parts in this discussion that is following from your mail. I'll start with a mini FAQ to avoid repeating myself below: Why is the PEP in the client rather than the server? In order to protect legacy servers some of the enforcement will have to live in the client. We can't expect existing legacy servers to all of a sudden enforce something that they haven't before. In fact, even XDR using client side PEP. It's the client that looks for the XDomainRequest header and denies the webpage access to the data if the header is not there. In fact, Access-Control does allow full PEP on the server if it so chooses by providing an Origin header. Is Access-Control designed with Security by design Yes. In many ways. For example Access-Control does not allow any requests to be sent to the server that aren't already possible today, unless the server explicitly asks to receive them. Additionally Access-Control sets up a safe way to transfer private data. This prevents sites from having to invent their own which risks them inventing something less safe. Thirdly, Access-Control integrates well with the existing HTTP architecture of the web by supporting REST apis and the Content-Type header. This allows existing security infrastructure to inspect and understand Access-Control requests properly. What about DNS rebinding attacks. Even with DNS rebinding attacks Access-Control is designed not to allow any requests which are not possible already in todays web platform as implemented in all major browsers. Especially the last point is something that seems to have been misunderstood at microsoft. It is not the case that DNS rebinding attacks affect Access-Control any different than it affects the rest of the web platform. Any server that wants to protect itself against DNS rebinding attacks in the current web platform will automatically get protected against Access-Control. And any site that does not protect itself is already vulnerable to the exact same attacks with Access-Control as it is on the current web platform. In fact, Access-Control is less vulnerable than XMLHttpRequest on its own is. So a server doesn't need to deploy anything extra to defend itself against Access-Control. Section 4: Secure Design Principles Why Secure Design Principles Are Important__ */Secure by design/*/, in /software engineering http://en.wikipedia.org/wiki/Software_engineering/, means that the software has been designed from the ground up to be secure. Malicious practices are assumed, and care is taken to minimize impact when a security vulnerability is discovered. For instance, when dealing with /user http://en.wikipedia.org/wiki/User_%28computing%29/ input, when the user has to type his or her name, and that name is then used elsewhere in the /program http://en.wikipedia.org/wiki/Computer_program/, care must be taken that when a user enters a blank name, the program does not break. -
Re: Call for Review: Last Call WD of Widgets 1.0 Requirements
Marcos Caceres wrote: What version of X.509 are you referencing? v3, v4? I've updated the references to version 3, using the following citation: ITU-T Recommendation X.509 version 3 (1997). Information Technology - Open Systems Interconnection - The Directory Authentication Framework ISO/IEC 9594-8:1997. However, do you think we should be referencing version 4? has there been much uptake of v4? Not sure, but I would be more inclined to reference RFC 5280: http://www.ietf.org/rfc/rfc5280.txt --Sean
Re: [XHR] Last Call comment on about dependencies
Hi Anne, Thanks for your reply. (We are assuming that this is not a formal reply from the webapps WG.) The XHTML 2 working group discussed the XHR draft at a recent teleconference, and I was asked to send in a brief comment. Basically, the XHTML 2 Working Group is concerned that the draft appears to have a dependency on HTML5. On closer inspection, it is not clear whether this dependency is completely necessary. Further, linking the spec to HTML5 will delay its deployment and incorporation into other languages that have a vested interest in portable scripting (e.g. XHTML 1, XHTML 2, XForms). The concepts defined in HTML5 are important for getting interoperable implementations of XMLHttpRequest. I don't think deployment is necessarily an issue as XMLHttpRequest is already deployed. Now we just need to make sure the various user agents get in line with respect to the behavior they each have. It's not entirely clear to me why XMLHttpRequest needs to be incorperated into a language. In fact, it was incorperated in HTML5 at some point and we splitted it out. (Given the amount of work this cost me I'm still not sure whether it was worth the cost, but it has been an interesting exercise nonetheless.) Finally, it appears that the dependecy is slightly backwards, since the requirement is that HTML5's document Window object support the XMLHttpRequest interface. Actually, no. The requirement is that objects implementing the HTML5 Window _interface_ also support the XMLHttpRequest constructor. Furthermore, the definition of HTML5 Window is important here in case of URI resolution in cross-frame scenarios. Also, that is not the sole dependency the XMLHttpRequest specification has on HTML5. Our request is that this dependency be removed (or that the connection be made informative instead of normative) so that all interested constituents can take advantage of this important interface as soon as possible. I don't think this is possible. Feel free to go through the public-webapi mailing list archives to find more detailed discussion on this subject if you feel the above is not sufficient: There seem to be several options: 1. XMLHttpRequest is irrevocably bound to HTML5. If that is the case then there seems to be no reason to develop this spec outside of the HTML5 WG, or indeed for developing as a separate spec. 2. XMLHttpRequest is host neutral, and therefore can be used in different environments. If that is the case, and it would seem preferable since there are several other technologies that are able to use this, then it seems good to make it as widely adoptable as possible. It seems like there are two ways to do this: a. copy the restrictions due to HTML5 into this document, so that it is free-standing b. remove the restrictions due to HTML5, and ensure that they are added to that spec, and let languages that use it specify the necessary restrictions needed to make it work in that environment. Which of these do you think best apply to XMLHttpRequest? There seem to be several technologies in W3C that could use XMLHttpRequest; SMIL and XForms come readily to mind. Would you be able to enumerate what it is in XMLHttpRequest that is so bound to HTML5? Thanks! Best wishes, Steven Pemberton
Reminder: DOM3 Events Telcon Cancelled, Resumes in 2 Weeks
Hi WebApps Fans- Because of a number of regrets, today's DOM3 Events telcon has been cancelled. We will also not meet next week, due to the F2F. We will resume telcons in 2 weeks, on July 9. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Re: Possible test for DOM Events
Hi, perhaps the test style could be something like in the attached file, in which I modified your original test a bit. The idea is that vendor could provide vendor_functions.js which defines functions to integrate test to vendor's own test system. -Olli Carmelo Montanez wrote: Hi: Given that I am still unable to use the wiki to upload a file, I am attaching possible test for the DOM API Test Suite as per my Action Item last week. I am off from the office for the next two weeks. Thanks, Carmelo Title: DOM Events API Test Suite - mouseover-002 move the mouse over the elements below Row 1, Cell 1Row 1, Cell 2 Row 2, Cell 1Row 2, Cell 2 Row 3, Cell 1Row 3, Cell 2 Row 4, Cell 1Row 4, Cell 2 Row 5, Cell 1Row 5, Cell 2
Worker Threads and Site Security Policy | Two Possible New Items for Standardization
Doug Schepers, Charles McCathieNevile (Chairs), Members of the WG, On behalf of Mozilla, I'd like to introduce the possibility of two new work items for this group to consider. Neither of these is presented as a fait accompli, although we would like to consider both of these for inclusion in Firefox 3.Next if that is possible. 1. Worker Threads in Script. The idea is to offer developers the ability to spawn threads from within web content, as well as cross-thread communication mechanisms such as postMessage. Mozilla presents preliminary thought on the subject [1], and notes similar straw persons proposed by WHATWG [2] and by Google Gears [3]. Also for reference see worker threads in C# [4]. The Web Apps working group seems like a logical home for this work. Will other members of the WG engage with Mozilla on this, via additional work items covered by the charter of this WG? 2. Mitigation of XSS (Cross Site Scripting) and CSRF (Cross Site Request Forgery) Vulnerabilities. The idea is to provide a mechanism (possibly via HTTP headers, but not necessarily limited to HTTP headers) to stipulate a *strict* mode for script inclusion via script src= and prevention of inline scripts altogether. See Site Security Policy [5]. We encourage discussion about this topic via email. Will other members of the WG engage with Mozilla on this, via additional work items covered by the charter of this WG? -- A* [1] http://wiki.mozilla.org/DOMWorkerThreads [2] http://hixie.ch/specs/dom/workers/0.9 [3] http://code.google.com/apis/gears/api_workerpool.html [4] http://msdn.microsoft.com/en-us/library/5xt1dysy.aspx [5] http://people.mozilla.com/~bsterne/site-security-policy/
Re: Worker Threads and Site Security Policy | Two Possible New Items for Standardization
On Wed, Jun 25, 2008 at 1:09 PM, Arun Ranganathan [EMAIL PROTECTED] wrote: 1. Worker Threads in Script. The idea is to offer developers the ability to spawn threads from within web content, as well as cross-thread communication mechanisms such as postMessage. Mozilla presents preliminary thought on the subject [1], and notes similar straw persons proposed by WHATWG [2] and by Google Gears [3]. Also for reference see worker threads in C# [4]. The Web Apps working group seems like a logical home for this work. Will other members of the WG engage with Mozilla on this, via additional work items covered by the charter of this WG? Sounds good to Gears. We'd be interested in participating in this. - a
Re: Worker Threads and Site Security Policy | Two Possible New Items for Standardization
On Jun 25, 2008, at 1:09 PM, Arun Ranganathan wrote: Doug Schepers, Charles McCathieNevile (Chairs), Members of the WG, On behalf of Mozilla, I'd like to introduce the possibility of two new work items for this group to consider. Neither of these is presented as a fait accompli, although we would like to consider both of these for inclusion in Firefox 3.Next if that is possible. 1. Worker Threads in Script. The idea is to offer developers the ability to spawn threads from within web content, as well as cross- thread communication mechanisms such as postMessage. Mozilla presents preliminary thought on the subject [1], and notes similar straw persons proposed by WHATWG [2] and by Google Gears [3]. Also for reference see worker threads in C# [4]. The Web Apps working group seems like a logical home for this work. Will other members of the WG engage with Mozilla on this, via additional work items covered by the charter of this WG? Apple is interested in a worker API. The key issues for workers, in my opinion, are security, messaging, and which of the normal APIs are available. Right now, these things are covered in HTML5, so I think that may be a better place to add a Worker API. We would certainly like to coordinate our work in this area with the proposed APIs cited. 2. Mitigation of XSS (Cross Site Scripting) and CSRF (Cross Site Request Forgery) Vulnerabilities. The idea is to provide a mechanism (possibly via HTTP headers, but not necessarily limited to HTTP headers) to stipulate a *strict* mode for script inclusion via script src= and prevention of inline scripts altogether. See Site Security Policy [5]. We encourage discussion about this topic via email. Will other members of the WG engage with Mozilla on this, via additional work items covered by the charter of this WG? This one looks complicated and I'll need some time to review to form an opinion. Some critical details seem to be missing from the proposal, for example, one of the mechanisms calls for a preflight policy check request but it is not described how to do this request. Regards, Maciej
Re: Worker Threads and Site Security Policy | Two Possible New Items for Standardization
Maciej, 1. Worker Threads in Script. Apple is interested in a worker API. The key issues for workers, in my opinion, are security, messaging, and which of the normal APIs are available. Right now, these things are covered in HTML5, so I think that may be a better place to add a Worker API. We would certainly like to coordinate our work in this area with the proposed APIs cited. Fair observation. I'll wait to hear from other parties (particularly the other user-agent companies) about where this ought to live. I note from a previous thread[1] that the presumption of a dependency on HTML5 has proven problematic to other WGs, which could sell your point about moving this to HTML5. My preference is to have it here since it is a Web API and thus should be treated as a modular piece of the ecosystem. 2. Mitigation of XSS (Cross Site Scripting) and CSRF (Cross Site Request Forgery) Vulnerabilities. The idea is to provide a mechanism (possibly via HTTP headers, but not necessarily limited to HTTP headers) to stipulate a *strict* mode for script inclusion via script src= and prevention of inline scripts altogether. See Site Security Policy [5]. We encourage discussion about this topic via email. Will other members of the WG engage with Mozilla on this, via additional work items covered by the charter of this WG? This one looks complicated and I'll need some time to review to form an opinion. Some critical details seem to be missing from the proposal, for example, one of the mechanisms calls for a preflight policy check request but it is not described how to do this request. Fair observation, though note (as I said before) that this is far from a fait accompli. The uber idea is to induce a stricter script inclusion/inline script mechanism in user agents. Should that idea have currency with Apple, we'd be very interested in working with you (as we are with others) in sorting out the details. Going forward, it might be wise to snap these two out of one email thread, but I'll wait on responses. -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0413.html
Re: Worker Threads and Site Security Policy | Two Possible New Items for Standardization
On Wed, 25 Jun 2008, Arun Ranganathan wrote: 1. Worker Threads in Script. The idea is to offer developers the ability to spawn threads from within web content, as well as cross-thread communication mechanisms such as postMessage. Mozilla presents preliminary thought on the subject [1], and notes similar straw persons proposed by WHATWG [2] and by Google Gears [3]. Also for reference see worker threads in C# [4]. The Web Apps working group seems like a logical home for this work. Will other members of the WG engage with Mozilla on this, via additional work items covered by the charter of this WG? I'd be happy to volunteer to edit a specification for worker threads, whether this ends up as a separate spec in Web Apps or as an HTML5 chapter. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Worker Threads and Site Security Policy | Two Possible New Items for Standardization
Maciej Stachowiak wrote: On Jun 25, 2008, at 1:09 PM, Arun Ranganathan wrote: Doug Schepers, Charles McCathieNevile (Chairs), Members of the WG, On behalf of Mozilla, I'd like to introduce the possibility of two new work items for this group to consider. Neither of these is presented as a fait accompli, although we would like to consider both of these for inclusion in Firefox 3.Next if that is possible. 1. Worker Threads in Script. The idea is to offer developers the ability to spawn threads from within web content, as well as cross-thread communication mechanisms such as postMessage. Mozilla presents preliminary thought on the subject [1], and notes similar straw persons proposed by WHATWG [2] and by Google Gears [3]. Also for reference see worker threads in C# [4]. The Web Apps working group seems like a logical home for this work. Will other members of the WG engage with Mozilla on this, via additional work items covered by the charter of this WG? Apple is interested in a worker API. The key issues for workers, in my opinion, are security, messaging, and which of the normal APIs are available. Right now, these things are covered in HTML5, so I think that may be a better place to add a Worker API. We would certainly like to coordinate our work in this area with the proposed APIs cited. I'd really rather not add more stuff to HTML5, it's too big as it is. Ideally worker threads is something that we can nail down in a pretty short period of time, before HTML5 is out (targeted a few years into the future iirc). Like you say, some features from HTML5 should be exposed in the context of worker threads. I don't really know how to handle that, but I can see two ways: 1. Make a informative note stating a list of features that we expect will be made available once there is a finished spec for them, but leave it up to the HTML5 spec to actually explicitly make this requirement. 2. Have a normative requirement that implementations that also support feature X from HTML5, makes that implementation available to the worker thread as well. / Jonas
RE: Worker Threads and Site Security Policy | Two Possible New Items for Standardization
On Jun 25, 2008, at 1:09 PM, Arun Ranganathan wrote: Mozilla presents preliminary thought on the subject [1], and notes similar straw persons proposed by WHATWG [2] and by Google Gears [3]. Also for reference see worker threads in C# [4]. The Web Apps working group seems like a logical home for this work. Will other members of the WG engage with Mozilla on this, via additional work items covered by the charter of this WG? [Sunava Dutta] We're still working on getting our membership here together. May we have copies to (I'm assuming what are URLS) for these proposals?
Re: Process Re: Worker Threads and Site Security Policy
On Jun 25, 2008, at 2:54 PM, Charles McCathieNevile wrote: CC trimmed a bit for people I know are in the list without looking. Sadly Microsoft still haven't got around to joining, so it falls on Chris to pass this on until they get to do the legal work. NB: The chairs are actually Art and I - Doug and Mike are the staff contacts. On Wed, 25 Jun 2008 22:48:04 +0200, Arun Ranganathan [EMAIL PROTECTED] wrote: Maciej, 1. Worker Threads in Script. Apple is interested in a worker API. The key issues for workers, in my opinion, are security, messaging, and which of the normal APIs are available. Right now, these things are covered in HTML5, so I think that may be a better place to add a Worker API. ... Fair observation. I'll wait to hear from other parties (particularly the other user-agent companies) about where this ought to live. I note from a previous thread[1] that the presumption of a dependency on HTML5 has proven problematic to other WGs, which could sell your point about moving this to HTML5. My preference is to have it here since it is a Web API and thus should be treated as a modular piece of the ecosystem. I note that in the geolocation discussion Ian has been quite vocal about this being the home for APIs, but in respect to the Window spec he has simply taken it into HTML5, although that won't be stable for many years according to him. So clearly the question of where things live is not always one with an obvious answer. I don't think it is accurate to say that Ian has taken [Window] into HTML5. Here is the history, to the best of my recollection: 1) HTML5 was the first specification ever to define the Window object and related DOM Level 0 features, and it did so before the Web API WG even existed. 2) The Web API WG wanted to split the Window portions of HTML5 into a standalone spec that could be referenced from multiple other specifications. I was the editor for this work, and got pretty far, including a start at a test suite. 3) I didn't have the time to keep up with the spec, and found that some details had very complex interrelationships with other parts of the HTML5 spec. 4) After waiting for some time, Ian continued to maintain the Window- related parts of the HTML5 spec. I still think it would be better overall for Window to be in a separate spec, but the work is more challenging than it may seem. Ian has acted in good faith in this regard, and the reason this effort failed is more my fault than anyone else's. Regards, Maciej
Re: Agenda and logistics...
On Wed, 25 Jun 2008 00:25:56 +0200, Chris Wilson [EMAIL PROTECTED] wrote: Charles McCathieNevile wrote: Assuming [Microsoft] have made the patent policy commitment and joined the group by then they are even welcome to take part ;) Just an update - I've filed the paperwork, it's gone through patent review, and it's now in cross-group review for the next two days, after which we just need our VP's signoff. So it should be complete prior to the FTF if not by EOW. Excellent, thanks. 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 9.5: http://snapshot.opera.com
Re: Agenda+ DOM3 Events (was: Agenda and logistics...)
On Wed, 25 Jun 2008 05:32:20 +0200, Doug Schepers [EMAIL PROTECTED] wrote: At the upcoming F2F, I would also like to spend an hour or two discussing DOM3 Events, if we find the time and have the right people. I don't care what day this happens on. Hmm. Given that we announced quite a while ago that this would be a meeting about XHR/XHR2 and AC4CSR, I don't mind you taking advantage of the fact that people are around to have an informal chat, or even give a brief update to the rest of the group, but I am reluctant to try and use the time to grapple issues with most people only learning this close to the meeting that it would even hit the agenda. We can schedule more meetings (we already have one scheduled for the W3C TPAC, in mid october, and can add this to the agenda for that meeting)... 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 9.5: http://snapshot.opera.com
Re: Call for Review: Last Call WD of Widgets 1.0 Requirements
Hi Sean, On Wed, Jun 25, 2008 at 11:37 PM, Sean Mullan [EMAIL PROTECTED] wrote: Marcos Caceres wrote: However, do you think we should be referencing version 4? has there been much uptake of v4? Not sure, but I would be more inclined to reference RFC 5280: http://www.ietf.org/rfc/rfc5280.txt Ok, I've updated the reference. It now reads: [X.509v3] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, S. Santesson, S. Boeyen, R. Housley, and W. Polk. May 2008. RFC5280 is available at http://www.ietf.org/rfc/rfc5280.txt For our record keeping of LC comments, could you please confirm that the Working Group has addressed your comments. Thank you again for taking the time to do the review. -- Marcos Caceres http://datadriven.com.au
Re: F2F Agenda Updated
Doug Schepers wrote: Hi, WebApps WG- The WebApps F2F meeting page has been updated to reflect the current agenda: http://www.w3.org/2008/webapps/Group/f2f0807.html (member-only) I do notice that some of the times are in what you americans call 'military time', and some times are in am/pm time, but lacking the actual am/pm notations. / Jonas
Re: F2F Agenda Updated
Hi, Jonas- Jonas Sicking wrote (on 6/25/08 8:48 PM): Doug Schepers wrote: Hi, WebApps WG- The WebApps F2F meeting page has been updated to reflect the current agenda: http://www.w3.org/2008/webapps/Group/f2f0807.html (member-only) I do notice that some of the times are in what you americans call 'military time', and some times are in am/pm time, but lacking the actual am/pm notations. I can only assume that Chaals intends for us to work all through the night, and to have a break at 3:30 in the morning. Actually, I see quite a few typos... I'll fix those up. Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF
RE: F2F Agenda Updated
Thanks for the update. Just an FYI, I've got ahead and made reservations at Maggianno's for the 2nd at 6.30. (Moved it from the 3rd). -Original Message- From: [EMAIL PROTECTED] [mailto:public-webapps- [EMAIL PROTECTED] On Behalf Of Doug Schepers Sent: Wednesday, June 25, 2008 4:47 PM To: public-webapps@w3.org Subject: F2F Agenda Updated Hi, WebApps WG- The WebApps F2F meeting page has been updated to reflect the current agenda: http://www.w3.org/2008/webapps/Group/f2f0807.html (member-only) Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF
