- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 19 Mar 2013 15:30:24 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WHATWG <whatwg@whatwg.org>
On Mar 19, 2013 4:20 AM, "Anne van Kesteren" <annevk@annevk.nl> wrote: > > On Mon, Mar 18, 2013 at 3:57 PM, Jonas Sicking <jonas@sicking.cc> wrote: > > By not including cookies or other login information you are already > > forcing the capability model since you can't tell the connection from > > one that is server-to-server. > > > > Including the referrer header, at least by default, seems very useful > > still since there is lots of infrastructure in servers which are using > > those for logging purposes. > > I don't disagree, but they wanted to avoid exposing any kind of > originating data so people could not make trust decisions based on > that at all (however silly doing that may be). See > http://www.w3.org/TR/UMP/#request-sending in particular. > > I don't really mind what we do here either way. I don't think that that is a particularly convincing argument since there is no confused deputy problem here, and if a website is making security decisions based on referrer headers even when there are no other identifying signals, then that website is a lost cause. In other words, I see no new attack vectors being introduced, but I do see additional value, if we keep the referrer. Regarding origin. I guess I don't care terribly strongly either way. But I don't really see the value of creating an exception here from regular CORS given that I don't see any attack vectors that are being closed. / Jonas
Received on Tuesday, 19 March 2013 22:30:57 UTC