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

Re: [referrer] HTTPS->HTTP

From: Jochen Eisinger <eisinger@google.com>
Date: Fri, 24 Oct 2014 10:11:26 +0000
Message-ID: <CALjhuicb3DzQrMTr5SRxGdVU+KLxj2Mx5x_4cv=A=HiHRsNW7A@mail.gmail.com>
To: Mike West <mkwst@google.com>, Mark Nottingham <mnot@mnot.net>
Cc: Brian Smith <brian@briansmith.org>, WebAppSec WG <public-webappsec@w3.org>
Maybe it does.

I'd still rather have sites to move to HTTPS sooner.

On Fri Oct 24 2014 at 12:08:23 PM Mike West <mkwst@google.com> wrote:

> How does that follow, Mark?
>
> -mike
>
> --
> Mike West <mkwst@google.com>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>
> On Fri, Oct 24, 2014 at 12:06 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>> Doesn't it encourage third-party services to be lazy and stay on
>> cleartext HTTP?
>>
>>
>> > On 24 Oct 2014, at 9:05 pm, Jochen Eisinger <eisinger@google.com>
>> wrote:
>> >
>> > Google uses the "origin" policy on the search result page.
>> >
>> > I agree that "always" is a two edged sword. From my point of view, the
>> current default referrer behavior makes sense in a world where everybody is
>> happy with HTTP, and HTTPS means something like "banking".
>> >
>> > Today, I think we'd rather have everybody on HTTPS, and I see the
>> "always" policy as a way to make it easier for web sites to migrate to
>> HTTPS without punishing them.
>> >
>> > best
>> > -jochen
>> >
>> > On Fri Oct 24 2014 at 11:56:41 AM Mike West <mkwst@google.com> wrote:
>> > +Jochen, who hopefully has a few minutes to think about this before he
>> disappears into vacationland.
>> >
>> > -mike
>> >
>> > --
>> > Mike West <mkwst@google.com>
>> > Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>> >
>> > Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
>> > Registergericht und -nummer: Hamburg, HRB 86891
>> > Sitz der Gesellschaft: Hamburg
>> > Geschäftsführer: Graham Law, Christine Elizabeth Flores
>> > (Sorry; I'm legally required to add this exciting detail to emails.
>> Bleh.)
>> >
>> > On Fri, Oct 24, 2014 at 9:03 AM, Brian Smith <brian@briansmith.org>
>> wrote:
>> > On Thu, Oct 23, 2014 at 10:29 PM, Mark Nottingham <mnot@mnot.net>
>> wrote:
>> > The bigger issue, however, is whether this is a good idea at all. In
>> particular, "unsafe-url" removes this prohibition completely, for an
>> *entire* page.
>> >
>> > This is likely to create a situation where those providing third-party
>> functionality want/require referers, so they tell HTTPS sites to set
>> "unsafe-url" or face a functional (or financial) penalty; now not only the
>> intended content but all other fetches from the page will send a referer.
>> >
>> > I understand that there's a delicate balance here; if referers aren't
>> sent at all, sites may be reluctant to move to HTTPS (although one might
>> just say that the sites they're linking to should move to HTTPS!). The
>> question is whether there's a net improvement to Web security.
>> >
>> > Arguably, origin-only and origin-when-cross-origin might get that
>> balance right; I question whether unsafe-url and always (which isn't
>> well-documented, btw) do.
>> >
>> > Has this been discussed yet?
>> >
>> > Mark, if I understand you correctly, then I very much agree with you.
>> See these messages, and others in that thread:
>> >
>> > http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0174.html
>> > http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0162.html
>> >
>> > See also:
>> >
>> https://groups.google.com/forum/#!msg/mozilla.dev.privacy/wmPzPCdzIU8/Vrugn8XquL4J
>> >
>> > Cheers,
>> > Brian
>> >
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
>
Received on Friday, 24 October 2014 10:11:56 UTC

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