W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2016

Re: [referrer] Providing safer policy states

From: Jochen Eisinger <eisinger@google.com>
Date: Wed, 20 Apr 2016 06:54:01 +0000
Message-ID: <CALjhuiczGo5rTGjfgFXncOLW8U992Mzv0NT+oSLAP+fn5v+0=w@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>, Francois Marier <francois@mozilla.com>, "Emily Stark (Dunn)" <estark@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
I agree that we shouldn't break existing users.

On Wed, Apr 20, 2016 at 7:06 AM Brad Hill <hillbrad@gmail.com> wrote:

> I would definitely be against changing the meaning of the existing policy
> states to break sending referrers across https->http transitions, since
> that was the biggest motivating use case for the feature, and it is very
> inconvenient to have to do browser sniffing and send different policies
> that sometimes say the same thing but mean different things across
> different UAs and different versions of the same UA.
> Who will be the "customers" for these new states that we think it is a
> good idea to break / force change on the existing users?
> On Tue, Apr 19, 2016 at 5:44 PM Francois Marier <francois@mozilla.com>
> wrote:
>> On 05/04/16 08:43 PM, Emily Stark (Dunn) wrote:
>> > Adding these new policy states sounds reasonable to me. However, I want
>> > to note that there's been discussion about expanding the spec to a
>> > JSON-based syntax that allows much more flexibility. For example, we
>> > might want to express the policy "'unsafe-url' for navigations to and
>> > subresources from myadnetwork.com <http://myadnetwork.com>, and 'none'
>> > for all other origins" -- maybe using some syntax like { "unsafe-url":
>> > ["myadnetwork.com <http://myadnetwork.com>", "'self'"], "none": "*"}.
>> > (I'm not suggesting that as an actual proposal for the syntax, just an
>> > idea of the kind of thing we were thinking about.) In that world, the
>> > policy states would just be shorthand for the most commonly used
>> policies.
>> That would be a good way to express policy the states in the table
>> (taking the liberty to abbreviate your strawman syntax, CSP-style):
>>  no-referrer:                     "none *"
>>  origin:                          "origin *; none 'http:*'"
>>  unsafe-origin:                   "origin *"
>>  same-origin:                     "full 'self'; none *"
>>  origin-when-cross-origin:        "full 'self'; origin *; none 'http:*'"
>>  unsafe-origin-when-cross-origin: "full 'self'; origin *"
>>  no-referrer-when-downgrade:      "full *; none 'http:*'"
>>  unsafe-url:                      "full *"
>> I'm assuming that the wildcard is applied last (i.e. it defaults to that
>> unless there is a more precise match).
>> > If that's the kind of thing that we want to head towards, then I don't
>> > think it makes sense to introduce a new attribute for downgrades.
>> > Presumably in that future world you'd be able to handle downgrades with
>> > something like { "none": "http://*" }.
>> Of course, it would be slightly different from the downgrade idea since
>> it would disable referrer on HTTP regardless of whether or not the page
>> is served over HTTPS, but I think that's just as good because the server
>> can vary the header if it wants to.
>> Francois
Received on Wednesday, 20 April 2016 06:54:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:55 UTC