RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
On Sun, 15 Jun 2008, Zhenbin Xu wrote: Ian wrote: On Wed, 11 Jun 2008, Sunava Dutta wrote: When Parsing Error happens, IE would still retain responseXML and put error information on the object. Isnt this better than null as there�s more relevant information for the web developer? How does one distinguish a document returned with parse error information from one that happens to look like a parse error but was well-formed? I wouldn't mind including more information but it seems like it should be out-of-band. I am not sure if I understand your question. responseXML.parseError has the error information http://msdn.microsoft.com/en-us/library/aa926483.aspx Oh, I assumed Sunava meant a conforming Document object was returned. A parseError-type object would be what I had in mind, yes. However, if we do this, then we should specify it. If we don't specify it, I'd rather have an exception. The test is expecting us to return NULL in case open() has not been called. We throw an exception in IE. I�d pre fer if the spec says �MUST return null OR an exception� otherwise I fear sites today will be broken. If a site is expecting an exception and gets null, then they'll get an exception when they try to dereferene the null, so in most cases it seems like this would work anyway. Properly written sites would have no problem one way or the other. However if someone is writing a wrapper on top of XMLHTTP, clearly it would make a difference on how to expose wrapped properties. Not really; if the script is expecting an exception, and receives null instead, then they'll just get an exception as soon as they dereference the object, which in almost all cases will be straight away. If we are going to spec it to accommodate all existing browsers, we would want to make it return null or INVALID_STATE_ERR exception. We want interoperable behaviour, so defining it in this way would be a bad idea. (I don't really have an opinion either way about exception vs null, but it seems that we should just pick whatever is most commonly implemented, which I'm guessing is what Anne did here.) I think it's important that we test that the DOM returned from XHR is DOM Core conformant just like any other, so this seems like an important and relevant testing area for XHR. That is not necessarily a good idea because you would then have to mandate which level of DOM Core support is required. And if the spec requires DOM level 3, that is big barrier for new user agent that wants to be compliant with XHR spec. getElementById requires DOM Level 2. At the least the testing case can be changed to use getElementByTagName, which is DOM level 1. I think expecting DOM Level 3 is the least of our worries -- after all, that's a 3+ year old spec. So testing just DOM Level 2 is really not a problem as far as I can tell. However, I agree that it would make sense to make the test pass if the UA didn't support that level of DOM on regular DOM objects too. The key is just to make sure that the objects returned by XHR are of equivalent DOM support as the rest of the UA's objects. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Improving Communication and Expectations
On Mon, 16 Jun 2008 07:24:12 +0200, Doug Schepers [EMAIL PROTECTED] wrote: To be fair, I want to note that during this same timeframe, we have been holding regular telcons for DOM3 Events, and that Travis Leithead (also of Microsoft's IE team) has been very helpful and productive, and has fulfilled his actions in a timely and considerate manner. We have had plenty of telcons for Access Control, close to none (if not none) attended by Microsoft: http://www.google.com/search?q=WAF+WG+Access+Control+Voice+Conf -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Improving Communication and Expectations
On Jun 16, 2008, at 1:50 AM, Doug Schepers wrote: Hi, Maciej- You may have misunderstood what I wrote. I did not propose that issues be brought up and solved in a binding manner during a single telcon (though some minor issues may be, in the interest of acting in a suitably-paced manner). As I clearly stated, the issues should be raised, discussed via email and supporting documents, giving everyone a chance to give input... the decision would be done during the telcon after the data has been collected, to draw the issue to a close. I honestly don't see how you could have jumped to your conclusion, unless you didn't read my email. I just assumed that telecons would work as they do in every W3C WG I have seen that makes binding decisions in telecons: 1) I have never seen a W3C Working Group chair take an actual roll call or ask for affirmative support when proposing a resolution in a telecon, just no objections? and a 30 second pause before the resolution is declared to pass. 2) I have rarely seen telecon decisions tabled because it was a new issue without adequate prior discussion. I have often seen an issue discussed for a total of 5-10 minutes (without significant prior email discussion) before a resolution is proposed 3) I have often seen telecon decisions ignore prior email feedback because many people hadn't bothered to read it, or since the person who'd sent the email was not present. If you are instead proposing a new kind of telecon-based binding decision-making that would not have these problems then I'd be interested in hearing more about it. I think the bottom line is that different people have different working styles. Some, like you, appreciate the heartbeat and sense of inclusion of weekly phone meetings. Others, like me, feel uncomfortable trying to make quick judgments on technical issues without adequate time to think about them, and do not find it a good use of time to listen to those who are happy to discuss without studying the matter. That's particularly likely to be true, I think, for those of us who have day jobs working on implementations or other areas of standards, but such people are highly likely to have relevant technical input as well. If binding decisions should be made in telecons, the working group would favor people with your kind of working style over those with my working style. I would strongly prefer if we had a way of making decisions that could be inclusive of both of these working styles. Perhaps this can be achieved with a combination of teleconferences, email discussion of proposals made in telecons, and a decision process where both phone people and email people can participate in a way they find comfortable. Perhaps a roll call voice vote plus web survey would do it. Or maybe just the web survey would do, if telecons remind people to vote. Regards, Maciej
Re: Opting in to cookies - proposal
On Sat, 14 Jun 2008 10:38:44 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: The downsides of inventing a URI scheme include: 1) URIs using this scheme will not parse into components properly (the feed: scheme has this problem) 2) The scheme really should be registered through IANA, which will be a bureaucratic hassle 3) IANA would probably be hesitant, because user-private: does not describe a new resource access method, it just describes what headers you want to send, which in http is separate from the URI 4) It is in fact a valid point that this violates the design of URI schemes 5) Code throughout the system will have to know to special-case this URI scheme to treat it as equivalent to the corresponding HTTP URI I strongly agree that if we do this at all we should not do it through a new URI scheme. If we do this something like Hixie's original proposal makes more sense to me (and maybe allowing it to be influenced by a flag): http://lists.w3.org/Archives/Public/public-appformats/2008May/0007.html -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XHR2 Feedback As Tracker Issues
It would be great if microsoft could do this. Sunava Dutta wrote: I LOVE the idea! -Original Message- From: Doug Schepers [mailto:[EMAIL PROTECTED] Sent: Monday, June 16, 2008 12:39 PM To: Chris Wilson Cc: Ian Hickson; Sunava Dutta; Arthur Barstow; Marc Silbey; public- webapps; Eric Lawrence; David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu; Michael Champion Subject: XHR2 Feedback As Tracker Issues (was: [NOT] Microsoft's feedback on XHR2) Hi, Folks- It might be useful if specific points were raised as issue in the WebApps Tracker [1], rather than just floating around on email (be it PDF, HTML, or plaintext). That way, they could be addressed in a concise and systematic manner. Do people (specifically, the chairs, the editor, and the contributors) think this would be useful? [1] http://www.w3.org/2008/webapps/track/products/4 Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF
Fwd: Registration now open for the Combined Technical Plenary and Advisory Committee Meeting
Sumary: PLease register - http://www.w3.org/2002/09/wbs/35125/TPAC2008/ We have two rooms reserved, so that we can work on stuff in parallel. The full schedule is at http://www.w3.org/2008/10/TPAC/Schedule and they ask you to stay at the hotel at 195€/night (single - double room is 225€/night for those who share). cheers Chaals --- Forwarded message --- From: Alexandra Lavirotte [EMAIL PROTECTED] Dear all, Registration for the October TPAC2008: Combined Technical Plenary and Advisory Committee Meeting is now open at http://www.w3.org/2002/09/wbs/35125/TPAC2008/. Registration will close on 28 September. Participation in the All Group Meetings and Technical Plenary is open to participants in good standing in a W3C Working or Interest Group, Incubator group, Advisory Committee Representatives, the TAG and Advisory Board. Participation in the W3C Advisory Committee Meeting is open to one Advisory Committee Representative per Member Organization, Chairs, the TAG and Advisory Board. The schedule of the All Group Meetings, Advisory Committee Meeting and Technical Plenary is at: http://www.w3.org/2008/10/TPAC/Schedule.html The TPAC2008 will be held at the Pullman Cannes Mandelieu Royal Casino (Formerly Sofitel Cannes Mandelieu Royal Casino), in Mandelieu, France. More information can be found on the Overview page at: http://www.w3.org/2008/10/TPAC/Overview.html A block of rooms has been reserved at the Pullman Cannes Mandelieu Royal Casino. The discounted room rates of 195€ for single room and 225€ for double romm are available from Saturday 18 October to Saturday 25 October 2008: http://www.w3.org/2008/10/TPAC/Overview.html#Hotel -- 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]
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.” – /Secure by Design, Wikipedia http://en.wikipedia.org/wiki/Secure_by_design Secure design principles are key to ensuring that users, whether the end-user or service provider, are protected. The increasingly hostile Web and ever more clever attackers lead to the proliferation of new vectors like XSS and CSRF. In the Web of today, it is critical that solutions be secure-by-design /prior/ to release. This does not guarantee that there will be no exploits; however it does ensure that the bug trail is significantly lower and goes a long way toward protecting the user. For more details on this, please read our MSDN article on The Trustworthy Computing Security Development Life Cycle http://msdn.microsoft.com/en-us/library/ms995349.aspx. This sounds great. We've been using these types of principals when designing Access-Control too. Background of Client Side Cross-Domain Proposals Cross-site XMLHttpRequest is essentially a combination of a cross-domain access mechanism, Access Control http://dev.w3.org/2006/waf/access-control/ (AC), and an object to enable this mechanism, in this case, a versioned XMLHttpRequest object called XMLHttpRequest Level 2 http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ (XHR). This cross-domain implementation will be referred to as CS-XHR. *NOTE: This paper is based on the AC and XHR level 2 draft on 3/June/08.* This is not entirely true. There is nothing that prevents Access-Control from being applied on XMLHttpRequest Level 1. Just as Access-Control can be
