Re: Do we need to rename the Origin header?
Ian Hickson wrote on 5/24/2010 7:55 PM: On Mon, 24 May 2010, Bil Corry wrote: Adam Barth wrote on 7/16/2009 10:38 AM: On Thu, Jul 16, 2009 at 8:47 AM, Bil Corryb...@corry.biz wrote: I think you mean everything will NOT be privacy-sensitive except non-XHR GETs. I don't think we've quite settled on exactly what will be privacy sensitive. It's most likely that POSTs and XHR will not be and that hyperlinks and image loads will be. The goal is to harmonize with the Mozilla proposal. I haven't been following the progress of this, has privacy-sensitive been defined in HTML5 yet? Yes. The only reference I could find was in 2.6 Fetching Resources: ---8--- For the purposes of the Origin header, if the fetching algorithm was explicitly initiated from an origin, then the origin that initiated the HTTP request is origin. Otherwise, this is a request from a privacy-sensitive context. [ORIGIN] (from: http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#fetching-resources) ---8--- That is the definition. To clarify, the Origin header is sent for all requests now, except those that don't have an origin? The Origin header is sent for GET, POST, XHR, and CORS? - Bil
Re: Do we need to rename the Origin header?
On Mon, 24 May 2010, Bil Corry wrote: The only reference I could find was in 2.6 Fetching Resources: ---8--- For the purposes of the Origin header, if the fetching algorithm was explicitly initiated from an origin, then the origin that initiated the HTTP request is origin. Otherwise, this is a request from a privacy-sensitive context. [ORIGIN] (from: http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#fetching-resources) ---8--- That is the definition. To clarify, the Origin header is sent for all requests now, except those that don't have an origin? The Origin header is sent for GET, POST, XHR, and CORS? It's sent for all invocations of the fetch algorithm in the HTML5 spec that explicitly specify that they come from a specific origin. Examples of invocations that include an explicit origin are the GET for a script src, the GET for video src and source src, and the POST done for the ping= attribute. Examples of invocations that do not include an explicit origin include the GET for an application cache manifest, the GET for img src=, and the POST done by a user agent user interface element. For precise details please see the spec itself. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Do we need to rename the Origin header?
Adam Barth wrote on 7/16/2009 10:38 AM: On Thu, Jul 16, 2009 at 8:47 AM, Bil Corryb...@corry.biz wrote: I think you mean everything will NOT be privacy-sensitive except non-XHR GETs. I don't think we've quite settled on exactly what will be privacy sensitive. It's most likely that POSTs and XHR will not be and that hyperlinks and image loads will be. The goal is to harmonize with the Mozilla proposal. I haven't been following the progress of this, has privacy-sensitive been defined in HTML5 yet? The only reference I could find was in 2.6 Fetching Resources: ---8--- For the purposes of the Origin header, if the fetching algorithm was explicitly initiated from an origin, then the origin that initiated the HTTP request is origin. Otherwise, this is a request from a privacy-sensitive context. [ORIGIN] (from: http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#fetching-resources) ---8--- - Bil
Re: Do we need to rename the Origin header?
On Mon, 24 May 2010, Bil Corry wrote: Adam Barth wrote on 7/16/2009 10:38 AM: On Thu, Jul 16, 2009 at 8:47 AM, Bil Corryb...@corry.biz wrote: I think you mean everything will NOT be privacy-sensitive except non-XHR GETs. I don't think we've quite settled on exactly what will be privacy sensitive. It's most likely that POSTs and XHR will not be and that hyperlinks and image loads will be. The goal is to harmonize with the Mozilla proposal. I haven't been following the progress of this, has privacy-sensitive been defined in HTML5 yet? Yes. The only reference I could find was in 2.6 Fetching Resources: ---8--- For the purposes of the Origin header, if the fetching algorithm was explicitly initiated from an origin, then the origin that initiated the HTTP request is origin. Otherwise, this is a request from a privacy-sensitive context. [ORIGIN] (from: http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#fetching-resources) ---8--- That is the definition. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Do we need to rename the Origin header?
Ian Hickson wrote on 7/15/2009 4:53 PM: On Wed, 15 Jul 2009, Bil Corry wrote: Ian Hickson wrote on 7/14/2009 6:37 PM: On Tue, 14 Jul 2009, Bil Corry wrote: Ian Hickson wrote on 7/14/2009 12:49 AM: (Trimmed cc list to avoid cross-posting.) On Thu, 25 Jun 2009, Bil Corry wrote: Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). I have no plans to add such a feature at this time, but I suppose if Sec-From becomes popular, we could add it at some future point, sure. The Sec-From draft relies on the adopter to define what constitutes privacy-sensitive -- will you be adding this definition to HTML5? HTML5 will say whatever Adam tells me it should say once the draft is stable. Given that identical requests may or may not be privacy-sensitive based entirely on context[1], and given that only the site itself understands the context, and given that HTML5 will not provide a way for the author to denote the context, we're left with Adam's default definition which may or may not be appropriate for any given request. We should revisit this once Adam has defined privacy-sensitive. I expect that what Adam will tell me to do is to make everything in HTML5 privacy-sensitive except GETs. I expect XHR GETs will not be. I think you mean everything will NOT be privacy-sensitive except non-XHR GETs. - Bil
Re: Do we need to rename the Origin header?
On Thu, Jul 16, 2009 at 8:47 AM, Bil Corryb...@corry.biz wrote: I think you mean everything will NOT be privacy-sensitive except non-XHR GETs. I don't think we've quite settled on exactly what will be privacy sensitive. It's most likely that POSTs and XHR will not be and that hyperlinks and image loads will be. The goal is to harmonize with the Mozilla proposal. Adam
Re: Do we need to rename the Origin header?
Ian Hickson wrote on 7/14/2009 6:37 PM: On Tue, 14 Jul 2009, Bil Corry wrote: Ian Hickson wrote on 7/14/2009 12:49 AM: (Trimmed cc list to avoid cross-posting.) On Thu, 25 Jun 2009, Bil Corry wrote: Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). I have no plans to add such a feature at this time, but I suppose if Sec-From becomes popular, we could add it at some future point, sure. The Sec-From draft relies on the adopter to define what constitutes privacy-sensitive -- will you be adding this definition to HTML5? HTML5 will say whatever Adam tells me it should say once the draft is stable. Given that identical requests may or may not be privacy-sensitive based entirely on context[1], and given that only the site itself understands the context, and given that HTML5 will not provide a way for the author to denote the context, we're left with Adam's default definition which may or may not be appropriate for any given request. We should revisit this once Adam has defined privacy-sensitive. - Bil [1] Jonas Sicking does an excellent job of explaining the thorny issue of privacy-sensitive and context in this post: http://www.mail-archive.com/public-webapps@w3.org/msg04001.html
Re: Do we need to rename the Origin header?
On Wed, 15 Jul 2009, Bil Corry wrote: Ian Hickson wrote on 7/14/2009 6:37 PM: On Tue, 14 Jul 2009, Bil Corry wrote: Ian Hickson wrote on 7/14/2009 12:49 AM: (Trimmed cc list to avoid cross-posting.) On Thu, 25 Jun 2009, Bil Corry wrote: Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). I have no plans to add such a feature at this time, but I suppose if Sec-From becomes popular, we could add it at some future point, sure. The Sec-From draft relies on the adopter to define what constitutes privacy-sensitive -- will you be adding this definition to HTML5? HTML5 will say whatever Adam tells me it should say once the draft is stable. Given that identical requests may or may not be privacy-sensitive based entirely on context[1], and given that only the site itself understands the context, and given that HTML5 will not provide a way for the author to denote the context, we're left with Adam's default definition which may or may not be appropriate for any given request. We should revisit this once Adam has defined privacy-sensitive. I expect that what Adam will tell me to do is to make everything in HTML5 privacy-sensitive except GETs. I expect XHR GETs will not be. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Do we need to rename the Origin header?
Ian Hickson wrote on 7/14/2009 12:49 AM: (Trimmed cc list to avoid cross-posting.) On Thu, 25 Jun 2009, Bil Corry wrote: Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). I have no plans to add such a feature at this time, but I suppose if Sec-From becomes popular, we could add it at some future point, sure. The Sec-From draft relies on the adopter to define what constitutes privacy-sensitive -- will you be adding this definition to HTML5? - Bil
Re: Do we need to rename the Origin header?
On Tue, 14 Jul 2009, Bil Corry wrote: Ian Hickson wrote on 7/14/2009 12:49 AM: (Trimmed cc list to avoid cross-posting.) On Thu, 25 Jun 2009, Bil Corry wrote: Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). I have no plans to add such a feature at this time, but I suppose if Sec-From becomes popular, we could add it at some future point, sure. The Sec-From draft relies on the adopter to define what constitutes privacy-sensitive -- will you be adding this definition to HTML5? HTML5 will say whatever Adam tells me it should say once the draft is stable. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Do we need to rename the Origin header?
(Trimmed cc list to avoid cross-posting.) On Thu, 25 Jun 2009, Bil Corry wrote: Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). I have no plans to add such a feature at this time, but I suppose if Sec-From becomes popular, we could add it at some future point, sure. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Denoting privacy-sensitive requests (was: Re: Do we need to rename the Origin header?)
Jonas Sicking wrote on 6/25/2009 5:35 PM: On Thu, Jun 25, 2009 at 8:10 AM, Bil Corryb...@corry.biz wrote: Jonas Sicking wrote on 6/25/2009 2:11 AM: On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote: On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? That's correct. Hopefully folks writing specs at the application layer will coordinate so as not to make the web platform any more confusing than it is already. :) To make it clear what the intent is here: We know that people are building web applications where GET requests cause state changes on the server side. While this is unfortunate, we don't believe that people will stop. Thus we sometimes want Sec-From to be included in GET requests. At the same time, it's a quite common practice on the web today for sites to allow other users to put a href=... links on their site. For example discussion boards often detect addresses and turn them into links, some, such as wikipedia, even allow users to hide which url the link is going to by specifying an arbitrary text for the link. In these cases we don't want the person inserting the link to be able to speak for the site the link was located on. Additionally, one of the reasons why the referer (sic) header is being so frequently blocked is that it leaks information about where users are coming from. For example when a political website linking to google.com it has bothered many users that this tells google my political affiliation, causing them to filter the referer header. Thus in these two cases we don't want the GET request to include a Sec-From header containing the originating website. The difference between these two cases is purely in the context from which the GET request was created. While we could enumerate these contexts in Adams spec, IETF has in the past expressed a dislike for specifying application behavior, prefering only to define protocol behavior. Thus we have to define the protocol in an IETF spec, and allow HTML5 (or some other spec) to selectively invoke the different behaviors defined by the IETF spec. Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). This is still being debated. But lets do that in a separate thread. Can you elaborate on the debate or point to an archive? HTML5 will have to enumerate the contexts in which requests are deemed privacy-sensitive (has this been added to HTML5 yet?), however, given that different sites will have different requirements, it may be likely that authors will want the ability to override the default behavior. - Bil
Re: Denoting privacy-sensitive requests (was: Re: Do we need to rename the Origin header?)
On Wed, Jul 1, 2009 at 7:48 AM, Bil Corryb...@corry.biz wrote: Jonas Sicking wrote on 6/25/2009 5:35 PM: On Thu, Jun 25, 2009 at 8:10 AM, Bil Corryb...@corry.biz wrote: Jonas Sicking wrote on 6/25/2009 2:11 AM: On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote: On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? That's correct. Hopefully folks writing specs at the application layer will coordinate so as not to make the web platform any more confusing than it is already. :) To make it clear what the intent is here: We know that people are building web applications where GET requests cause state changes on the server side. While this is unfortunate, we don't believe that people will stop. Thus we sometimes want Sec-From to be included in GET requests. At the same time, it's a quite common practice on the web today for sites to allow other users to put a href=... links on their site. For example discussion boards often detect addresses and turn them into links, some, such as wikipedia, even allow users to hide which url the link is going to by specifying an arbitrary text for the link. In these cases we don't want the person inserting the link to be able to speak for the site the link was located on. Additionally, one of the reasons why the referer (sic) header is being so frequently blocked is that it leaks information about where users are coming from. For example when a political website linking to google.com it has bothered many users that this tells google my political affiliation, causing them to filter the referer header. Thus in these two cases we don't want the GET request to include a Sec-From header containing the originating website. The difference between these two cases is purely in the context from which the GET request was created. While we could enumerate these contexts in Adams spec, IETF has in the past expressed a dislike for specifying application behavior, prefering only to define protocol behavior. Thus we have to define the protocol in an IETF spec, and allow HTML5 (or some other spec) to selectively invoke the different behaviors defined by the IETF spec. Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). This is still being debated. But lets do that in a separate thread. Can you elaborate on the debate or point to an archive? HTML5 will have to enumerate the contexts in which requests are deemed privacy-sensitive (has this been added to HTML5 yet?), however, given that different sites will have different requirements, it may be likely that authors will want the ability to override the default behavior. I think this is a discussion that should be held in the HTML WG, but here is the latest draft of a list that we've discussed at mozilla: https://wiki.mozilla.org/Security/Origin#When_the_Origin_is_served_.28and_when_it_is_.22null.22.29 The document still calls the header Origin, though it should be Sec-From according to Adams latest draft. Also, I see no reason not to simply send null for stylesheet loads. And yes, it's possible that sites will want to override the default behavior. / Jonas
Re: Denoting privacy-sensitive requests (was: Re: Do we need to rename the Origin header?)
Jonas Sicking wrote on 7/1/2009 3:42 PM: On Wed, Jul 1, 2009 at 7:48 AM, Bil Corryb...@corry.biz wrote: Jonas Sicking wrote on 6/25/2009 5:35 PM: On Thu, Jun 25, 2009 at 8:10 AM, Bil Corryb...@corry.biz wrote: Jonas Sicking wrote on 6/25/2009 2:11 AM: On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote: On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? That's correct. Hopefully folks writing specs at the application layer will coordinate so as not to make the web platform any more confusing than it is already. :) To make it clear what the intent is here: We know that people are building web applications where GET requests cause state changes on the server side. While this is unfortunate, we don't believe that people will stop. Thus we sometimes want Sec-From to be included in GET requests. At the same time, it's a quite common practice on the web today for sites to allow other users to put a href=... links on their site. For example discussion boards often detect addresses and turn them into links, some, such as wikipedia, even allow users to hide which url the link is going to by specifying an arbitrary text for the link. In these cases we don't want the person inserting the link to be able to speak for the site the link was located on. Additionally, one of the reasons why the referer (sic) header is being so frequently blocked is that it leaks information about where users are coming from. For example when a political website linking to google.com it has bothered many users that this tells google my political affiliation, causing them to filter the referer header. Thus in these two cases we don't want the GET request to include a Sec-From header containing the originating website. The difference between these two cases is purely in the context from which the GET request was created. While we could enumerate these contexts in Adams spec, IETF has in the past expressed a dislike for specifying application behavior, prefering only to define protocol behavior. Thus we have to define the protocol in an IETF spec, and allow HTML5 (or some other spec) to selectively invoke the different behaviors defined by the IETF spec. Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). This is still being debated. But lets do that in a separate thread. Can you elaborate on the debate or point to an archive? HTML5 will have to enumerate the contexts in which requests are deemed privacy-sensitive (has this been added to HTML5 yet?), however, given that different sites will have different requirements, it may be likely that authors will want the ability to override the default behavior. I think this is a discussion that should be held in the HTML WG It'll be difficult for me to participate if it takes place on the HTML WG list due to the restriction on who may join it (I don't qualify). here is the latest draft of a list that we've discussed at mozilla: https://wiki.mozilla.org/Security/Origin#When_the_Origin_is_served_.28and_when_it_is_.22null.22.29 Would you envision those values becoming the default behavior? The column Workaround to Default Behavior wouldn't be needed if authors can control it via HTML5. Also, draft makes mention of sending the RequestType -- is that a proposed header? - Bil
Re: Do we need to rename the Origin header?
On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote: On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? That's correct. Hopefully folks writing specs at the application layer will coordinate so as not to make the web platform any more confusing than it is already. :) To make it clear what the intent is here: We know that people are building web applications where GET requests cause state changes on the server side. While this is unfortunate, we don't believe that people will stop. Thus we sometimes want Sec-From to be included in GET requests. At the same time, it's a quite common practice on the web today for sites to allow other users to put a href=... links on their site. For example discussion boards often detect addresses and turn them into links, some, such as wikipedia, even allow users to hide which url the link is going to by specifying an arbitrary text for the link. In these cases we don't want the person inserting the link to be able to speak for the site the link was located on. Additionally, one of the reasons why the referer (sic) header is being so frequently blocked is that it leaks information about where users are coming from. For example when a political website linking to google.com it has bothered many users that this tells google my political affiliation, causing them to filter the referer header. Thus in these two cases we don't want the GET request to include a Sec-From header containing the originating website. The difference between these two cases is purely in the context from which the GET request was created. While we could enumerate these contexts in Adams spec, IETF has in the past expressed a dislike for specifying application behavior, prefering only to define protocol behavior. Thus we have to define the protocol in an IETF spec, and allow HTML5 (or some other spec) to selectively invoke the different behaviors defined by the IETF spec. / Jonas
Re: Do we need to rename the Origin header?
On Thu, 25 Jun 2009 05:50:32 +0200, Bil Corry b...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? HTML5 defines an XHTML serialization too. (Which is also the XHTML UAs implement.) Keeping the behavior of the two serializations as similar as possible is a goal of the HTML5 effort so this should not happen. -- Anne van Kesteren http://annevankesteren.nl/
Re: Do we need to rename the Origin header?
Jonas Sicking wrote on 6/25/2009 2:11 AM: On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote: On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? That's correct. Hopefully folks writing specs at the application layer will coordinate so as not to make the web platform any more confusing than it is already. :) To make it clear what the intent is here: We know that people are building web applications where GET requests cause state changes on the server side. While this is unfortunate, we don't believe that people will stop. Thus we sometimes want Sec-From to be included in GET requests. At the same time, it's a quite common practice on the web today for sites to allow other users to put a href=... links on their site. For example discussion boards often detect addresses and turn them into links, some, such as wikipedia, even allow users to hide which url the link is going to by specifying an arbitrary text for the link. In these cases we don't want the person inserting the link to be able to speak for the site the link was located on. Additionally, one of the reasons why the referer (sic) header is being so frequently blocked is that it leaks information about where users are coming from. For example when a political website linking to google.com it has bothered many users that this tells google my political affiliation, causing them to filter the referer header. Thus in these two cases we don't want the GET request to include a Sec-From header containing the originating website. The difference between these two cases is purely in the context from which the GET request was created. While we could enumerate these contexts in Adams spec, IETF has in the past expressed a dislike for specifying application behavior, prefering only to define protocol behavior. Thus we have to define the protocol in an IETF spec, and allow HTML5 (or some other spec) to selectively invoke the different behaviors defined by the IETF spec. Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). - Bil
Re: Do we need to rename the Origin header?
On Thu, Jun 25, 2009 at 8:10 AM, Bil Corryb...@corry.biz wrote: Jonas Sicking wrote on 6/25/2009 2:11 AM: On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote: On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? That's correct. Hopefully folks writing specs at the application layer will coordinate so as not to make the web platform any more confusing than it is already. :) To make it clear what the intent is here: We know that people are building web applications where GET requests cause state changes on the server side. While this is unfortunate, we don't believe that people will stop. Thus we sometimes want Sec-From to be included in GET requests. At the same time, it's a quite common practice on the web today for sites to allow other users to put a href=... links on their site. For example discussion boards often detect addresses and turn them into links, some, such as wikipedia, even allow users to hide which url the link is going to by specifying an arbitrary text for the link. In these cases we don't want the person inserting the link to be able to speak for the site the link was located on. Additionally, one of the reasons why the referer (sic) header is being so frequently blocked is that it leaks information about where users are coming from. For example when a political website linking to google.com it has bothered many users that this tells google my political affiliation, causing them to filter the referer header. Thus in these two cases we don't want the GET request to include a Sec-From header containing the originating website. The difference between these two cases is purely in the context from which the GET request was created. While we could enumerate these contexts in Adams spec, IETF has in the past expressed a dislike for specifying application behavior, prefering only to define protocol behavior. Thus we have to define the protocol in an IETF spec, and allow HTML5 (or some other spec) to selectively invoke the different behaviors defined by the IETF spec. Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). This is still being debated. But lets do that in a separate thread. / Jonas
Re: Do we need to rename the Origin header?
Adam Barth wrote on 6/20/2009 6:25 PM: On Sat, Jun 20, 2009 at 12:57 PM, Bil Corryb...@corry.biz wrote: I've lost track, is this still something being considered? I should have an updated draft posted soon. I'm not clear with the new draft if it now allows Sec-From for same-origin GET requests, it says: - Whenever a user agent issues an HTTP request from a privacy- sensitive context, the user agent MUST send the value null in the Sec-From header. - But it doesn't define privacy-sensitive. It does say: - The Sec-From header also improves on the Referer header by NOT leaking intranet host names to external Web sites when a user follows a hyperlink from an intranet host to an external site because hyperlinks generate privacy-sensitive requests. - So presumably a GET request to the same origin isn't a privacy-sensitive request, but I'm just double-checking. I think explicitly defining or referencing what constitutes a privacy-sensitive request would greatly improve the draft. - Bil
Re: Do we need to rename the Origin header?
On Wed, Jun 24, 2009 at 5:48 PM, Bil Corryb...@corry.biz wrote: Adam Barth wrote on 6/20/2009 6:25 PM: On Sat, Jun 20, 2009 at 12:57 PM, Bil Corryb...@corry.biz wrote: I've lost track, is this still something being considered? I should have an updated draft posted soon. I'm not clear with the new draft if it now allows Sec-From for same-origin GET requests, it says: I'll respond to everyone's feedback in as time permits (probably in the next couple of days). To answer you question, the draft has always allowed the header to be send for same-origin GETs. The difference is we now require it for participating user agents. Also, the draft has always allowed the user agent to send the value null. The new spec introduces the term privacy-sensitive as a hook so that other specs can easily control when to send null or a non-null value. But it doesn't define privacy-sensitive. It does say: This is for application-level specs, like HTML 5, to define. So presumably a GET request to the same origin isn't a privacy-sensitive request, but I'm just double-checking. I think explicitly defining or referencing what constitutes a privacy-sensitive request would greatly improve the draft. We can't determine which requests are privacy-sensitive at this layer. For example, HTML 5 might wish to define requests generated from a elements as privacy sensitive but requests generated from form elements as not privacy sensitive. Adam
Re: Do we need to rename the Origin header?
Adam Barth wrote on 6/24/2009 8:58 PM: On Wed, Jun 24, 2009 at 5:48 PM, Bil Corryb...@corry.biz wrote: Adam Barth wrote on 6/20/2009 6:25 PM: On Sat, Jun 20, 2009 at 12:57 PM, Bil Corryb...@corry.biz wrote: I've lost track, is this still something being considered? I should have an updated draft posted soon. I'm not clear with the new draft if it now allows Sec-From for same-origin GET requests, it says: I'll respond to everyone's feedback in as time permits (probably in the next couple of days). To answer you question, the draft has always allowed the header to be send for same-origin GETs. The difference is we now require it for participating user agents. Also, the draft has always allowed the user agent to send the value null. The new spec introduces the term privacy-sensitive as a hook so that other specs can easily control when to send null or a non-null value. But it doesn't define privacy-sensitive. It does say: This is for application-level specs, like HTML 5, to define. So presumably a GET request to the same origin isn't a privacy-sensitive request, but I'm just double-checking. I think explicitly defining or referencing what constitutes a privacy-sensitive request would greatly improve the draft. We can't determine which requests are privacy-sensitive at this layer. For example, HTML 5 might wish to define requests generated from a elements as privacy sensitive but requests generated from form elements as not privacy sensitive. Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? - Bil
Re: Do we need to rename the Origin header?
On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? That's correct. Hopefully folks writing specs at the application layer will coordinate so as not to make the web platform any more confusing than it is already. :) Adam
Re: Do we need to rename the Origin header?
Ian Hickson wrote on 6/2/2009 8:11 PM: On Thu, 2 Apr 2009, Bil Corry wrote: Related, HTML5 currently prohibits sending the XXX-Origin header for GET requests. This is to prevent intranet applications leaking their internal hostnames to external sites (are there other reasons?). However, there is value in a site being able to determine that a request originated from itself, so to that end, I'd like to request that HTML5 specify that the XXX-Origin header should be sent for any same-origin GET requests. This would still avoid leaking intranet hostnames while allowing a site to verify that a request came from itself. That's an interesting idea; Adam, what do you think? I'm a bit wary of adding too many features at once here, and it's difficult to define exactly what consists a same-origin request sometimes, so this might not be that easy to do. I've lost track, is this still something being considered? - Bil
Re: Do we need to rename the Origin header?
On Sat, Jun 20, 2009 at 12:57 PM, Bil Corryb...@corry.biz wrote: I've lost track, is this still something being considered? I should have an updated draft posted soon. Adam
Re: Do we need to rename the Origin header?
On Thu, 2 Apr 2009, Bil Corry wrote: Since the public-webapps list was never able to reconcile[1] HTML5's Origin header (now renamed XXX-Origin[2]) with CORS's Origin header[3], we're left with two headers with similar implementations and similar names. Due to this, it may prudent to rename XXX-Origin to something without Origin in the name to better distinguish between the two. I don't know what the header should be renamed to (Source?), but no matter which name is chosen for the header, it should be listed as a prohibited header for XHR.setRequestHeader()[4]. [1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0057.html [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate-fragid-step [3] http://www.w3.org/TR/cors/#origin-header [4] http://www.w3.org/TR/XMLHttpRequest2/#author-request-headers Based on advice from Adam, I have updated HTML5 to have Origin again. On Thu, 2 Apr 2009, Bil Corry wrote: Related, HTML5 currently prohibits sending the XXX-Origin header for GET requests. This is to prevent intranet applications leaking their internal hostnames to external sites (are there other reasons?). However, there is value in a site being able to determine that a request originated from itself, so to that end, I'd like to request that HTML5 specify that the XXX-Origin header should be sent for any same-origin GET requests. This would still avoid leaking intranet hostnames while allowing a site to verify that a request came from itself. That's an interesting idea; Adam, what do you think? I'm a bit wary of adding too many features at once here, and it's difficult to define exactly what consists a same-origin request sometimes, so this might not be that easy to do. On Thu, 2 Apr 2009, Bil Corry wrote: Since HTML5's XXX-Origin header now differs slightly from CORS Origin header, I propose we rename HTML5's header to something without Origin in it to make the distinction between the two more clear -- i.e. to avoid developer implementation errors where they check for the wrong header. As far as a name for the header goes, perhaps Source or Request-Source or Can we just resolve the differences? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Do we need to rename the Origin header?
On Thu, 9 Apr 2009, Bil Corry wrote: For example, imagine instead you visit a malicious site, and it wants to phish your banking credentials. But rather than choosing a random bank and hoping you bank there, it instead launches a series of timing attacks against the top 30 banks, determines which bank(s) you're logged into, then tries phishing against the one you're logged into. CORS-Origin can't help, but a robust Origin could. You could just do a timing attack against non-login-protected assets that are only shown while logged in, or even just do timing attacks against any cached resource from the site, to see if they visited it. Or heck, you could just do a regular :visited history probing attack to see which site they visited. If we wanted to protect against timing attacks like this I think we would need to just have the browser itself ensure all network traffic has unpredictable timing (and remove the visited URLs features). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Do we need to rename the Origin header?
Ian Hickson wrote on 4/9/2009 1:42 AM: On Thu, 9 Apr 2009, Bil Corry wrote: For example, imagine instead you visit a malicious site, and it wants to phish your banking credentials. But rather than choosing a random bank and hoping you bank there, it instead launches a series of timing attacks against the top 30 banks, determines which bank(s) you're logged into, then tries phishing against the one you're logged into. CORS-Origin can't help, but a robust Origin could. You could just do a timing attack against non-login-protected assets that are only shown while logged in, or even just do timing attacks against any cached resource from the site, to see if they visited it. Or heck, you could just do a regular :visited history probing attack to see which site they visited. If we wanted to protect against timing attacks like this I think we would need to just have the browser itself ensure all network traffic has unpredictable timing (and remove the visited URLs features). My point is that a robust Origin moves us closer to better security controls, perhaps not all the way, but certainly much closer than CORS-Origin gets us. - Bil
Re: Do we need to rename the Origin header?
On Thu, Apr 9, 2009 at 8:48 AM, Bil Corry b...@corry.biz wrote: My point is that a robust Origin moves us closer to better security controls, perhaps not all the way, but certainly much closer than CORS-Origin gets us. I think we should focus on clear use cases and techniques that address those use cases. For example, Mozilla-Origin is useful for mitigating ClickJacking whereas CORS-Origin is not. Adam
Re: Do we need to rename the Origin header?
Adam Barth wrote on 4/7/2009 4:36 PM: HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate-fragid-step Barth: http://www.ietf.org/internet-drafts/draft-abarth-origin-00.txt These two, at least, are the same. We separated the XXX-Origin bit from the HTML 5 spec because folks from the IETF were interested in reviewing it separately from HTML 5. Is draft-abarth-origin-00.txt entirely compatible now with CORS-Origin? - Bil
Re: Do we need to rename the Origin header?
On Wed, Apr 8, 2009 at 10:34 AM, Bil Corry b...@corry.biz wrote: Is draft-abarth-origin-00.txt entirely compatible now with CORS-Origin? Yes, as far as I know. If you find any incompatibility, please let me know and I'll fix it. Adam
Re: Do we need to rename the Origin header?
Adam Barth wrote on 4/9/2009 12:21 AM: On Wed, Apr 8, 2009 at 10:09 PM, Bil Corry b...@corry.biz wrote: Using the above scenario, if Origin was populated and sent for all same-origin requests (including GET), the website could simply redirect any request for any protected resource that isn't same-origin. Then no one could link to the site. Virtually every site is going to have some page that both wants to be world-linkable and has different time characteristics for logged in / not logged in. The Origin header is useful for many things but not for defeating timing attacks. The site could redirect externally-driven requests to a login page, and once the user logs in again, redirect the user back to the original source. It really depends on the site and what it is trying to accomplish. For example, imagine instead you visit a malicious site, and it wants to phish your banking credentials. But rather than choosing a random bank and hoping you bank there, it instead launches a series of timing attacks against the top 30 banks, determines which bank(s) you're logged into, then tries phishing against the one you're logged into. CORS-Origin can't help, but a robust Origin could. - Bil
Re: Do we need to rename the Origin header?
On Mon, Apr 6, 2009 at 2:09 PM, Bil Corry b...@corry.biz wrote: Can we please include the Origin header for all same-origin requests, including GET and HEAD? Or is there a compelling reason why not do to so? Also, would there be value in having Origin sent for *all* requests, and if populating Origin is prohibited for that request (e.g. cross-origin GET), it sends null as the value? In order to make the Origin header a workable CSRF defense for GET, we'd have to send null on cross-origin GET requests (otherwise the attacker can suppress the header by making a GET request from another origin). However, this is inconsistent with CORS. Adam
Re: Do we need to rename the Origin header?
Adam Barth wrote on 4/7/2009 11:54 AM: On Mon, Apr 6, 2009 at 2:09 PM, Bil Corry b...@corry.biz wrote: Can we please include the Origin header for all same-origin requests, including GET and HEAD? Or is there a compelling reason why not do to so? Also, would there be value in having Origin sent for *all* requests, and if populating Origin is prohibited for that request (e.g. cross-origin GET), it sends null as the value? In order to make the Origin header a workable CSRF defense for GET, we'd have to send null on cross-origin GET requests (otherwise the attacker can suppress the header by making a GET request from another origin). However, this is inconsistent with CORS. How set in stone is Origin within CORS? When brought up before, the consensus was Origin within CORS couldn't be changed due to Microsoft shipping IE8.[1] But now Doug Schepers is asking for a review of Origin within CORS[2] which makes me think it may be open to modification if warranted. The ideal scenario would be to merge all the various proposed Origin specifications into one that is well thought out and handles the bulk of the use cases. But this is predicated on being able to modify Origin as it appears in CORS; otherwise we're left with either at least two headers, or changing the behavior of all to match CORS, or making the header contextual, so that it is sent one way when via CORS, and another when it's not. At this point, I'm aware of four Origin descriptions, are there any others? CORS: http://www.w3.org/TR/cors/#origin-header HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate-fragid-step Barth: http://www.ietf.org/internet-drafts/draft-abarth-origin-00.txt Moz: https://wiki.mozilla.org/Security/Origin - Bil [1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0090.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0031.html
Re: Do we need to rename the Origin header?
On Tue, Apr 7, 2009 at 10:24 AM, Bil Corry b...@corry.biz wrote: How set in stone is Origin within CORS? I don't think we want to impede CORS with these issues. CORS is quite close to shipping in a number of implementations. I certainly don't want to hold it hostage. The ideal scenario would be to merge all the various proposed Origin specifications into one that is well thought out and handles the bulk of the use cases. Given infinite time, I agree. However, there is tremendous value in shipping CORS sooner rather than later. At this point, I'm aware of four Origin descriptions, are there any others? CORS: http://www.w3.org/TR/cors/#origin-header HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate-fragid-step Barth: http://www.ietf.org/internet-drafts/draft-abarth-origin-00.txt These two, at least, are the same. We separated the XXX-Origin bit from the HTML 5 spec because folks from the IETF were interested in reviewing it separately from HTML 5. Moz: https://wiki.mozilla.org/Security/Origin Adam
Re: Do we need to rename the Origin header?
Thomas Roessler wrote on 4/6/2009 4:19 AM: On 3 Apr 2009, at 20:26, Jonas Sicking wrote: We've done a lot of discussions internally at mozilla, but was hoping that Adam Barth would start work somewhere so that we could send our feedback. Perhaps it's worthwhile to summarize the Mozilla-internal discussions and send them here first? I'm having a sense that much of what's needed right now is for somebody to ask the right questions. I would like to see it. Another option that I haven't seen proposed is to keep CORS-Origin and HTML5-Origin both named Origin but make them contextual, so that Origin when sent via CORS will behave as outlined in CORS, and Origin when sent via HTML5 will behave as outlined in HTML5. - Bil
Re: Do we need to rename the Origin header?
Bil Corry wrote on 4/6/2009 9:32 AM: Another option that I haven't seen proposed is to keep CORS-Origin and HTML5-Origin both named Origin but make them contextual, so that Origin when sent via CORS will behave as outlined in CORS, and Origin when sent via HTML5 will behave as outlined in HTML5. Nevermind, I forgot that Adam conceded to changing his original Origin spec to match the redirect behavior in CORS, and reading through his draft, I see the change has been made to make them compatible. - Bil [1] http://www.ietf.org/internet-drafts/draft-abarth-origin-00.txt
Re: Do we need to rename the Origin header?
On Mon, Apr 6, 2009 at 2:19 AM, Thomas Roessler t...@w3.org wrote: Perhaps it's worthwhile to summarize the Mozilla-internal discussions and send them here first? I'm having a sense that much of what's needed right now is for somebody to ask the right questions. I'll let someone from Mozilla fill in the details, but the general idea is twofold: 1) Enable CSRF mitigation for GET requests. 2) Providing additional information in the header to help mitigate ClickJacking as well. To achieve (1), the Mozilla proposal sends the header (let's call it Blame-List for easy of discussion) for some GET requests, depending on how the requests were generated. For example, a hyperlink or an image would not send Blame-List, but a form submission would. To achieve (2), the Blame-List contains not only the origin that initiated the request, but also the origin of all the ancestor frames. For example, if attacker.com created an iframe to example.com, and the user clicked on the buy button inside of the example.com iframe, the header would look something like this: Blame-List: http://example.com http://attacker.com I believe Mozilla has fleshed out the details in a document somewhere. Adam
Re: Do we need to rename the Origin header?
On Mon, Apr 6, 2009 at 8:01 AM, Bil Corry b...@corry.biz wrote: Nevermind, I forgot that Adam conceded to changing his original Origin spec to match the redirect behavior in CORS, and reading through his draft, I see the change has been made to make them compatible. Yes. This is not ideal from a CSRF mitigation point of view, but it is workable. Adam
Re: Do we need to rename the Origin header?
Brandon Sterne wrote on 4/6/2009 3:34 PM: I'm adding Sid, who has been editing the document: https://wiki.mozilla.org/Security/Origin As is mentioned in the first section of that document, the name of the proposed header is subject to change. I'm confused, what is the relationship of this Origin (let's call it Moz-Origin): https://wiki.mozilla.org/Security/Origin To this Origin (IETF-Origin)? http://www.ietf.org/internet-drafts/draft-abarth-origin-00.txt - Bil
Re: Do we need to rename the Origin header?
Brandon Sterne wrote on 4/6/2009 3:34 PM: I'm adding Sid, who has been editing the document: https://wiki.mozilla.org/Security/Origin As is mentioned in the first section of that document, the name of the proposed header is subject to change. If you're going for an entirely new header, then you should consider adding the redirect path as well to it: Origin: origin host frame-ancestor*[, redirect-host]* So site A frames B which frames C that then POSTs to D, which redirects to E which redirects to F becomes: Origin: C B A, D, E - Bil
Re: Do we need to rename the Origin header?
On Fri, 03 Apr 2009 22:05:52 +0200, Bil Corry b...@corry.biz wrote: So the first question to ponder is if the referrer header really can adequately replace Origin. If it can, then we should the move this discussion over to ietf-http-wg and work to make sure referrer is updated in a way to make it useful for CSRF protection. If it can not, then we should discuss Origin here as the ietf-http-wg has made it very clear that they are not interested. FWIW, for CORS it's too late to rename Origin now that we have three implementations, one of which is shipping (IE) and two that are in beta (Firefox, Safari). (Anyone know which version of Chrome supports CORS?) CORS defines the Origin header as well: http://www.w3.org/TR/2009/WD-cors-20090317/#origin-request-header It has also been registered in the provisional header registry from IANA for quite a while. -- Anne van Kesteren http://annevankesteren.nl/
Re: Do we need to rename the Origin header?
Ian Hickson wrote on 1/14/2009 4:07 PM: On Tue, 13 Jan 2009, Jonas Sicking wrote: On Tue, Jan 13, 2009 at 5:09 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 13 Jan 2009, Jonas Sicking wrote: It's not just POST that we need to worry about, ideally we should cover the GET case as well. Or at least it's quite likely that we will want to. My understanding was that we didn't want to include Origin in GET requests. In fact HTML5 right now goes out of its way to avoid including it in GET requests. We've been debating this both ways at mozilla, no decision has been made yet regarding what we'll recommend. I've renamed it to XXX-Origin in HTML5. I haven't changed its behavior (it is still only sent for non-GET). I'm trying to bring HTML5 to last call by October. Who owns this issue? Do we have an ETA on resolving it? Since HTML5's XXX-Origin header now differs slightly from CORS Origin header, I propose we rename HTML5's header to something without Origin in it to make the distinction between the two more clear -- i.e. to avoid developer implementation errors where they check for the wrong header. As far as a name for the header goes, perhaps Source or Request-Source or In addition, no matter which name is chosen for the header, it should be listed as a prohibited header for XHR.setRequestHeader() to avoid XHR requests spoofing it. And as far as implementation goes, I'd really like to see XXX-Origin sent for any same-origin GET requests (currently GET requests exclude the header). This still avoids leaking intranet hostnames to external sites and allows sites to verify that a request is coming from themselves. Thoughts? - Bil
Re: Do we need to rename the Origin header?
Thomas Roessler wrote on 1/12/2009 8:02 PM: Having the CSRF-Origin defined in an RFC or another separate spec is a good idea independently of whether or not it ends up being the same header that's used for cross-site XHR. If someone wants to form an Origin BOF at the next IETF meeting in March (with the idea of creating a RFC), I'll attend. I'm already planning to be there for the Cookie BOF. - Bil
Re: Do we need to rename the Origin header?
On Tue, 13 Jan 2009, Jonas Sicking wrote: On Tue, Jan 13, 2009 at 5:09 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 13 Jan 2009, Jonas Sicking wrote: It's not just POST that we need to worry about, ideally we should cover the GET case as well. Or at least it's quite likely that we will want to. My understanding was that we didn't want to include Origin in GET requests. In fact HTML5 right now goes out of its way to avoid including it in GET requests. We've been debating this both ways at mozilla, no decision has been made yet regarding what we'll recommend. I've renamed it to XXX-Origin in HTML5. I haven't changed its behavior (it is still only sent for non-GET). I'm trying to bring HTML5 to last call by October. Who owns this issue? Do we have an ETA on resolving it? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Do we need to rename the Origin header?
On Tue, 13 Jan 2009 01:31:49 +0100, Jonas Sicking jo...@sicking.cc wrote: My suggestion is to rename Origin to Access-Control-Request-Origin or Access-Control-Origin if possible (depends on where current implementers are in their ship schedule), or that we request that the CSRF protection header be renamed to something other than Origin. I'm fine with renaming it to Access-Control-Request-Origin as far as the Access Control draft is concerned. Maciej, Sam, Adam? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Do we need to rename the Origin header?
On Tue, Jan 13, 2009 at 5:09 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 13 Jan 2009, Jonas Sicking wrote: It's not just POST that we need to worry about, ideally we should cover the GET case as well. Or at least it's quite likely that we will want to. My understanding was that we didn't want to include Origin in GET requests. In fact HTML5 right now goes out of its way to avoid including it in GET requests. We've been debating this both ways at mozilla, no decision has been made yet regarding what we'll recommend. / Jonas
Re: Do we need to rename the Origin header?
On 12 Jan 2009, at 16:31, Jonas Sicking wrote: There are 3 possible solutions that I can see to this: 1. Change the name of the Origin header in Access-Control 2. Change the name of the Origin header used for CSRF protection 3. Change the behavior of one (or both) of the specs such that they match in behavior. My concern with doing 3 is that the CSRF protection part hasn't been fully ironed out yet, so if we were to tie Access-Control the the CSRF protection scheme then that might leave Access-Control in flux longer than we want. My preference would be 3. Having two almost identical headers in place will only cause more confusion, and ultimately do damage.
Re: Do we need to rename the Origin header?
Thomas Roessler wrote: On 12 Jan 2009, at 16:31, Jonas Sicking wrote: There are 3 possible solutions that I can see to this: 1. Change the name of the Origin header in Access-Control 2. Change the name of the Origin header used for CSRF protection 3. Change the behavior of one (or both) of the specs such that they match in behavior. My concern with doing 3 is that the CSRF protection part hasn't been fully ironed out yet, so if we were to tie Access-Control the the CSRF protection scheme then that might leave Access-Control in flux longer than we want. My preference would be 3. Having two almost identical headers in place will only cause more confusion, and ultimately do damage. Well, they have semantically different meanings: The Access-Control one means this is the party I'm sending data to. The CSRF one means this is the party that initiated the request. But yeah, I agree that it would be great if we could use the same header. My main concern is if it's possible to change implementation at this stage though, I know some implementations are very close to shipping, specifically IE 8. That said, here is a solution that might work for both Access-Control and CSRF protection: Site A makes a request to site B, the UA adds the header Origin: A Site B redirects the request to site C, the UA adds the header Origin: A, B If the request is an Access-Control request, then in order for site C to authorize the request, it needs to send back Access-Control-Allow-Origin: A, B. However before even considering this I think we need to check with involved parties that have implementations to see if they will be able to change before shipping. / Jonas
Re: Do we need to rename the Origin header?
On Mon, 12 Jan 2009, Jonas Sicking wrote: Should I remove or rename 'Origin' in HTML5 for now? Well, HTML5 isn't the only place where this header has been discussed, but it wouldn't be a bad idea I think. Which, remove or rename? :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
