Re: HSTS priming vs preloading

On Mon, Jan 18, 2016 at 3:15 PM, Mike West <mkwst@google.com> wrote:

> 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.
>

Got it -- I was very aware of the proposal, but hadn't connected the dots
to how it would generally move HSTS checking to before MIX checking.


>
> -mike
>



-- 
konklone.com | @konklone <https://twitter.com/konklone>