Re: HSTS priming vs preloading

On Mon, Jan 18, 2016 at 9:11 PM, Eric Mill <eric@konklone.com> wrote:

> On Mon, Jan 18, 2016 at 7:11 AM, Mike West <mkwst@google.com> wrote:
>
>> On Mon, Jan 18, 2016 at 1:05 PM, Jim Manico <jim@manicode.com> wrote:
>>
>>> Forgive this indulgence, but does HSTS preloading have the same benefits
>>> of HSTS priming since preloaded HSTS would occur before the mixed content
>>> check?
>>>
>>
>> Yes. Basically, we'd only do a priming ping if the origin being requested
>> wasn't already marked as HSTSized in the user's local browser. The fact
>> that we _would_ do a priming ping for non-secure origins that aren't in the
>> local browser's HSTS list ensures that we can do the upgrade without
>> breakage.
>>
>
> I may be remembering wrong, but I didn't think HSTS alone (preloaded or
> dynamic) would resolve mixed content issues.
>
> The stated concern with allowing HSTS to affect mixed-content rendering is
> that it would create different experiences per-user/session, and preloading
> does mitigate this concern, but I didn't think there was an actual code
> path in Chrome (or other browsers) where it decides to allow HSTS to
> override mixed content if the HSTS policy was preloaded.
>

Right. That's how it works in the status quo. In the brilliant and colorful
world of tomorrow, Richard's "priming" (not "preloading", and not
"pinning", and not any other word that starts with "P") proposal is meant
to address this: https://mikewest.github.io/hsts-priming/

With that proposal, we could move HSTS up before MIX in the Fetch ordering,
as we'd guarantee the same experience for everyone by priming the pump
before sending the request out onto the wire.

-mike