W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2014

Re: Frame Ancestors and Referrer (Re: [webappsec] Call for Consensus: Stop work on Content Security Policy 1.0, transition to WG Note)

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Fri, 24 Oct 2014 11:37:57 -0700
Message-ID: <CALx_OUA9tAmBWSSKfKCSVg2VVAMoYJXHVXKYC2YJznBz4_Nxkw@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Sean Snider <ssnider@yahoo-inc.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
>> I'm trying to understand the valid use-case for having "referrer" set to
>> "none" [...]
>> While the path, and host "could" have sensitive data. . . that's certainly
>> not the case normally.

> http://www.w3.org/TR/capability-urls/ are used all over the place to grant
> temporary permissions. Flickr's sharing mechanism uses them, for instance
> (or it did back when I worked at Yahoo! :) ).

Yeah, just to pile on, the path routinely contains secrets or
quasi-secrets (document IDs shared with "anyone with a link", titles
of blog posts on private blogs that require a password to access,
etc).

But to also address the more general question of whether we need
"none" - I don't know, I don't think it's essential, but one obvious
use case would be protecting info about internal networks
*.corp.yahoo-inc.com. On top of that, some system names can be
revealing - say, a click from fraud-investigations.corp.yahoo-inc.com
would make my scratch my head.

Today, both of these get leaked a lot; giving them a browser-supported
way to minimize exposure sounds nice.

/mz
Received on Friday, 24 October 2014 18:38:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC