Re: [Element Traversal LC] access to element by index
If we're not 100% compatible with SVG, why would they oppose an improvement like the suggested one? Content that uses childElements[...] would not function correctly in SVG Tiny 1.2 implementations for no particularily good reason. I'm not following this argument at all. Neither would content that uses .globalStorage, .forms, .querySelector or anything else that's not in the SVG Tiny spec. We're trying to make a new API here, of course content that uses that API isn't going to work in implementations that don't support it. / Jonas
Re: [XHR2] onprogress Event issue
Julien Chaffraix wrote: Hi everyone, We are in the process of implementing XHR onprogress attribute on WebKit and arises a compatibility issue with the Firefox implementation. Currently the XHR2 draft specifies that we use the ProgressEvent interface for onprogress events whereas Firefox uses the DocumentLS LSProgressEvent interface. We are left wondering which way to go. Does someone know what the prospects are: will Firefox change its behavior in the future or should we ask for a modification of the draft? This is definitely a good question, one that I'd like to see addressed too. I think that if the spec remains as is Firefox would likely fire events that implements both the ProgressEvent interface and the LSProgressEvent interface, but encourage people to use the ProgressEvent interface. Possibly even by putting a message in the error console when the old interface properties are accessed. / Jonas
Re: [Element Traversal LC] access to element by index
Daniel Glazman wrote: I'm actually not sure. How often do authors want to get the third child without knowing anything more about it than that it's an element? Iterating through the kids (by means of ET or '.childNodes') gives you much more context information (what type of element it is, what it's bbox is, whether or not it has text/child content, etc.). Not trying to be a pain, but can you identify a concrete use case? [admin: please Cc me, I am not following this mailing-list] I probably has to use it in my daily code - find the n-th child element of another given element - at least a dozen times in the last fifteen days. Iterating through the kids is a for my point of view pure bloat compared to myFooElement.childElements.item(3)... I agree with Daniel, while I don't write a lot of javascript myself I've seen a number of cases like this in the javascript used to implement firefox: bar = foo.parentNode.parentNode.childNodes.item(3).firstChild; Basically I wonder why we wouldn't give access to items by index? Complexity of implementation really can't be an argument here, the amount of code to implement this is trivial, especially compared to all other things required by a browser or DOM implementation. Like Boris pointed out it's likely that an implementation could reuse existing code, but even if that isn't the case I would imagine that the code to implement this property is laughable compared to the code needed to draw an antialiased spline or implementing DOM events (part of which I use as a hiring interview question due to its complexity). I remember in the initial releases of gecko we got a lot of support questions from people wondering why their DOM-using code didn't work in Netscape when it worked in IE. The reason was that IE didn't create DOM nodes for whitespace-only nodes and so the DOM was significantly different and harder to figure out where your nodes lived. getElementById helped to some extent here, and I think that recent development of javascript libraries has helped a lot too. However if we are arguing that people should use those solutions there really is no need for the ElementTraversal spec at all. So I honestly can't understand the complexity argument at all. I think ElementTraversal is something that users really want and would be trivial to implement with or without .childElements. So there really is no need to cut corners and good arguments not to. / Jonas
Re: [Element Traversal LC] access to element by index
On Apr 2, 2008, at 00:48, Boris Zbarsky wrote: OK. So item() would be available on Element after casting it to NodeList in those implementations. I guess you're saying that the cast would not longer be unambiguous if there were multiple NodeLists that might make sense? So childElements couldn't be implemented with a |return this;|? That doesn't seem like such a terrible implementation burden to me, to be honest... I'm not claiming it would be awfully hard, but it does change the impact of Element Traversal from adding four or five methods on an existing class (mere code footprint; super-simple) to adding more run- time object instances. And then, there are issues like should childElements return the same object every time. And if yes, then the implementor needs to add a new pointer to each element node or to add a hashtable on the owner document or something along those lines. Again, not awfully hard, but still more complex than just adding convenience methods on an existing class. And to what end? To use indexing instead of list-style iteration. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [Element Traversal LC] access to element by index
Bjoern Hoehrmann wrote: It would be easier to define that, if the argument starts with a non- white space combinator, it is prefixed with a selector that selects the element node it is called on and only that node. That would give you myFooElement.querySelectorAll(*)[3] Urgh, to say the least. First it means the argument of querySelectorAll is not always a valid Selector. That is bad design. With both my Selectors spec's editor and my CSS WG Co-Chair hats on, that's not desirable. Second, querySelectorAll's implementation would need to parse the first token of the argument to recognize it, and would then rely on the Selectors parser one first time before calling a second time to resolve the selector. Or, second possibility, the Selectors parser has to be tweaked to add a context if the first token is a combinator. From my implementor's perspective, both are NOT acceptable. Really really ugly. We could also standardize the popular .getChildrenByTagName() method, that would give the similar myFooElement.getChildrenByTagName(*)[3] First it's not that popular. I write complex JS code on a daily basis and that's the first time I hear of it. Second, once again I don't see why we have childNode.item() and not childElements.item(). Please give one *good* reason why we cannot do that. Performance ? Let me laugh ! Complexity of implementation ? I guess Jonas answered to that. No use cases ? I would use it immediately and the JS code of Firefox and extensions is full of use cases. Speaking of memory footprint and performance, I certainly prefer getting the nth element child individually through item() rather than getting the whole list of children and then reaching the nth index of it... Either would be preferable over myFooElement.querySelector(:nth-child(3), null, myFooElement) Well... From a design perspective, that is MUCH better than your querySelectorAll() tweak above... /Daniel
Re: [Element Traversal LC] access to element by index
Henri Sivonen wrote: On Apr 2, 2008, at 12:44, Jonas Sicking wrote: And to what end? To use indexing instead of list-style iteration. Exactly. Something that I would imagine is quite commonly done. Note that we're not just talking iterating over a full DOM tree, we're also talking about navigating around in a DOM tree from one known specific node to another. It seems to me that allowing indexed access to children creates a similar kind of problem that allowing indexed access to strings by UTF-16 code unit has created. Allowing app code to index into platform structures that are most commonly forward-iterated seems like an anti-pattern in terms of what implementation constraints are placed if the impression that the app developer gets is that indexing has the performance properties of array access and that it is OK to write app code with that assumption. What makes you think that most users of the DOM-tree does forward-iteration? This is not my experience with the code I've seen. Rather it has been trying to get to specific nodes within a tree. The same argument can be made for .nextElementSibling, why give forward-iterating access into platform structures that are most commonly index-accessed? / Jonas
Re: [Element Traversal LC] access to element by index
On Apr 2, 2008, at 12:44, Jonas Sicking wrote: And to what end? To use indexing instead of list-style iteration. Exactly. Something that I would imagine is quite commonly done. Note that we're not just talking iterating over a full DOM tree, we're also talking about navigating around in a DOM tree from one known specific node to another. It seems to me that allowing indexed access to children creates a similar kind of problem that allowing indexed access to strings by UTF-16 code unit has created. Allowing app code to index into platform structures that are most commonly forward-iterated seems like an anti- pattern in terms of what implementation constraints are placed if the impression that the app developer gets is that indexing has the performance properties of array access and that it is OK to write app code with that assumption. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [Element Traversal LC] access to element by index
Jonas Sicking wrote: Bjoern Hoehrmann wrote: We could also standardize the popular .getChildrenByTagName() method, that would give the similar myFooElement.getChildrenByTagName(*)[3] This seems like an excellent idea. To do in addition to the ElementTraversal spec. I understand from Jonas's answer that he also never heard before of that popular getChildrenByTagName()... /Daniel
Re: [Element Traversal LC] access to element by index
On Apr 2, 2008, at 13:20, Jonas Sicking wrote: Henri Sivonen wrote: On Apr 2, 2008, at 12:44, Jonas Sicking wrote: And to what end? To use indexing instead of list-style iteration. Exactly. Something that I would imagine is quite commonly done. Note that we're not just talking iterating over a full DOM tree, we're also talking about navigating around in a DOM tree from one known specific node to another. It seems to me that allowing indexed access to children creates a similar kind of problem that allowing indexed access to strings by UTF-16 code unit has created. Allowing app code to index into platform structures that are most commonly forward-iterated seems like an anti-pattern in terms of what implementation constraints are placed if the impression that the app developer gets is that indexing has the performance properties of array access and that it is OK to write app code with that assumption. What makes you think that most users of the DOM-tree does forward- iteration? This is not my experience with the code I've seen. Rather it has been trying to get to specific nodes within a tree. If one wants a specific node, why not put an id on it and use getElementById? Knowing that you want the fifth element child of another element requires a priori knowledge of the document tree shape anyway. That said, I don't think there's a problem with having a getChildElementByIndexThisIsNotGuaranteedToBeArrayAccess() if you really want to get the nth element child only instead of iterating with an index. The same argument can be made for .nextElementSibling, why give forward-iterating access into platform structures that are most commonly index-accessed? Indeed the argument I made should lead to iterator objects instead of either item(n) or nextSibling. I think one of the major design flaws of the DOM is that it gives two views to the tree without specifying the performance characteristics of those views. App developers who like linked lists may reasonable assume that nextSibling is a mere pointer dereference. App developers who like arrays may reasonably assume that item(n) is a mere array access. Now DOM implementations are damned either way and have to do tricks to make the non-native view fast as well. (From what I've said so far, it can be guessed that I prefer the linked list view. :-) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [XHR2] onprogress Event issue
Anne van Kesteren wrote: On Wed, 02 Apr 2008 08:54:17 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: This is definitely a good question, one that I'd like to see addressed too. I think that if the spec remains as is Firefox would likely fire events that implements both the ProgressEvent interface and the LSProgressEvent interface, but encourage people to use the ProgressEvent interface. Possibly even by putting a message in the error console when the old interface properties are accessed. If we want a different interface I think the progress events specification should be changed. XMLHttpRequest Level 2 simply uses whatever Progress Events 1.0 defines at this point and I'd like to keep it that way. FWIW i'm fine with keeping things the way they are. Though there is definitely a risk that other vendors will have to implement the LSProgressEvent interface as well in order to support content out there that is written for firefox. But we're talking about two extra properties whose implementation will basically just be to forward to another property so I doubt that it's a big burden. / Jonas
Re: [Element Traversal LC] access to element by index
Daniel Glazman wrote: Jonas Sicking wrote: Bjoern Hoehrmann wrote: We could also standardize the popular .getChildrenByTagName() method, that would give the similar myFooElement.getChildrenByTagName(*)[3] This seems like an excellent idea. To do in addition to the ElementTraversal spec. I understand from Jonas's answer that he also never heard before of that popular getChildrenByTagName()... I hadn't, but I wouldn't expect to either since I'm not looking at toolkits that often. But I was serious about thinking that adding the function seems like a good idea. It's currently much too painful to navigate around in the DOM so it's something we should try to fix. / Jonas
Re: [Element Traversal LC] access to element by index
Jonas Sicking wrote: But I was serious about thinking that adding the function seems like a good idea. It's currently much too painful to navigate around in the DOM so it's something we should try to fix. Agreed. /Daniel
Re: [Element Traversal LC] access to element by index
On Apr 2, 2008, at 15:09, Jonas Sicking wrote: It can be a pain to add IDs to *all* the nodes you ever access. A pattern i've seen a lot is to have small repeating sections in a page, and then navigating within that repeated section. That makes sense. That said, I don't think there's a problem with having a getChildElementByIndexThisIsNotGuaranteedToBeArrayAccess() if you really want to get the nth element child only instead of iterating with an index. Sure, as long as we also add .firstElementChildThisIsNotGuaranteedToBePropertyAccess ;) Hmm. Somehow I thought it would be a given that nextElementSibling/ firstElementChild wouldn't be direct pointers but convenience getters built on top of nextSibling and firstChild. But I guess an app developer might as well expect the DOM to maintain lots and lots of direct pointers... Anyway, myFooElement.getChildrenByTagName(*)[3] looks like it does something more expensive than myFooElement.childElements[3] even if the implementation were the same, so they give app developers different expectations of performance characteristics. The same argument can be made for .nextElementSibling, why give forward-iterating access into platform structures that are most commonly index-accessed? Indeed the argument I made should lead to iterator objects instead of either item(n) or nextSibling. I think one of the major design flaws of the DOM is that it gives two views to the tree without specifying the performance characteristics of those views. App developers who like linked lists may reasonable assume that nextSibling is a mere pointer dereference. App developers who like arrays may reasonably assume that item(n) is a mere array access. Now DOM implementations are damned either way and have to do tricks to make the non-native view fast as well. Honestly, is this really a big problem? It used to be that iterating a child list using .nextSibling was O(N^2). It was a problem for me when I tried to walk the HTML5 spec in Firefox 1.5 using iterative traversal with firstChild/nextSibling/parentNode. Firefox 1.5 performed a *lot* worse than the then-current versions of Opera and Safari. And the spec was a lot smaller back then, too. :-) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [Element Traversal LC] access to element by index
On Apr 2, 2008, at 16:21, Henri Sivonen wrote:
It was a problem for me when I tried to walk the HTML5 spec in
Firefox 1.5 using iterative traversal with firstChild/nextSibling/
parentNode. Firefox 1.5 performed a *lot* worse than the then-
current versions of Opera and Safari. And the spec was a lot smaller
back then, too. :-)
It turns out that I still have the test case around:
http://hsivonen.iki.fi/test/dom-walk-perf.html
I think it is perfectly reasonable to expect this algorithm to be the
fast way to walk when you see a tree with first child, sibling and
parent references:
function walk(node) {
var current = node;
var next = null;
for (;;) {
if (next = current.firstChild) {
current = next;
continue;
}
break;
for (;;) {
if (next = current.nextSibling) {
current = next;
break;
}
current = current.parentNode;
if (current == node) {
return;
}
}
}
}
With Element Traversal, I think it would be reasonable to expect the
above algorithm to be the fast way to walk the elements when s/
firstChild/firstElementChild/ and s/nextSibling/nextElementSibling/.
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
Re: [Element Traversal LC] access to element by index
On Apr 2, 2008, at 16:50, Henri Sivonen wrote:
if (next = current.firstChild) {
current = next;
continue;
}
break;
Please disregard that break;. (Left-over from a switch that was
obscuring the main point of the algorithm.)
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
Re: DOM3 Events Keyflow
Hi all, I did some key event testing, mainly on Windows. Tested FF3, Safari3.1, Opera9.5 (not IE, because of its non-DOM-events). When just pressing one character key all the browsers dispatch 'keydown', 'keypress', 'input', 'keyup', but Safari dispaches also 'textInput' right before 'input'. So the key event dispatching in non-IME cases is quite similar in all those browsers - at least when the testcase is simple enough :) But when enabling IME things change quite a bit. The testcase was simply to press 'k' and 'a' and enter to get one Hiragana symbol. MS IME Standard 2002 ver 8.1 was used for the testing. Opera seems to dispatch only the first 'keydown' and when the composition is ready one 'input'. Subsequent IME compositions don't trigger keydown, only 'input' events. Safari does something like: 'keydown', 'input', 'keyup', 'keydown', 'input', 'input', 'keyup', 'keydown', 'input', 'textInput', 'input', 'keyup'. That is quite many 'input' events. Gecko has for a long time had few events for IME, so the event flow in the testcase goes like this: 'keydown', 'keypress', 'compositionstart', 'text', 'text', 'text', 'input', 'compositionend', 'keyup' I don't like the event name 'text' (which is dispatched for each component in the composition, or how to say) but it has been there since 1999. The names 'compositionstart' and 'compositionend' are ok. If those gecko-only-events are removed from the flow, it looks just like the normal key event handling: 'keydown', 'keypress', 'input', 'keyup' Pretty nice, IMHO. My testing may miss some events, especially if non-gecko-engines have some their own events. I attached also one quick version of gecko-key-event-flow. It may contain bugs and doesn't cover all the cases. -Olli Doug Schepers wrote: Hi, WebAPI fans- This past week in the DOM3 Events telcon, we discussed the order of key events for the DOM3 Events specification, with attention paid to IME. We are hoping to model the most platform-independent event order, and are seeking active feedback from Apple, Microsoft, Mozilla, Opera, and anyone else with experience in implementing keyboard events (especially with regards to internationalization). I've made a trial schematic to get us started [1]. I've also modeled it in Graphviz, and I've included the Dot format file here (attached). Graphviz is free open source software [2], and the Dot format is really simple to edit. We are hoping to discuss this again at next week's teleconference. [1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/proposals/d3e-keyflow.svg [2] http://www.graphviz.org/ Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI inline: gecko-keyflow.svg
Re: [Element Traversal LC] access to element by index
On Apr 2, 2008, at 2:44 AM, Jonas Sicking wrote: Henri Sivonen wrote: On Apr 2, 2008, at 00:48, Boris Zbarsky wrote: OK. So item() would be available on Element after casting it to NodeList in those implementations. I guess you're saying that the cast would not longer be unambiguous if there were multiple NodeLists that might make sense? So childElements couldn't be implemented with a |return this;|? That doesn't seem like such a terrible implementation burden to me, to be honest... I'm not claiming it would be awfully hard, but it does change the impact of Element Traversal from adding four or five methods on an existing class (mere code footprint; super-simple) to adding more run-time object instances. And then, there are issues like should childElements return the same object every time. And if yes, then the implementor needs to add a new pointer to each element node or to add a hashtable on the owner document or something along those lines. Again, not awfully hard, but still more complex than just adding convenience methods on an existing class. Sure it's more complex, but it's still trivial. In WebKit, it would be more than one line of code to add a new kind of NodeList. Not a ridiculous amount of code though. However, I think live NodeLists are an anti-pattern. They tend to be horrible for performance in the face of mutation (and even when there isn't mutation, extra objects are allocated). This is part of why I strongly argued for querySelectorAll to return a non-live list. And using indexing is not really any more convenient than using next/ previous methods. I can live with the editor's decision either way on this one. Cheers, Maciej
Re: [Element Traversal LC] access to element by index
Henri Sivonen wrote: I'm not claiming it would be awfully hard, but it does change the impact of Element Traversal from adding four or five methods on an existing class (mere code footprint; super-simple) That depends on what performance characteristics callers expect or UAs want to provide. More on that below. And then, there are issues like should childElements return the same object every time. True. And if yes, then the implementor needs to add a new pointer to each element node or to add a hashtable on the owner document or something along those lines. Assuming there is nothing like that in place already, yes. I guess I'm a little biased since in Gecko there is somethign like that in place already (if nothing else to support setUserData() from DOM3 Core). One could also allow UAs to choose, of course, but that might give them different performance characteristics. But you can't prevent that anyway; see below. And to what end? To use indexing instead of list-style iteration. This is the really good question. The other major use-case of an actual object that represents the list of child elements is that the script can cache the object if it intends to iterate the list multiple times. That, of course, raises questions about whether the list should be live or not, because for different use cases one might want to cache one or the other. If the common envisioned use case for this will involve multiple iterations of the list, possibly separated in time, then the right performance tradeoff might be creating an object which caches the list of child elements so as to avoid having to walk all the non-element kids and check their types all the time. The caching could happen in the user script, or it could happen in the UA itself. The latter is what I'm guessing would end up being implemented in Gecko given the spec as it stands. I say that because I strongly suspect that, in practice, child elements of the same node are walked multiple times. Note that any use case that involves getting the childElementCount immediately means that two walks are required on the UA side, by the way. -Boris
Re: [Element Traversal LC] access to element by index
Henri Sivonen wrote: Allowing app code to index into platform structures that are most commonly forward-iterated seems like an anti-pattern in terms of what implementation constraints are placed if the impression that the app developer gets is that indexing has the performance properties of array access and that it is OK to write app code with that assumption. AS you noted in another post, in practice app developers assume that anything they do will be fast and when it's not they blame the UA. And therefore, no matter which access pattern you expose it has to be fast. -Boris
Minutes, DOM3 Events Telcon, 02 April 2008
Hi, WebAPI fans- The minutes for the 02 April 2008 DOM3 Events telcon can be found here: http://www.w3.org/2008/04/02-webapi-minutes.html Or as text, below: [1]W3C [1] http://www.w3.org/ - DRAFT - Web API WG Teleconference 02 Apr 2008 [2]Agenda [2] http://www.w3.org/2008/webapps/wiki/2_Apr_2008 See also: [3]IRC log [3] http://www.w3.org/2008/04/02-webapi-irc Attendees Present Doug, Carmelo, smaug, ap, Travis Regrets Chair Doug Scribe Carmelo, Travis Contents * [4]Topics 1. [5]Key Event Model 2. [6]keyCode and charCode 3. [7]mobile-specific events * [8]Summary of Action Items _ trackbot Date: 02 April 2008 smaug Zakim: ??P4 is smaug shepazu [9]http://lists.w3.org/Archives/Public/www-archive/2006Nov/att-0047/ keyCode-ie.htm [9] http://lists.w3.org/Archives/Public/www-archive/2006Nov/att-0047/keyCode-ie.htm shepazu scribe: Carmelo shepazu scribeNick: Carmelo ap_ Alexey Proskuryakov, Apple scribe ACTION: Item to To Carmelo to cross tests keyup keydown and keypress as described on [recorded in [10]http://www.w3.org/2008/04/02-webapi-minutes.html#action01] [11]http://lists.w3.org/Archives/Public/www-archive/2006Nov/att-0047 /keyCode-ie.htm [11] http://lists.w3.org/Archives/Public/www-archive/2006Nov/att-0047/keyCode-ie.htm ap_ close enough :) Daug went over new introductions Key Event Model shepazu Ollie sent in this: [12]http://lists.w3.org/Archives/Public/public-webapi/2008Apr/att-00 34/gecko-keyflow.svg [12] http://lists.w3.org/Archives/Public/public-webapi/2008Apr/att-0034/gecko-keyflow.svg shepazu [13]http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0034.h tml [13] http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0034.html ap_ correct, 10:40 PM :) smaug 9:40 pm here ap_ that's an OK time for me, no problem! shepazu Alexey,s email: [14]http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0220.h tml [14] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0220.html Travis (a little late, sorry) Travis I'll be calling in just a minute... Ap: Explained his model view Doug: Although browsers can not gurantee event orders's users can ... to Alexey, Do u thing that will be useful? Ollie: Quite a number of issues with that. shepazu Dead keys, etc. smaug it's very noisy right now smaug and echo too ap_ yes, that's correct Doug to Alexey: When your first started you had a model similar to Firefox? shepazu and now they no longer provide an emulation layer ap_ yes, I can describe it like that ap_ that's both for matching IE, and for better supporting advanced text input on windows Alexey: We do not have that many problems with our model. ap_ not to say that Firefox is significantly broken Alexey: A few minor issues with Windows ap_ but there were some issues Alexey: Possible to define some kind of state diagram Travis: What about performance issues after removing the emulation layer? Alexey - None shepazu TL: did you drop the emulation layer for benchmarking reasons? shepazu AP: no, to better match IE... shepazu ... ap_ and resolve some issues with advanced text input that we had ap_ ok Doug: Will it be possible to write down (email) the issues? ap_ in fact, we are trying to make OS X and Windows versions work the same ap_ as much as possible shepazu scribeNick: Travis shepazu scribe: Travis It would be nice to standarize on one model or another... (TL: said that) Doug: It would mean that all other browers might have to change their behavior--at the risk of breaking pages. (someone:sorry) Whenever we change eventing, we break something. (It always happens) Whenever a webpage wants to handle IME, it's a mess Doug: With a single model, there will be pages that break, but I think that most pages don't use it 'cause that can't depend on it. ... If people are relying on a model, it's probably IE's model. In Safari, we saw significant breakage on many pages, but not significant enough to cause a huge problem. (many pages were special-casing for safari, but they were quite ready to adapt) Doug: Do you think that if we specified a set behavior, that those pages would change to match? Yes, big sites would adapt. Doug: that reduces the risk of us proposing a specific model. ... until we hear otherwise, we will continue to try to specify a model. ... If we do have a cleaner (or specified) model, we would adopt it. ... We have two options: ... 1) Figure out IE's behavior and specify that
RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]
I think the XDR proposal is pretty good and is the best of the current proposals to push forward to standardization. I hope Microsoft finds a way to make that happen. Some responses to Jonas' comments are inline below... Jonas Sicking wrote: Eric Lawrence wrote: Ian-- Thanks for sharing your opinions. I'd like to take the opportunity to clarify a few points of confusion. This is blatently untrue, a number of serious security problems with XDR have already been raised (such as the fact that it encourages content-type sniffing It's possible that you overlooked some mails on the thread? Vis-à-vis content-type sniffing, it was plainly stated that Content-Type sniffing is neither recommended, nor necessary. I think you are misunderstanding the issues Ian has raised. Since XDR does not let you set the Content-Type header, the server is in fact required to sniff the content type. How else would the server figure out the content type of the request body? I think Eric's point is that the client specified Content-Type header cannot be trusted to accurately describe the content, so the server must parse the content under the assumption that the header is misleading. Given that status-quo, and assuming the resource only accepts one Content-Type, omitting the header doesn't seem to change the server's responsibilities. There could be a danger when the resource accepts more than one media type and the server determines that the client sent a different media type than the client thought it was sending. In this case, the server sees the client as saying something that the client didn't mean to say. To avoid this scenario, there would have to be some mechanism agreed to between the client and the server for specifying the intended media type. This role is precisely what the Content-Type header was created for, but it has unfortunately been overloaded with security implications. Having client and server coordinate the media type based on a URL query string argument seems like the best alternative. XDR is a truly anonymous request and does not send credentials to ANY site (1st party, 3rd party), trustworthy or not. In this way, we have high confidence that there is no possibility of executing a CSRF attack against an unsuspecting legacy server which uses cookies or HTTP authentication. Again, this is not the concern. The concern is sites that do want to transport private data. They are going to try to do this weather the browser provides the API meant for this or not. Sending the user's cookies, as AC4CSR does, is just not a viable design, since the target resource cannot determine whether or not the user consented to the request. I've posted several explanations of the attacks enabled by this use of ambient authority, and, in my opinion, the issues are still outstanding. The use of ambient authority in AC4CSR is a show-stopper, as reflected in the decision Mozilla announced on this mailing list. In fact, I would argue that XDR does encourage sending private data. Most use cases for POST that I can think of involves knowing who the data is coming from. Or have you had other use cases in mind? There are many other ways to authorize a request, other than sending the user's credentials, which is among the worst ways. Additionally, it is not true that no authorization credentials is being sent. Intranet sites might authorize simply based on the fact that you can connect to the intranet server. I have still not seen anything in the XDR spec to prevent internet-interanet POSTs so this still seems to be the case. Currently, an HTML form can POST internet-intranet with Content-Type of application/x-www-form-urlencoded or text/plain. The XDR proposal adds a third case of no specified Content-Type (but with no cookies or custom headers). It seems highly unlikely that an intranet resource correctly defends against the first two cases, but is vulnerable to the third. I would rather bet on this than work through all the things that might go wrong with AC4CSR's pre-flight request, caching, ACLs and use of ambient authority. I definitely appreciate all the work that Microsoft has put into the spec, but am saddened that there was no mention about XDR in any of the numerous posts from anyone at microsoft. I think the AC4CSR spec is a goner, and so appreciate Microsoft stepping up with a proposal that seems more likely to survive study and deployment. Given the Mozilla announcement, now seems like the right time to move on from the AC4CSR proposal. --Tyler IHTMLXDomainRequest Interface () http://msdn2.microsoft.com/en-us/library/cc288108(VS.85).aspx Access Control for Cross-site Requests http://www.w3.org/TR/access-control/
Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]
Close, Tyler J. wrote: I think Eric's point is that the client specified Content-Type header cannot be trusted to accurately describe the content, so the server must parse the content under the assumption that the header is misleading. I don't think anyone is arguing about that. There could be a danger when the resource accepts more than one media type and the server determines that the client sent a different media type than the client thought it was sending. Actually, the danger is when the resource accepts more that one media type, there is a proxy or firewall that filters which types are allowed (possibly depending on the origin), and the sniffing on the server and firewall is not exactly identical. This is the most common security issue with content-type sniffing: one program trying to protect another from certain types of content, and failing because the type-identification algorithms are not precisely identical. The proposal of communicating the type via some mechanism other than Content-Type would work to address this issue if the firewall is aware of that mechanism and has exactly the same implementation for type detection as the resource. It seems to me that this is barely less fragile as relying on content sniffing... -Boris
Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]
On Apr 2, 2008, at 4:52 PM, Close, Tyler J. wrote: Sending the user's cookies, as AC4CSR does, is just not a viable design, since the target resource cannot determine whether or not the user consented to the request. I've posted several explanations of the attacks enabled by this use of ambient authority, and, in my opinion, the issues are still outstanding. The use of ambient authority in AC4CSR is a show-stopper, as reflected in the decision Mozilla announced on this mailing list. Can you please post these examples again, or pointers to where you posted them? I believe they have not been previously seen on the Web API list. A number of people have mentioned that the AC approach to cross-site XHR is insecure (or that XDR is somehow more secure), but I have not yet seen any examples of specific attacks. I would love to see this information. If I do not see a description of a specific attack soon I will assume these claims are just FUD. Note also that sending of cookies is not an essential feature of AC4CSR; certainly it could be a viable spec with that feature removed. Do you believe there are any other showstopper issues? Regards, Maciej
RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]
Maciej Stachowiak wrote: On Apr 2, 2008, at 4:52 PM, Close, Tyler J. wrote: Sending the user's cookies, as AC4CSR does, is just not a viable design, since the target resource cannot determine whether or not the user consented to the request. I've posted several explanations of the attacks enabled by this use of ambient authority, and, in my opinion, the issues are still outstanding. The use of ambient authority in AC4CSR is a show-stopper, as reflected in the decision Mozilla announced on this mailing list. Can you please post these examples again, or pointers to where you posted them? I believe they have not been previously seen on the Web API list. I've written several messages to the appformats mailing list. I suggest reading all of them. The most detailed description of the attacks are in the message at: http://www.w3.org/mid/[EMAIL PROTECTED] with a correction at: http://www.w3.org/mid/[EMAIL PROTECTED] A number of people have mentioned that the AC approach to cross-site XHR is insecure (or that XDR is somehow more secure), but I have not yet seen any examples of specific attacks. I would love to see this information. If I do not see a description of a specific attack soon I will assume these claims are just FUD. I think we've met before at a SHDH event. That was a more pleasant conversation. Hopefully, we'll be able to regain that tone. Note also that sending of cookies is not an essential feature of AC4CSR; certainly it could be a viable spec with that feature removed. Do you believe there are any other showstopper issues? Possibly. There is a lot of complexity in the AC4CSR proposal. I've been writing about the most severe things as I find them. --Tyler
RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]
On Thu, 3 Apr 2008, Close, Tyler J. wrote: Maciej Stachowiak wrote: Can you please post these examples again, or pointers to where you posted them? I believe they have not been previously seen on the Web API list. I've written several messages to the appformats mailing list. I suggest reading all of them. The most detailed description of the attacks are in the message at: http://www.w3.org/mid/[EMAIL PROTECTED] with a correction at: http://www.w3.org/mid/[EMAIL PROTECTED] As noted here: http://lists.w3.org/Archives/Public/public-appformats/2008Feb/0138.html ...these are not problems with the Access Control and XXX specs. XDR is just as susceptible to these problems. The above e-mail also describes ways to mitigate these problems. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
