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

Re: HSTS priming vs preloading

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 2 Feb 2016 10:00:49 +0100
Message-ID: <CADnb78ix=rg3NTPsdTwrDCsi444Bf1yD_TmVUMCqQMnmuKjPXw@mail.gmail.com>
To: Eric Mill <eric@konklone.com>
Cc: Richard Barnes <rbarnes@mozilla.com>, Ben Wilson <ben.wilson@digicert.com>, Jim Manico <jim.manico@owasp.org>, Mike West <mkwst@google.com>, Jim Manico <jim@manicode.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Feb 1, 2016 at 11:27 PM, Eric Mill <eric@konklone.com> wrote:
> However, the underlying issue driving HSTS priming (and why the HSTS check
> currently comes after mixed content checking) is to make it so users have
> deterministic and consistent experiences. Since preloading also guarantees
> that consistency, you could also imagine an interim step being taken, before
> this priming proposal is finalized and before the priming ping is
> implemented anywhere, where preloaded HSTS is put ahead of mixed content
> checking.

I think there are two issues with this:

1. Last I heard some software, e.g., Firefox OS, did not perform
preloading due to the size of the table.
2. What happens if large host providers bundle LE / HSTS / preload?
Scaling the preload system is a good problem to have, but it seems
like we need something there if we are going to make it part of the
way other standards work.

Received on Tuesday, 2 February 2016 09:01:16 UTC

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