- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 25 Jun 2009 00:11:21 -0700
- To: Adam Barth <w3c@adambarth.com>
- Cc: Bil Corry <bil@corry.biz>, Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>, public-webapps@w3.org, Maciej Stachowiak <mjs@apple.com>, Sam Weinig <weinig@apple.com>
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. / Jonas
Received on Thursday, 25 June 2009 07:12:21 UTC