- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 25 Jun 2009 15:35:35 -0700
- To: Bil Corry <bil@corry.biz>
- Cc: Adam Barth <w3c@adambarth.com>, 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 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