W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2015

Re: [UPGRADE]: What's left?

From: Mike West <mkwst@google.com>
Date: Wed, 11 Mar 2015 06:26:12 +0100
Message-ID: <CAKXHy=cYvN7UKM6VsErti4U=ubMQsyPoN9vjLoq5cTkdr0AO3g@mail.gmail.com>
To: Ilya Grigorik <igrigorik@google.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Brad Hill <hillbrad@gmail.com>, Eric Mill <eric@konklone.com>, Peter Eckersley <pde@eff.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Jeff Hodges <Jeff.Hodges@kingsmountain.com>, Tanvi Vyas <tanvi@mozilla.com>, Yves Lafon <ylafon@w3.org>, T Guild <ted@w3.org>, Daniel Appelquist <appelquist@gmail.com>, Alex Russell <slightlyoff@google.com>, Yoav Weiss <yoav@yoav.ws>, Mark Nottingham <mnot@mnot.net>
On Tue, Mar 10, 2015 at 11:56 PM, Ilya Grigorik <igrigorik@google.com>

> On Tue, Mar 10, 2015 at 3:42 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>> Link: <https://equivalent/path>;rel="secure"
>> Is probably OK.  That means that you have the content from the body of
>> the response, but you can follow the link to find a secure version.
>> Then you only have to worry about minimizing the unsecured junk you
>> are using to base decisions on.
If you consider it reasonable for user agents that prefer secure resources
to follow an explicit `Link` header, wouldn't it also be reasonable for
those user agents to follow an implicit link based on parsing the CSP

The `Link` header makes a lot of sense (and would allow us to perform
cross-origin navigation, or navigation to paths other than the current
resource), but it seems repetitive if we already have the CSP directive.
Moreover, it's dynamic, which might make it difficult for otherwise static
sites to use. The _super_ important `mikewest.org`, for instance, is just a
bunch of pre-generated HTML files with Nginx in front. It is significantly
easier to add a static CSP header than it would be to add a header that
contained a modified version of the request URL.

Given the authors we're targeting (folks with vast archives of potentially
difficult-to-migrate data, among others), I'd really like to reduce the
complexity of opting-into upgrades as much as possible.

> +1. Albeit treating rel=secure as an implicit redirect still feels a bit
> odd to me.

I resolve the oddity for myself by noting that the server _isn't_
redirecting the client. The _client_, based on the information the server
provides, is making a decision for itself about what content to display to
a user. That seems pretty reasonable to me, and in-line with concepts like
responsive images (where the server says "Here are some options. Pick one
that makes sense.").


Mike West <mkwst@google.com>, @mikewest

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
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Wednesday, 11 March 2015 05:26:59 UTC

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