Re: Do we need to rename the Origin header?

On Thu, Jun 25, 2009 at 8:10 AM, Bil Corry<bil@corry.biz> wrote:
> 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?).

This is still being debated. But lets do that in a separate thread.

/ Jonas

Received on Thursday, 25 June 2009 22:36:38 UTC