Re: Opera's Proposal for :context Selector
-www-style
+public-webapps
Andrew Fedoniouk wrote:
Lachlan Hunt wrote:
Andrew Fedoniouk wrote:
Bert Bos wrote:
(It seems to me you shouldn't need it at all. The problem seems to
be that x.querySelector(:root) doesn't return x. That looks
strange to me: you pass a tree and a pattern, and you get something
outside the tree!? But I'm not an expert on that spec...)
The API doesn't change the way in which an element is evaluated
against a selector; it's still evaluated in the context of the
entire document. All it does is limit the collection of elements
that are evaluated against it.
do you have any particular use cases for such a behavior? At last:
who requested such querySelector(), where that demand came from?
It was done this way for mostly for technical reasons, many of which
are explained in the the following email. Basically, it was mostly to
avoid changing the way selectors work, or how they are parsed.
I am not sure I understand problems you have mentioned.
Mathematically any sub-tree is a tree by itself in DOM alike graphs.
Root element is not anyhow different from any other elements in the DOM
if to speak about CSS selectors.
What you need is described as solution 5 in this email I showed you before.
http://lists.w3.org/Archives/Public/public-webapi/2008May/0057.html
My proposal to treat :scope as such a :root
:rootulli {}
does not require to change anything. At all.
But what you're asking for still suffers from the problems of solutions
3 and 4 because :root is defined to match the root element of the document.
Your idea requires special :scope pseudo that has to be dealt separately
in querySelector and in CSS selectors - so to *change* the way how
selectors are handled now.
Solution 5 requires changing the way selectors are parsed in order to
allow combinators to appear at the beginning. I am working on finding a
solution to that problem.
http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0181.html
I'm also trying to find a way to allow it to match sibling elements and
their descendants as well, like JQuery does for, e.g. foo.find(+p)
It also addresses the majority of use cases while remaining quite
flexible, especially when combined with :scope. It allows, for
example, to do additional filtering based on the state of scope
element itself, or its ancestors.
I've seen people use jQuery but have not seen people using or requesting
such additional filtering, terribly sorry. That is why I asked.
As I said before full depth lookups are ineffective for scoped cases.
Technically it would be just a bug of specification if you would ask
any mathematician.
The problem is if I were to change querySelector is defined now, we
already have implementations that are getting close to shipping and such
a huge change could majorly delay things. Plus, we haven't entirely
solved the technical issues.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Widgets and :context
On Thu, 17 Jul 2008 20:31:13 +0200, Andrew Fedoniouk [EMAIL PROTECTED] wrote: That is what I thought: widgets if used as components on some page behave as a micro documents - fragments of the DOM with local style systems rooted to the widget. But it seems that this is not the case - that Widgets are more about free floating frames that live in top level windows on desktop(?), something like Konfabulator desktoplets. Assuming I understand you correctly, then yes. The Widgets spec at W3C is about a way to package web standards-based applications to use them as locally installed applications. 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://www.opera.com
Re: #webapps is now logged
It is my understanding that Krijn implemented some type of [off] functionality. Krijn - would you please provide a short summary regarding that function (or a pointer to such information)? If you say And the [off] is some secret info. you'll get http://krijnhoetmer.nl/irc-logs/webapps/20080717#l-5 - that's it :) The stuff _is_ in the static log file, it's just not presented on my site. I don't guarantee nobody will ever read it, but it's not my intention to show it to anyone (although I do accept biddings :] ). And if you don't want anybody to read what you said, just don't say it. Other people may log as well, and tools won't save you :) If you have any ideas about making this thing better/more useful, let me know. I'm krijn or krijnh or IRC, and IRL as well. Btw, keep up the great work you guys! Thanks a lot for letting us (less enlightened) developers have a job :) Grt, Krijn -- Krijn Hoetmer // Freelance web developer +31622471234 // http://krijnhoetmer.nl/
Re: [D3E] Possible Changes to Mutation Events
On Thu, 17 Jul 2008 17:51:42 -0700, Jonas Sicking [EMAIL PROTECTED] wrote: As for when the events fire (note that this is just clarifications of the spec, not changes to it): For events that fire after the mutation takes place I propose that we add a concept of a compound operation and state that while compound operations are in progress no mutation events are fired. I was thinking about this some more, and it seems to me that a compound operation is more or less a lightweight transaction (transaction in the sense that is referred to in 1.6.4 of L2 events). It might be useful to expose this functionality to authors as well. If a couple of methods were added to allow authors to indicate the start and end of a compound operation/transaction, and it were guaranteed that no mutation events would be dispatched until the end of the compound operation, they would have to worry less about dealing with interference from other mutation listeners while they're doing a high-level compound operation. It would be pretty trivial to implement on top of internal compound events, and would solve the problem of revalidating assumptions for authors as well as implementors. The only pitfall I can see is if authors started a compound operation and never ended it, causing an unbounded queue of events. We'd have to allow implementations to drop the queue (or some events) if it got too large. Thoughts? kats
Re: [D3E] Possible Changes to Mutation Events
Doug Schepers wrote: Hi, Jonas- Thanks for this modified proposal. I want to hear back from those who've already commented as to their disposition, and to solicit comments from other known implementors (e.g., gtk, BitFlash, Opera, JSR), but I think your proposal is reasonable, and well detailed. A few comments inline... Jonas Sicking wrote (on 7/17/08 8:51 PM): * Add a |readonly attribute long relatedIndex;| property to the MutationEvent interface. * Add a DOMChildRemoved event which is fired on a node when one of its children is removed. The relatedNode property contains the removed child, and relatedIndex contains the index the child had immediately before the removal. The event is fired after the removal takes place. * Add a DOMDescendantRemovedFromDocument event which is fired on a node when the node is in a document, but any of nodes the descendants is removed from the document. The event is fired after the removal takes place. The relatedNode property contains the removed descendant. The relatedIndex property contains the index the child had immediately before the removal. (Should relatedIndex be -1 when the node wasn't removed from its parent, but rather an ancestor was?) What is the rationale for having both 'DOMChildRemoved' and 'DOMDescendantRemovedFromDocument'? Wouldn't a single one, 'DOMDescendantRemovedFromDocument' (or, preferably, 'DOMDescendantRemoved'), work about as well? You already give a way to detect if it was a child or a descendant. Well, I'd start by asking what the rationale is for mutation events at all :) They seem to only solve the very simple cases where all parties that mutate the page cooperate nicely with each other and with the parties that listen to mutation events. But I would have expected that in those cases the parties that mutate the DOM could instead have notified the listening parties directly. But I digress :) Specifically the two new events correspond to the current DOMNodeRemoved and DOMNodeRemovedFromDocument, so the rationale is the same as for those old events. However I can only guess at that rationale is. DOMNodeRemoved is useful when you want to know when a node is removed from its parent. DOMNodeRemovedFromDocument is useful when you want to know when a node is no longer part of a document. The latter seems in general more useful, for example for keeping a TOC of headings in a page, or a list of clickable links. However the latter seems very complicated to implement without severely regressing performance any time there is a listener for the event. Whenever a node is removed you have to fire an event for each and every node in the removed subtree, presumably including attribute nodes. Also DOMNodeRemoved can be mostly used to emulate DOMNodeRemovedFromDocument by checking if the node you are interested in (i.e. the link or the heading) has the removed node in its parent chain. In mozilla we have never implemented DOMNodeRemovedFromDocument or DOMNodeInsertedIntoDocument due to its high cost. Likewise I doubt that we'll implement DOMDescendantRemovedFromDocument. I'm not sure what other vendors have done about the old event or feel about the new. I understand that having the distinction means that you could filter on the level of depth to fire events on, but I'm asking if this is useful and necessary. I take it you are asking under the general assumption that mutation events are useful at all? :) I generally think that DOMDescendantRemovedFromDocument is likely easier to use, but seems prohibitively expensive to implement correctly, whereas DOMChildRemoved seems to cover most use cases, though with a bit more effort on the side of the listener. Also note that all these events have a capture phase, so you can always attack your listener on an ancestor of the nodes you are interested in, such as the document node. * Specify *when* the events fire (see details below). We should do this regardless, since it is tightening up the spec, not changing it (though admittedly, it may force some implementations to change anyway... but that means more interop). * Deprecate the DOMNodeRemoved and DOMNodeRemovedFromDocument events. If this means making them optional or just discouraged I don't really care. I'd even be ok with simply leaving them in as is. Mozilla will simply remove our implementation of the DOMNodeRemoved event. We've never supported the DOMNodeRemovedFromDocument event. If Mozilla is determined to remove them regardless of what the spec says, then I would rather leave them in as specced, but deprecate them. Yes, given that someone pointed out that we can't really fire DOMNodeRemoved after the event takes place as that means that the parent chain is broken and so the event wouldn't reach any ancestors, I see no other alternative than dropping the event entirely. Do note that there is still nothing that defines when these events should fire. I.e. if you do
Re: [D3E] Possible Changes to Mutation Events
Kartikaya Gupta wrote: On Thu, 17 Jul 2008 17:51:42 -0700, Jonas Sicking [EMAIL PROTECTED] wrote: * Add a DOMDescendantRemovedFromDocument event which is fired on a node when the node is in a document, but any of nodes the descendants is removed from the document. The event is fired after the removal takes place. The relatedNode property contains the removed descendant. The relatedIndex property contains the index the child had immediately before the removal. (Should relatedIndex be -1 when the node wasn't removed from its parent, but rather an ancestor was?) From this description it seems bit ambiguous as to exactly which node is the target of the event, since there could be multiple nodes that satisfy the conditions (a) being attached to the document and (b) ancestor of the removed node. I assume you mean the node that satisfies the conditions that is deepest in the tree? And yes, I think relatedIndex should be -1 if an ancestor was the one that was removed, so that it's easier to distinguish between the roots of the removed subtrees and the non-roots. Good point. Yes, I meant the one deepest in the tree. Another way to put it is that the target is always the parent old of the root of the subtree that was removed. / Jonas
Re: Widgets and :context
Charles McCathieNevile wrote: On Thu, 17 Jul 2008 20:31:13 +0200, Andrew Fedoniouk [EMAIL PROTECTED] wrote: That is what I thought: widgets if used as components on some page behave as a micro documents - fragments of the DOM with local style systems rooted to the widget. But it seems that this is not the case - that Widgets are more about free floating frames that live in top level windows on desktop(?), something like Konfabulator desktoplets. Assuming I understand you correctly, then yes. The Widgets spec at W3C is about a way to package web standards-based applications to use them as locally installed applications. cheers Chaals Thanks for the clarification. Seems like I mixed up Web Widget[1], Web Control[2] and Behavior[3] [1] http://en.wikipedia.org/wiki/Web_widget [2] http://www.whatwg.org/specs/web-controls/current-work/ [3] http://www.w3.org/TR/becss/ Simply thought that scoped style sheet are somehow related to one of those. -- Andrew Fedoniouk. http://terrainformatica.com
Re: [D3E] Possible Changes to Mutation Events
Hi, Jonas- Jonas Sicking wrote (on 7/18/08 2:51 PM): Well, I'd start by asking what the rationale is for mutation events at all :) They seem to only solve the very simple cases where all parties that mutate the page cooperate nicely with each other and with the parties that listen to mutation events. But I would have expected that in those cases the parties that mutate the DOM could instead have notified the listening parties directly. I admit I've used mutation events only sparingly in my own projects, so I'm not the most qualified to answer. However, many authors I've talked to or read from speak of them glowingly, so I will defer to the notion that they are useful. I know you deal a lot with the more complex mashup cases, but are those really the most common case? I suspect that even today, the very simple case where only one site is involved are the more common. Or does all parties also mean cases where people are using script frameworks like dojo? In mozilla we have never implemented DOMNodeRemovedFromDocument or DOMNodeInsertedIntoDocument due to its high cost. Likewise I doubt that we'll implement DOMDescendantRemovedFromDocument. I'm not sure what other vendors have done about the old event or feel about the new. I am very reluctant to specify something that browser vendors won't implement. Unless other vendors feel strongly about including it, or Mozilla changes their mind and decides to include it, I'm not going to waste everyone's time by adding this. The only reason to add a feature is to make sure that authors can use it interoperably, in my mind. As an author, I was (and am!) always bitter and disappointed when I read about *exactly* the feature I need in a spec, but it's not implemented at all, or not implemented interoperably enough to use. I have no intention of building up authors expectations like that if it will be futile. If possible, I prefer to keep looking for a solution that fits the use cases and will be widely implemented. But I want to resolve this soon. This specification is at the awkward point where it's too established to change it much, and too unstable to rely on it. That sucks for everyone. I understand that having the distinction means that you could filter on the level of depth to fire events on, but I'm asking if this is useful and necessary. I take it you are asking under the general assumption that mutation events are useful at all? :) That is the general tenor of the authors, who, along with users, are my chief constituents. Do note that there is still nothing that defines when these events should fire. I.e. if you do foo.textContent = '', does that fire a DOMNodeRemoved on all elements before any of them are removed, or does it fire the event on each of them as they are removed. Though it might not be needed to be defined if the events get deprecated anyway... No, I intend to define that regardless of whether or not we deprecate it. Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF
New file I/O build
Hi folks, if you want to play around with the file I/O stuff, we have released another Opera build on desktop platforms (Windows, Mac, Linux, FreeBSD) that incorporates it - again for the moment only enabled for widgets. This is an experimental build, so usual warnings and disclaimers apply - read more about it at http://labs.opera.com/news/2008/07/18/ 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://www.opera.com
Re: Proposal for an extension XMLHttpRequest to allow sending files
On Jul 18, 2008, at 9:58 AM, Aaron Boodman wrote: On Thu, Jul 17, 2008 at 4:06 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Jul 17, 2008, at 3:53 PM, Aaron Boodman wrote: I have two minor concerns with this proposal, both in the cases where it differs from Gears: 1. Combining the concepts of 'large chunk of binary data' and 'file' seems unnecessarily coupled to me. It seems likely that in the future the first concept would be useful in the web api by itself. For example, in Gears, we have a xhr.responseBlob property. Having a fileName property here would not always make sense. I agree! But this proposal doesn't include a concept of 'large chunk of binary data', only a concept of 'file'. It just lets you send the file without first turning it into a chunk of binary data. We're not proposing that the File object should be a generic representation for any binary data, just that it should be sendable via XHR directly. So you're saying that in the future XHR.send() could be overloaded to take blob as an argument too? I guess another way to handle it would be with inheritance -- File could implement Blob, and then you could change XHR.send() to take Blob instead of File. Either of these are fine with me. XHR.send() already takes many things, so one extra overload is not a big deal. I can imagine a future design making File be a kind of Blob instead of having a Blob as in gears, but the idea is that we don't all have to agree on that now. 2. The slice() method seems important for the initial version, particularly if you are targeting the large upload use case. We use this to cut up a large file into smaller pieces so that they can be uploaded individually. This makes the upload resilient and also allows the UI to show progress on the upload. So far the other requests we have had for this functionality have not needed slicing capability, but nothing in our proposal precludes adding it (even adding it in a way that's identical to the Gears proposal would be possible). On Thu, Jul 17, 2008 at 4:32 PM, Sam Weinig [EMAIL PROTECTED] wrote: Upload progress is possible without manually slicing using the new upload progress events proposed in the XMLHttpRequest Level 2 spec. Sam's point is good. I forgot that we actually have this in Gears mainly for resumability of large uploads, not for progress (we have implemented upload progress too). I can understand this is less necessary for the initial version. I wonder if it is possible to make resumability more automatic, somewhat like the way If-Range is used to do resumable downloads. But manual slicing does seem like an ok solution. Regards, Maciej
XDomainRequest Integration with AC
I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. Namely, The changes to support the new Access control model is as follows - * Change Referer header set in the request to Origin. * Change the XDomainRequestAllowed header check from it being 1 to check for Access-Control: allow * In addition, I realized that the discussions we had in the F2F (tracked by issue 32 http://www.w3.org/2008/webapps/track/issues/32) means that an access control check is now also performed when the redirect steps are applied to prevent data leakage from intranet pages. This is different from XDR as we currently do the check in the final destination for redirection. I think the reason why we did this in XDR was to allow cross domain resources to move around easily. That said, I'm not religious about this issue either way. (Adding my team-mates to hear if they have any concerns). I'll ask our dev to make the change, but before that I just wanted to confirm the AC spec will be updated with this. Currently I couldn't find this in the updated spec but I could be wrong. Thanks,
RE: XDomainRequest Integration with AC
The specific concern with redirections is that we know of instances where redirection systems are in use that do not currently support addition of custom response headers, and cannot be trivially updated to add such headers. These redirection systems include legacy C++ applications whose source is no longer available; the only possible updates are to the source-destination URLs via a database. I've also heard reports of hardware frontend devices with similar limitations, although I'm not personally aware of a specific device with this limitation. In general, checking the Access-control response header on every hop of a redirection chain may make the access-control specification more difficult to deploy in real-world circumstances. -Eric From: Sunava Dutta Sent: Friday, July 18, 2008 4:21 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn Cc: public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: XDomainRequest Integration with AC I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. Namely, The changes to support the new Access control model is as follows - * Change Referer header set in the request to Origin. * Change the XDomainRequestAllowed header check from it being 1 to check for Access-Control: allow * In addition, I realized that the discussions we had in the F2F (tracked by issue 32 http://www.w3.org/2008/webapps/track/issues/32) means that an access control check is now also performed when the redirect steps are applied to prevent data leakage from intranet pages. This is different from XDR as we currently do the check in the final destination for redirection. I think the reason why we did this in XDR was to allow cross domain resources to move around easily. That said, I'm not religious about this issue either way. (Adding my team-mates to hear if they have any concerns). I'll ask our dev to make the change, but before that I just wanted to confirm the AC spec will be updated with this. Currently I couldn't find this in the updated spec but I could be wrong. Thanks,
Re: XDomainRequest Integration with AC
On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I’m in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas’s proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. I think Anne's email represents the most recent agreement and I don't think anyone has objected: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html The change would be: Instead of checking for XDomainRequestAllowed: 1 check for Access- Control-Allow-Origin: * or Access-Control-Allow-Origin: url where url matches what was sent in the Origin header. Regards, Maciej Namely, The changes to support the new Access control model is as follows – · Change Referer header set in the request to Origin. · Change the XDomainRequestAllowed header check from it being “1” to check for Access-Control: allow * In addition, I realized that the discussions we had in the F2F (tracked by issue 32http://www.w3.org/2008/webapps/track/issues/32) means that an access control check is now also performed when the redirect steps are applied to prevent data leakage from intranet pages. This is different from XDR as we currently do the check in the final destination for redirection. I think the reason why we did this in XDR was to allow cross domain resources to move around easily. That said, I’m not religious about this issue either way. (Adding my team-mates to hear if they have any concerns). I’ll ask our dev to make the change, but before that I just wanted to confirm the AC spec will be updated with this. Currently I couldn’t find this in the updated spec but I could be wrong. Thanks,
Re: XDomainRequest Integration with AC
On Jul 18, 2008, at 4:56 PM, Eric Lawrence wrote: The specific concern with redirections is that we know of instances where redirection systems are in use that do not currently support addition of custom response headers, and cannot be trivially updated to add such headers. These redirection systems include legacy C++ applications whose source is no longer available; the only possible updates are to the source-destination URLs via a database. I’ve also heard reports of hardware frontend devices with similar limitations, although I’m not personally aware of a specific device with this limitation. In general, checking the Access-control response header on every hop of a redirection chain may make the access-control specification more difficult to deploy in real-world circumstances. It seems to me that checking every hop is required to avoid inadvertent information disclosure. If someone has a service (not enabled for Access-Control) which will redirect to the URL of your choice but passing some additional info, then by forcing it to redirect to a URL that does support Access-Control you can access information that you otherwise would not be able to. We should not allow systems that don't opt in to be subject to any information disclosure, and this seems even more essential if these systems cannot be modified. Regards, Maciej -Eric From: Sunava Dutta Sent: Friday, July 18, 2008 4:21 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn Cc: public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: XDomainRequest Integration with AC I’m in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas’s proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. Namely, The changes to support the new Access control model is as follows – · Change Referer header set in the request to Origin. · Change the XDomainRequestAllowed header check from it being “1” to check for Access-Control: allow * In addition, I realized that the discussions we had in the F2F (tracked by issue 32http://www.w3.org/2008/webapps/track/issues/32) means that an access control check is now also performed when the redirect steps are applied to prevent data leakage from intranet pages. This is different from XDR as we currently do the check in the final destination for redirection. I think the reason why we did this in XDR was to allow cross domain resources to move around easily. That said, I’m not religious about this issue either way. (Adding my team-mates to hear if they have any concerns). I’ll ask our dev to make the change, but before that I just wanted to confirm the AC spec will be updated with this. Currently I couldn’t find this in the updated spec but I could be wrong. Thanks,
RE: XDomainRequest Integration with AC
Can you elaborate on the scenario you're concerned about? I cannot think of a scenario matching your description that could not be exploited using HTML4 Forms alone. Thanks! Eric Lawrence Program Manager - IE Security Want to view and tamper with HTTP(S) traffic? Try http://www.fiddler2.comhttp://www.fiddler2.com/ From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 5:07 PM To: Eric Lawrence Cc: Sunava Dutta; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 4:56 PM, Eric Lawrence wrote: The specific concern with redirections is that we know of instances where redirection systems are in use that do not currently support addition of custom response headers, and cannot be trivially updated to add such headers. These redirection systems include legacy C++ applications whose source is no longer available; the only possible updates are to the source-destination URLs via a database. I've also heard reports of hardware frontend devices with similar limitations, although I'm not personally aware of a specific device with this limitation. In general, checking the Access-control response header on every hop of a redirection chain may make the access-control specification more difficult to deploy in real-world circumstances. It seems to me that checking every hop is required to avoid inadvertent information disclosure. If someone has a service (not enabled for Access-Control) which will redirect to the URL of your choice but passing some additional info, then by forcing it to redirect to a URL that does support Access-Control you can access information that you otherwise would not be able to. We should not allow systems that don't opt in to be subject to any information disclosure, and this seems even more essential if these systems cannot be modified. Regards, Maciej -Eric From: Sunava Dutta Sent: Friday, July 18, 2008 4:21 PM To: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]; [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn Cc: public-webapps@w3.orgmailto:public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: XDomainRequest Integration with AC I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. Namely, The changes to support the new Access control model is as follows - * Change Referer header set in the request to Origin. * Change the XDomainRequestAllowed header check from it being 1 to check for Access-Control: allow * In addition, I realized that the discussions we had in the F2F (tracked by issue 32http://www.w3.org/2008/webapps/track/issues/32) means that an access control check is now also performed when the redirect steps are applied to prevent data leakage from intranet pages. This is different from XDR as we currently do the check in the final destination for redirection. I think the reason why we did this in XDR was to allow cross domain resources to move around easily. That said, I'm not religious about this issue either way. (Adding my team-mates to hear if they have any concerns). I'll ask our dev to make the change, but before that I just wanted to confirm the AC spec will be updated with this. Currently I couldn't find this in the updated spec but I could be wrong. Thanks,
Re: XDomainRequest Integration with AC
On Jul 18, 2008, at 5:15 PM, Eric Lawrence wrote: Can you elaborate on the scenario you’re concerned about? I cannot think of a scenario matching your description that could not be exploited using HTML4 Forms alone. Forms do not give you read access to the target of the redirect, whether or not it opts into Access-Control, in the cross-domain case. Regards, Maciej Thanks! Eric Lawrence Program Manager - IE Security Want to view and tamper with HTTP(S) traffic? Try http://www.fiddler2.com From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 5:07 PM To: Eric Lawrence Cc: Sunava Dutta; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 4:56 PM, Eric Lawrence wrote: The specific concern with redirections is that we know of instances where redirection systems are in use that do not currently support addition of custom response headers, and cannot be trivially updated to add such headers. These redirection systems include legacy C++ applications whose source is no longer available; the only possible updates are to the source-destination URLs via a database. I’ve also heard reports of hardware frontend devices with similar limitations, although I’m not personally aware of a specific device with this limitation. In general, checking the Access-control response header on every hop of a redirection chain may make the access-control specification more difficult to deploy in real-world circumstances. It seems to me that checking every hop is required to avoid inadvertent information disclosure. If someone has a service (not enabled for Access-Control) which will redirect to the URL of your choice but passing some additional info, then by forcing it to redirect to a URL that does support Access-Control you can access information that you otherwise would not be able to. We should not allow systems that don't opt in to be subject to any information disclosure, and this seems even more essential if these systems cannot be modified. Regards, Maciej -Eric From: Sunava Dutta Sent: Friday, July 18, 2008 4:21 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn Cc: public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: XDomainRequest Integration with AC I’m in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas’s proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. Namely, The changes to support the new Access control model is as follows – · Change Referer header set in the request to Origin. · Change the XDomainRequestAllowed header check from it being “1” to check for Access-Control: allow * In addition, I realized that the discussions we had in the F2F (tracked by issue 32http://www.w3.org/2008/webapps/track/issues/32) means that an access control check is now also performed when the redirect steps are applied to prevent data leakage from intranet pages. This is different from XDR as we currently do the check in the final destination for redirection. I think the reason why we did this in XDR was to allow cross domain resources to move around easily. That said, I’m not religious about this issue either way. (Adding my team-mates to hear if they have any concerns). I’ll ask our dev to make the change, but before that I just wanted to confirm the AC spec will be updated with this. Currently I couldn’t find this in the updated spec but I could be wrong. Thanks,
RE: XDomainRequest Integration with AC
In the scenario you described, the threat was that there would be information disclosure against an unsuspecting redirector in the middle of a redirection chain. It's not clear to me how providing read-access to the final destination (which must opt-in to such access using an Access-Control response header) would somehow disclose any information about the intermediary redirector? Could you describe a simple step-by-step attack scenario? Thanks a bunch! -Eric From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 6:02 PM To: Eric Lawrence Cc: Sunava Dutta; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 5:15 PM, Eric Lawrence wrote: Can you elaborate on the scenario you're concerned about? I cannot think of a scenario matching your description that could not be exploited using HTML4 Forms alone. Forms do not give you read access to the target of the redirect, whether or not it opts into Access-Control, in the cross-domain case. Regards, Maciej Thanks! Eric Lawrence Program Manager - IE Security Want to view and tamper with HTTP(S) traffic? Try http://www.fiddler2.comhttp://www.fiddler2.com/ From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 5:07 PM To: Eric Lawrence Cc: Sunava Dutta; [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]; [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.orgmailto:public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 4:56 PM, Eric Lawrence wrote: The specific concern with redirections is that we know of instances where redirection systems are in use that do not currently support addition of custom response headers, and cannot be trivially updated to add such headers. These redirection systems include legacy C++ applications whose source is no longer available; the only possible updates are to the source-destination URLs via a database. I've also heard reports of hardware frontend devices with similar limitations, although I'm not personally aware of a specific device with this limitation. In general, checking the Access-control response header on every hop of a redirection chain may make the access-control specification more difficult to deploy in real-world circumstances. It seems to me that checking every hop is required to avoid inadvertent information disclosure. If someone has a service (not enabled for Access-Control) which will redirect to the URL of your choice but passing some additional info, then by forcing it to redirect to a URL that does support Access-Control you can access information that you otherwise would not be able to. We should not allow systems that don't opt in to be subject to any information disclosure, and this seems even more essential if these systems cannot be modified. Regards, Maciej -Eric From: Sunava Dutta Sent: Friday, July 18, 2008 4:21 PM To: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]; [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn Cc: public-webapps@w3.orgmailto:public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: XDomainRequest Integration with AC I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. Namely, The changes to support the new Access control model is as follows - * Change Referer header set in the request to Origin. * Change the XDomainRequestAllowed header check from it being 1 to check for Access-Control: allow * In addition, I realized that the discussions we had in the F2F (tracked by issue 32http://www.w3.org/2008/webapps/track/issues/32) means that an access control check is now also performed when the redirect steps are applied to prevent data leakage from intranet pages. This is different from XDR as we currently do the check in the final destination for redirection. I think the reason why we did this in XDR was to allow cross domain resources to move around easily. That said, I'm not religious about this issue either way. (Adding my team-mates to hear if they have any concerns). I'll ask our dev to make the change, but before that I just wanted to confirm the AC spec will be updated with this. Currently I couldn't find this in the updated spec but I could be wrong. Thanks,
RE: XDomainRequest Integration with AC
Jonas said: 'url' is parsed as an absolute URL using the internal parser used for normal URL parsing, but if the resulting URL contains anything other than scheme, domain and port then access should be denied. I.e. if the url contains a path, a query string a fragment or similar, the header is considered invalid and MUST be ignored. This sounds fine as it reduces surface area of attack. -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 6:58 PM To: Maciej Stachowiak Cc: Sunava Dutta; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. I think Anne's email represents the most recent agreement and I don't think anyone has objected: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html The change would be: Instead of checking for XDomainRequestAllowed: 1 check for Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: url where url matches what was sent in the Origin header. 'url' is parsed as an absolute URL using the internal parser used for normal URL parsing, but if the resulting URL contains anything other than scheme, domain and port then access should be denied. I.e. if the url contains a path, a query string a fragment or similar, the header is considered invalid and MUST be ignored. / Jonas
