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 Barth<w3c@adambarth.com> wrote:
>> On Wed, Jun 24, 2009 at 8:50 PM, Bil Corry<bil@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

Received on Thursday, 25 June 2009 15:11:39 UTC