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
