- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 24 Jun 2009 18:58:34 -0700
- To: Bil Corry <bil@corry.biz>
- Cc: Ian Hickson <ian@hixie.ch>, whatwg@whatwg.org, Jonas Sicking <jonas@sicking.cc>, 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 5:48 PM, Bil Corry<bil@corry.biz> wrote: > Adam Barth wrote on 6/20/2009 6:25 PM: >> On Sat, Jun 20, 2009 at 12:57 PM, Bil Corry<bil@corry.biz> wrote: >>> I've lost track, is this still something being considered? >> >> I should have an updated draft posted soon. > > I'm not clear with the new draft if it now allows Sec-From for same-origin GET requests, it says: I'll respond to everyone's feedback in as time permits (probably in the next couple of days). To answer you question, the draft has always allowed the header to be send for same-origin GETs. The difference is we now require it for participating user agents. Also, the draft has always allowed the user agent to send the value "null." The new spec introduces the term "privacy-sensitive" as a hook so that other specs can easily control when to send null or a non-null value. > But it doesn't define "privacy-sensitive". It does say: This is for application-level specs, like HTML 5, to define. > So presumably a GET request to the same origin isn't a "privacy-sensitive" request, but I'm just double-checking. I think explicitly defining or referencing what constitutes a "privacy-sensitive" request would greatly improve the draft. We can't determine which requests are privacy-sensitive at this layer. For example, HTML 5 might wish to define requests generated from <a> elements as privacy sensitive but requests generated from <form> elements as not privacy sensitive. Adam
Received on Thursday, 25 June 2009 01:59:37 UTC