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

Re: [UPGRADE]: What's left?

From: Yoav Weiss <yoav@yoav.ws>
Date: Fri, 6 Mar 2015 20:33:36 +0100
Message-ID: <CACj=BEgF_T6iWLaFrNHFrw+eckast5xRd-itK2cDDUA18FGdbw@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: 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>, Ilya Grigorik <igrigorik@google.com>
On Fri, Mar 6, 2015 at 7:43 PM, Mike West <mkwst@google.com> wrote:
>
>
> Unfortunately that does mean this mechanism is going to add a lot of
>> bytes on the wire, and we should consider mitigations like shortening
>> the Prefer: header, or only sending the Prefer: header for magic HTTPS
>> URLs like favicon.ico (since it's just going to be there to refresh
>> HSTS once every so often).
>
>
> +Ilya and Yoav, who are poking at me about bytes on the wire in a separate
> thread. I assume they have thoughts that are relevant here. :)
>

Thanks, Mike! :)

Well, since at the Client-Hints effort we've heard similar concerns about
sending even shorter headers on all navigation requests without an opt-in
mechanism, I started wondering about the justification of the "Prefer"
header here, and the benefits that over an opt-in only mechanism.

What would be the consequences of the Upgrade mechanism only working as a
way to get sites onto an "HSTS-lite" list, so that future navigations would
be over HTTPS with their sub-resources upgraded, rather than blocked? What
would be the lose in privacy/security here, vs. the benefits of not sending
extra headers on each navigational request?
Received on Friday, 6 March 2015 19:34:04 UTC

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