Re: ISSUE-4 (SpecContent): Should specifications decide what counts as content for transfer? [Progress Events]
On Sun, 22 Jun 2008 10:32:50 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Bjoern Hoehrmann wrote: * Jonas Sicking wrote: It makes no sense to me to for HTTP say that the total number of bytes should include HTTP headers. It would be similar to including the TCP headers in the IP packets IMHO. There is a big difference here, an application might not have meaningful access to the latter, but would necessarily have meaningful access to the former (even if only to the next hop). I don't see how ability to get hold of one or another makes a difference in determining whether it's the right or the wrong data. There is lots of data available that would be the wrong data, that doesn't change the fact that it's the wrong data. The consequence of not in- cluding headers would be, e.g., that on HEAD requests you would seem to never make any progress. Yes, I agree that this is somewhat unfortunate. Though in reality I doubt that it will matter much since headers are usually small enough that you don't really need progress reports on them. Well, until you get some mobile network crawling along sending an accept header ... Seriously, this is the sort of problem that makes me want to define this as application-specific. Because it makes no sense to me that a GET request counts the returned header as content, but it makes sense to me that a HEAD request does, and I am not sure what makes sense for PUT. Using it for mail, where you are transferring an entire mailbox as a single object it seems natural to count the mail headers, but shifting an individual message I am not so sure... Cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: ElementTraversal progress?
Followup to webapps group please (reply-to set for this mail) On Mon, 02 Jun 2008 23:56:22 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Charles McCathieNevile wrote: On Sat, 31 May 2008 01:05:44 +0200, Jonas Sicking [EMAIL PROTECTED] I wanted to implement the ElementTraversal spec for the next release of firefox (after FF3). However last I heard there was still an outstanding issue of if we wanted to have .childElementCount unsigned long or if we wanted a .childElements NodeList. I guess Doug will pipe up soon, but as I understand things from him he thinks it makes sense to leave the spec as is. Opera, Ikivo and BitFlash are known to have implementations that are believed to be conformant to the current spec. ... In mozilla we would actually even implement the .childElementCount property by keeping a hidden childNodes list internally. But that might be specific to the mozilla implementation. Indeed, it seems from discussing it that it would. Checking back with the implementor at Opera, we would prefer to leave the spec as it is for now, and if necessary write another, even smaller spec that offered the node list functionality if you really want it. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: ElementTraversal progress?
Charles McCathieNevile wrote: Followup to webapps group please (reply-to set for this mail) On Mon, 02 Jun 2008 23:56:22 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Charles McCathieNevile wrote: On Sat, 31 May 2008 01:05:44 +0200, Jonas Sicking [EMAIL PROTECTED] I wanted to implement the ElementTraversal spec for the next release of firefox (after FF3). However last I heard there was still an outstanding issue of if we wanted to have .childElementCount unsigned long or if we wanted a .childElements NodeList. I guess Doug will pipe up soon, but as I understand things from him he thinks it makes sense to leave the spec as is. Opera, Ikivo and BitFlash are known to have implementations that are believed to be conformant to the current spec. ... In mozilla we would actually even implement the .childElementCount property by keeping a hidden childNodes list internally. But that might be specific to the mozilla implementation. Indeed, it seems from discussing it that it would. Checking back with the implementor at Opera, we would prefer to leave the spec as it is for now, and if necessary write another, even smaller spec that offered the node list functionality if you really want it. What about the issue I raised here: http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0214.html Which no one replied to. If you implement the HTML DOM you should already have code that not only filters out elements, but even filters out elements of a specific name. Seems like that code should be reusable? / Jonas
Re: New: Tracking Issues in XHR that we raised
Zhenbin Xu wrote: It should be revised to: responseText: If the state is not DONE, raise an INVALID_STATE_ERR exception and terminate these steps. This doesn't seem very consistent with the other response properties though. Seems like .getResponseHeader and .getAllResponseHeaders work fine (without throwing) even in state HEADERS_RECEIVED and LOADING, so it seems better to let .responseText work fine there too. Additionally, our API has for a long time been defined such that you can read .responseText all through the LOADING state in order to read streaming data. This has been advertised to authors so I would expect them to depend on that at this point and so if we started throwing here I would expect websites to stop working. This makes even more sense in XHR2 when we have progress events and so the site gets notified as data comes in. (In fact, this is already the case in firefox where you get onreadystatechange notifications for the LOADING state every time data is received. We hope to change this to reflect the specification and use progress events as appropriate instead in FF3.1) However throwing in the UNSENT and OPENED states are fine with me. responseXML: If the state is not at least OPENED, raise an INVALID_STATE_ERR exception and terminate these steps. I think we additionally need to throw in the OPENED state. Until all headers are received there is no way to know what document, if any, should be created so we need to either return null or throw until we're in state HEADERS_RECEIVED. Though it does seem scary to start throwing in more states for this property as throwing more tends to break sites. So possibly we would have to go with returning null in the OPENED state even though that would be inconsistent with the other properties. On a related note: Can we specify exactly when .status and .statusText should throw? Currently the spec says to throw if not available which seems very implementation specific. If we say that it should throw unless the state is at least HEADERS_RECEIVED that should make things consistent. Note that this would be unlikely to break sites due to more throwing. As things stand now the property is likely throw during the start of the OPENED state, but at some point during the state stop throwing and return a real result. So sites can't count on that happening at any predictable time before we're in the HEADERS_RECEIVED state anyway. / Jonas / Jonas
Re: ISSUE-4 (SpecContent): Should specifications decide what counts as content for transfer? [Progress Events]
Charles McCathieNevile wrote: On Sun, 22 Jun 2008 10:32:50 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Bjoern Hoehrmann wrote: * Jonas Sicking wrote: It makes no sense to me to for HTTP say that the total number of bytes should include HTTP headers. It would be similar to including the TCP headers in the IP packets IMHO. There is a big difference here, an application might not have meaningful access to the latter, but would necessarily have meaningful access to the former (even if only to the next hop). I don't see how ability to get hold of one or another makes a difference in determining whether it's the right or the wrong data. There is lots of data available that would be the wrong data, that doesn't change the fact that it's the wrong data. The consequence of not in- cluding headers would be, e.g., that on HEAD requests you would seem to never make any progress. Yes, I agree that this is somewhat unfortunate. Though in reality I doubt that it will matter much since headers are usually small enough that you don't really need progress reports on them. Well, until you get some mobile network crawling along sending an accept header ... Seriously, this is the sort of problem that makes me want to define this as application-specific. Because it makes no sense to me that a GET request counts the returned header as content, but it makes sense to me that a HEAD request does, and I am not sure what makes sense for PUT. Using it for mail, where you are transferring an entire mailbox as a single object it seems natural to count the mail headers, but shifting an individual message I am not so sure... Is anyone ever going to be able to get any useful size data for the headers anyway though? I.e. if we allow headers to be counted as part of the size, is anyone ever going to be able to do that? To be able to do that you'd have to have some sort of out-of-band metadata that travells parallel to the TCP/IP connection since the TCP/IP connection is busy transferring HTTP which doesn't contain this information. I guess you could use just the 'bytes downloaded so far' part just to show that progress is made, but that would mix very strangly if you then received a body which you did have a size for. Anyhow, I guess I don't care that much about this as it won't affect any actual implementations for the web at least for now. And I think in reality most people will not include the headers due to all the strangness mentioned above if you did include the headers. So feel free to go ahead either way on this. / Jonas
Agenda and logistics...
Hi folks, the agenda and logistics page for the meeting will be shortly available to working group members (Sunava, can you please ask your AC rep to ensure that you guys have joined by the time we have the meeting?). I have one question - although I am the chair, and the co-chair is not going to be available for this meeting, I am unable to be there for the first morning since I will be taking a horror flight from Boston and arriving at SEA-TAC just after 10am inshallah. I am equally happy to have someone else chair the meeting in my absence (that's something we expect Staff contacts to be able to do...) or to postpone the start until lunchtime, depending on how people feel. The agenda for the meeting is pretty basic, covering XHR1 and XHR2 with Access Control, and the issues raised in MS' review of XHR2. Hopefully Mike will manage the right W3C mojo soon and announce the page with the information. Cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
RE: Agenda and logistics...
I am fine with the first meeting starting after lunchtime. It gives us a chance to chat with members and mingle before we get down to the meat and potatoes! -Original Message- From: [EMAIL PROTECTED] [mailto:public-webapps- [EMAIL PROTECTED] On Behalf Of Charles McCathieNevile Sent: Monday, June 23, 2008 11:24 AM To: Webapps Cc: Sunava Dutta Subject: Agenda and logistics... Hi folks, the agenda and logistics page for the meeting will be shortly available to working group members (Sunava, can you please ask your AC rep to ensure that you guys have joined by the time we have the meeting?). I have one question - although I am the chair, and the co-chair is not going to be available for this meeting, I am unable to be there for the first morning since I will be taking a horror flight from Boston and arriving at SEA-TAC just after 10am inshallah. I am equally happy to have someone else chair the meeting in my absence (that's something we expect Staff contacts to be able to do...) or to postpone the start until lunchtime, depending on how people feel. The agenda for the meeting is pretty basic, covering XHR1 and XHR2 with Access Control, and the issues raised in MS' review of XHR2. Hopefully Mike will manage the right W3C mojo soon and announce the page with the information. Cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
ISSUE-10 (client-server): Client and Server model [Access Control]
ISSUE-10 (client-server): Client and Server model [Access Control] http://www.w3.org/2008/webapps/track/issues/ Raised by: Arthur Barstow On product: Access Control [[ This issue was created on 2008-01-04 as Issue #20 in the Web Applications Formats (WAF) WG and is copied in totality to the Web Applications WG's Issues database: http://www.w3.org/2005/06/tracker/waf/issues/20 ]] Issues have been raised regarding client (i.e. browser) versus server aspects of the model. For example, would it better and simple for the policy enforcement point to be the server rather than the client, etc. On 20 December 2007, Tyler Close raised this issue via: http://lists.w3.org/Archives/Public/public-appformats/2007Dec/0054.html There were several relevant follow-ups, including but not limited to: http://lists.w3.org/Archives/Public/public-appformats/2007Dec/0068.html http://lists.w3.org/Archives/Public/public-appformats/2007Dec/0071.html http://lists.w3.org/Archives/Public/public-appformats/2008Jan/.html http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0004.html http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0010.html http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0018.html http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0032.html Related issues were also raised on 5 November 2007 during WG's f2f meeting that included members of the Web Security Context WG and the XML Security Spec Maintenance WG: http://www.w3.org/2007/11/05-waf-minutes.html#item09
Re: IRC logging
* Gavin Sharp wrote: It does seem quite unreasonable. Why do you think it would be a serious breach of protocol? Which protocol? Making approval of logging contingent on the presence of the bot in channel seems rather arbitrary. Why not just say that approval for logging is implicit for anyone present in the channel, at any time? If the decision is made to log the channel, I don't see why it should matter whether it is logged directly to the web by the bot, or via someone else's private logs which are later published (e.g. if the bot is offline due to network issues). I wasn't giving my opinion, I was sharing my experience that, just be- cause some IRC channel has public logs, that everybody automatically approves of complementing the logs using private logs gathered when the normal logger was absent--and it is therefore wise to either ensure the continuous presence of it, or explicitly ask for participants approval when necessary. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
ISSUE-11 (security-model): What is the Security Model for the access-control spec? [Access Control]
ISSUE-11 (security-model): What is the Security Model for the access-control spec? [Access Control] http://www.w3.org/2008/webapps/track/issues/ Raised by: Arthur Barstow On product: Access Control [[ This issue was created on 2008-01-15 as Issue #21 in the Web Applications Formats (WAF) WG and is copied in totality to the Web Applications WG's Issues database: http://www.w3.org/2005/06/tracker/waf/issues/21 ]] The AC4CSR spec is missing a description of its Security Model. For example, what is the threat model for attacks such as CSRF, XSS, etc. This issue was raised by the WSC WG during its joint f2f meeting with the WAF WG on 5 November 2007: http://www.w3.org/2007/11/05-waf-minutes.html#item09 It has also been a subject of discussion within e-mail exchanges on the public-appformats mail list: http://lists.w3.org/Archives/Public/public-appformats/
ISSUE-12 (access-control-policy-path): IIS and Access-Control-Policy-Path [Access Control]
ISSUE-12 (access-control-policy-path): IIS and Access-Control-Policy-Path [Access Control] http://www.w3.org/2008/webapps/track/issues/ Raised by: Anne van Kesteren On product: Access Control [[ This issue was created on 2008-06-06 as Issue #25 in the Web Applications Formats (WAF) WG and is copied in totality to the Web Applications WG's Issues database: http://www.w3.org/2005/06/tracker/waf/issues/25 ]] IIS servers have an issue in that resources can be addressed by several distinct URIs as explained in this e-mail: http://lists.w3.org/Archives/Public/public-appformats/2008May/0039.html This impacts the design of Access-Control-Policy-Path to some extent. Two proposals have been put forward by members of the WG to address this issue: A. If a URI (also one given during redirects, etc.) contains the \.. sequence (or the escaped form) apply the generic network error steps. B. Warn against using the Access-Control-Policy-Path feature in servers that exhibit this behavior.
ISSUE-13 (opting-into-cookies): Opting into cookies [Access Control]
ISSUE-13 (opting-into-cookies): Opting into cookies [Access Control] http://www.w3.org/2008/webapps/track/issues/ Raised by: Anne van Kesteren On product: Access Control [[ This issue was created on 2008-06-06 as Issue #26 in the Web Applications Formats (WAF) WG and is copied in totality to the Web Applications WG's Issues database: http://www.w3.org/2005/06/tracker/waf/issues/26 ]] It has been suggested that because Access-Control also allows read access and not just making the request explicit optin into cookies specifically is desired. The benefit would be that servers can more safely enable Access Control functionality. The drawback would be that the model becomes more complicated and therefore more prone to errors and implementation bugs. +++ Addition by Barstow 2008-06-06 Jonas submitted the following e-mail which contains three proposals to address this issue: http://lists.w3.org/Archives/Public/public-appformats/2008May/0144.html
ISSUE-14 (opt-into-methods-headers): Opting into methods/headers [Access Control]
ISSUE-14 (opt-into-methods-headers): Opting into methods/headers [Access Control] http://www.w3.org/2008/webapps/track/issues/ Raised by: Anne van Kesteren On product: Access Control [[ This issue was created on 2008-06-06 as Issue #27 in the Web Applications Formats (WAF) WG and is copied in totality to the Web Applications WG's Issues database: http://www.w3.org/2005/06/tracker/waf/issues/27 ]] The current Access Control model allows all methods to be used and all headers (apart from a blacklist and some headers require a preflight request in case of GET). There is a proposal to only allow methods and headers the server has opted into: [AC] Helping server admins not making mistakes http://lists.w3.org/Archives/Public/public-appformats/2008May/0034.html This would make the server more secure by default when opting into Access Control. The drawback is again that it makes the model more complicated and more prone to bugs.
Re: ISSUE-4 (SpecContent): Should specifications decide what counts as content for transfer? [Progress Events]
* Jonas Sicking wrote: Is anyone ever going to be able to get any useful size data for the headers anyway though? I.e. if we allow headers to be counted as part of the size, is anyone ever going to be able to do that? To be able to do that you'd have to have some sort of out-of-band metadata that travells parallel to the TCP/IP connection since the TCP/IP connection is busy transferring HTTP which doesn't contain this information. I guess you could use just the 'bytes downloaded so far' part just to show that progress is made, but that would mix very strangly if you then received a body which you did have a size for. You do not know the length of the header while you are reading it, and you may not know the length of the body while reading it. In both cases you would signify that the length is not computable and only report the amout that has been transferred so far. If the length of the body is known, you would signify that after reading the header, and set total to the length of the message (header + rest) that has been read so far. Do note that e.g. with Transfer-Encoding:chunked you do not know the length of the body until you finished reading it. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Opting in to cookies - proposal
* Jonas Sicking wrote: I'm not quite following what you are asking here. My proposal is about giving a site the ability to enable two modes of Access-Control: 1. Allow a third-party site to read the data on this resource, and/or perform unsafe methods in HTTP requests to this resource. When these requests are sent any cookie and/or auth headers (for the resource) are included in the request, just as if had been a same-site XHR request. 2. Same as above, but requests never include cookies or auth headers are never included. In the spec currently only mode 1 is possible. I suggest that we make mode 2 possible as well. I guess you can call it opting out of cookies as well... I am proposing that there be only a single mode unless it can clearly be demonstrated that having two modes would be a substantial net gain. As far as I am aware, this has not been established for a with-cookie mode if the no-cookie mode is the default, and my questions focus on learning more about the with-cookie mode. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
[XHR2] upload complete flag
Hi all, the draft says that the initial value for upload complete flag is false and then there are several ways to get it set to true. But when is the value set back to false if XHR object is reused? Perhaps '3.5.3 Initiating a Request', right after step 2? -Olli
Re: ISSUE-10 (client-server): Client and Server model [Access Control]
I don't think we have seen any alternative proposals for putting the policy *enforcement* on the server. It also seems very hard to me to rely on the server enforcing the policy, while still protecting legacy servers, since they currently do not perform any such enforcement. What I have seen suggestions for though is a simpler policy language that doesn't send a full white-list to the client, but rather just a yes/no decision to the client. / Jonas
Re: ISSUE-10 (client-server): Client and Server model [Access Control]
On Mon, Jun 23, 2008 at 2:35 PM, Jonas Sicking [EMAIL PROTECTED] wrote: What I have seen suggestions for though is a simpler policy language that doesn't send a full white-list to the client, but rather just a yes/no decision to the client. If we go this route, we should be careful about caching of HTTP responses, especially for GET requests. We don't want clients to use cached yes responses without consulting the server. Adam
RE: Agenda and logistics...
Thanks for the info. Chris is working on getting us signed up before the meeting! Meanwhile, I'm fine with a Tues noon start. I've also requested we discuss our feedback on AC on Tuesday as Eric, our security PM is out of office Wed and Thursday. Let me know what we finally decide on both topics. Meanwhile, may I suggest we have a solid dinner to mark the end of the F2F and the July 4th weekend courtesy the IE team? (I can personally vouch for the place) Here's what I propose, let me know if there's anything else attendees would prefer? http://www.maggianos.com/foodbeverage/default.asp?menu=Family%20Style%20Dinner -Original Message- From: [EMAIL PROTECTED] [mailto:public-webapps- [EMAIL PROTECTED] On Behalf Of Charles McCathieNevile Sent: Monday, June 23, 2008 11:24 AM To: Webapps Cc: Sunava Dutta Subject: Agenda and logistics... Hi folks, the agenda and logistics page for the meeting will be shortly available to working group members (Sunava, can you please ask your AC rep to ensure that you guys have joined by the time we have the meeting?). I have one question - although I am the chair, and the co-chair is not going to be available for this meeting, I am unable to be there for the first morning since I will be taking a horror flight from Boston and arriving at SEA-TAC just after 10am inshallah. I am equally happy to have someone else chair the meeting in my absence (that's something we expect Staff contacts to be able to do...) or to postpone the start until lunchtime, depending on how people feel. The agenda for the meeting is pretty basic, covering XHR1 and XHR2 with Access Control, and the issues raised in MS' review of XHR2. Hopefully Mike will manage the right W3C mojo soon and announce the page with the information. Cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Element Nodelist - ISSUE-6 (was: ElementTraversal progress?)
Hi, Jonas, Daniel- Jonas Sicking wrote (on 6/23/08 2:03 PM): What about the issue I raised here: http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0214.html Which no one replied to. If you implement the HTML DOM you should already have code that not only filters out elements, but even filters out elements of a specific name. Seems like that code should be reusable? For an HTML UA, yes, that makes perfect sense. But there is concept of that in SVG, for example, so for an SVG-only UA that would still be an additional implementation (and memory) cost. I intend to make a make a separate spec that also provides a nodelist for Element nodes, so we won't be losing the nodelist feature, just deferring it (and not for long, at that). Those UAs which want to implement both Element Traversal and Element Nodelist can do so; those that don't yet aren't burdened with implementing Element Nodelist (though as devices mature, I'm sure they'll want to do both). The other issue at stake here is the coordination between W3C and JSRs. While this doesn't have a direct impact on desktop browser vendors, it does affect the current mobile Web sphere, where Java is widely deployed. The better aligned the JSRs can be to core W3C technologies, the more robust the entire Open Web Stack is for content developers and users. This is important enough that it is worth a small amount of extra standardization effort to facilitate that. I will create an Element Nodelist specification right away, and if it is approved to go forward (and I don't see why it wouldn't be, since there is considerable support), I am confident that this would not slow down deployment in desktop browsers, and so authors should be able to use it in the same timeframe as Element Traversal. I hope this resolves your issue satisfactorily. Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF
RE: Agenda and logistics...
The meeting says Tuesday through Thursday 24th - 26 June 2008 in the Overview section. I just had a heart attack till I realized that's probably (keeping fingers crossed) a mistake?? -:) -Original Message- From: Michael(tm) Smith [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2008 11:48 AM To: Webapps Cc: Charles McCathieNevile; Sunava Dutta Subject: Re: Agenda and logistics... The meeting page is now online and member visible: http://www.w3.org/2008/webapps/Group/f2f0807.html Charles McCathieNevile [EMAIL PROTECTED], 2008-06-23 20:23 +0200: Hi folks, the agenda and logistics page for the meeting will be shortly available to working group members (Sunava, can you please ask your AC rep to ensure that you guys have joined by the time we have the meeting?). I have one question - although I am the chair, and the co-chair is not going to be available for this meeting, I am unable to be there for the first morning since I will be taking a horror flight from Boston and arriving at SEA-TAC just after 10am inshallah. I am equally happy to have someone else chair the meeting in my absence (that's something we expect Staff contacts to be able to do...) or to postpone the start until lunchtime, depending on how people feel. The agenda for the meeting is pretty basic, covering XHR1 and XHR2 with Access Control, and the issues raised in MS' review of XHR2. Hopefully Mike will manage the right W3C mojo soon and announce the page with the information. Cheers Chaals -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/
Re: Opting in to cookies - proposal
Bjoern Hoehrmann wrote: * Jonas Sicking wrote: I'm not quite following what you are asking here. My proposal is about giving a site the ability to enable two modes of Access-Control: 1. Allow a third-party site to read the data on this resource, and/or perform unsafe methods in HTTP requests to this resource. When these requests are sent any cookie and/or auth headers (for the resource) are included in the request, just as if had been a same-site XHR request. 2. Same as above, but requests never include cookies or auth headers are never included. In the spec currently only mode 1 is possible. I suggest that we make mode 2 possible as well. I guess you can call it opting out of cookies as well... I am proposing that there be only a single mode unless it can clearly be demonstrated that having two modes would be a substantial net gain. As far as I am aware, this has not been established for a with-cookie mode if the no-cookie mode is the default, and my questions focus on learning more about the with-cookie mode. Not sure if there is much of a 'default' mode no matter what, since it's the website that chooses if it wants to receive cookies or not. But anyway... Allowing with cookies has obvious benefits. It allows the target size to know which user data is requested for. So if the requesting site is trusted by the target site, the target site can send user-private data (note, this trust has to be established out-of-band from the spec, usually by the target site asking the user) and know which users data to send. Additionally, this is done without needing to entrust the requesting site with any user credentials. It also neatly integrates with security solutions inside ASP, PHP, etc without having to deploy a new infrastructure to handle these things. Allowing without cookies gives websites that want to publish public data a tool to significantly safer opt in to Access-Control without having to worry about accidentally leaking users private data. Accidentally leaking private data can happen in two instances that I can think of: * The operator opts in to AC on a subsection of the site forgetting that somewhere deeply nested is a form with CRSF protection which isn't supposed to be readable cross-site. Or there is a resource that serves user-private data which isn't supposed to be readable cross-site. * The operator opts in to AC on a URI that mostly serves public data, but forgets that if the user is logged in the URI also serves some user-private data. I do admit that I do not yet know how likely it is that operators will make any of the mistakes listed above, so I can't give an exact cost/benefit analysis. / Jonas
Re: Element Nodelist - ISSUE-6
Sounds good to me. / Jonas Doug Schepers wrote: Hi, Jonas, Daniel- Jonas Sicking wrote (on 6/23/08 2:03 PM): What about the issue I raised here: http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0214.html Which no one replied to. If you implement the HTML DOM you should already have code that not only filters out elements, but even filters out elements of a specific name. Seems like that code should be reusable? For an HTML UA, yes, that makes perfect sense. But there is concept of that in SVG, for example, so for an SVG-only UA that would still be an additional implementation (and memory) cost. I intend to make a make a separate spec that also provides a nodelist for Element nodes, so we won't be losing the nodelist feature, just deferring it (and not for long, at that). Those UAs which want to implement both Element Traversal and Element Nodelist can do so; those that don't yet aren't burdened with implementing Element Nodelist (though as devices mature, I'm sure they'll want to do both). The other issue at stake here is the coordination between W3C and JSRs. While this doesn't have a direct impact on desktop browser vendors, it does affect the current mobile Web sphere, where Java is widely deployed. The better aligned the JSRs can be to core W3C technologies, the more robust the entire Open Web Stack is for content developers and users. This is important enough that it is worth a small amount of extra standardization effort to facilitate that. I will create an Element Nodelist specification right away, and if it is approved to go forward (and I don't see why it wouldn't be, since there is considerable support), I am confident that this would not slow down deployment in desktop browsers, and so authors should be able to use it in the same timeframe as Element Traversal. I hope this resolves your issue satisfactorily. Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF
Re: Agenda and logistics...
On Jun 23, 2008, at 11:23 AM, Charles McCathieNevile wrote: Hi folks, the agenda and logistics page for the meeting will be shortly available to working group members (Sunava, can you please ask your AC rep to ensure that you guys have joined by the time we have the meeting?). I would like to request an additional agenda item. There is already a block of time for discussing Microsoft's feedback on XHR2+AC. I would like to request a separate block of time for discussion among those looking to implement or use XHR2+AC, so that we can come to rough consensus on the key remaining open issues. Since Microsoft has announced that they plan to stick with XDR (http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx ), I assume they are not interested in being part of this consensus. But I still think we need to have this item on the agenda, and of course representatives from Microsoft are welcome to observe this discussion. With XHR2+AC implementations in progress in the WebKit and Gecko engines, we need to make sure that we are on track to deliver a secure and interoperable solution in upcoming releases. Perhaps we could devote a day or half day to this topic, rather than devoting 2 days to XHR1 issues. Perhaps (given Microsoft's request) we can discuss Microsoft's feedback on Tuesday, XHR2+AC issues on Wednesday, and XHR1 issues on Thursday. Regards, Maciej
Re: Initial input for discussion of Widget security model
On Thu, May 1, 2008 at 1:33 AM, Arve Bersvendsen [EMAIL PROTECTED] wrote: Attached is a document providing some initial input on a security model for a widget, that should provide a rough draft for providing the/a widget security model. Note that the document is not to be treated as input for specification text, and it needs substantial work and review before any such thing can take place. I'm just wondering how we should proceed with the Security input? My preference has always been to create a Widgets 1.0: Security spec. However, we need someone to edit it. I am willing to help edit it, but would not want to take a leading editorial role. kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Agenda and logistics...
Hi, Folks- Fixed. Sunava, you can put away the heart meds. :) -Doug Charles McCathieNevile wrote (on 6/24/08 12:10 AM): On Tue, 24 Jun 2008 01:30:39 +0200, Sunava Dutta [EMAIL PROTECTED] wrote: The meeting says Tuesday through Thursday 24th - 26 June 2008 in the Overview section. I just had a heart attack till I realized that's probably (keeping fingers crossed) a mistake?? -:) Oops, sorry. It is indeed. I thought I had got all of those dates (there were half a dozen) changed. I'll fix and send mike a new version to post... -Original Message- From: Michael(tm) Smith [mailto:[EMAIL PROTECTED] ... The meeting page is now online and member visible: http://www.w3.org/2008/webapps/Group/f2f0807.html
Re: Agenda and logistics...
On Tue, 24 Jun 2008 03:43:38 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Jun 23, 2008, at 11:23 AM, Charles McCathieNevile wrote: Hi folks, the agenda and logistics page for the meeting will be shortly available to working group members (Sunava, can you please ask your AC rep to ensure that you guys have joined by the time we have the meeting?). I would like to request an additional agenda item. There is already a block of time for discussing Microsoft's feedback on XHR2+AC. I would like to request a separate block of time for discussion among those looking to implement or use XHR2+AC, so that we can come to rough consensus on the key remaining open issues. Sorry, I wasn't that clear, but that is what I meant in the agenda on day 3, by XHR specs. Since Microsoft has announced that they plan to stick with XDR (http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx ), I assume they are not interested in being part of this consensus. But I still think we need to have this item on the agenda, and of course representatives from Microsoft are welcome to observe this discussion. Assuming they have made the patent policy commitment and joined the group by then they are even welcome to take part ;) Perhaps we could devote a day or half day to this topic, rather than devoting 2 days to XHR1 issues. Perhaps (given Microsoft's request) we can discuss Microsoft's feedback on Tuesday, XHR2+AC issues on Wednesday, and XHR1 issues on Thursday. Yep. I am waiting for people to comment on whether they are happy to roll up about 11 on Tuesday, or would prefer to have the meeting start early without me - I am happy either way, but so far only Sunava has actually made a clear statement so I am looking for a couple more concrete answers - then I will update the agenda properly too. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: Element Nodelist - ISSUE-6
Doug Schepers wrote: I will create an Element Nodelist specification right away, and if it is approved to go forward (and I don't see why it wouldn't be, since there is considerable support), I am confident that this would not slow down deployment in desktop browsers, and so authors should be able to use it in the same timeframe as Element Traversal. I hope this resolves your issue satisfactorily. A new spec just for that seems to me a steamroller to kill a fly, but as soon as I have the feature, bah. Go ahead. Thanks. /Daniel
