Which "this" do you mean? If you mean "taking HSTS into account for MIX decisions", then you're not going to get much, since AFAIK no browser has implemented it yet. On Tue, Jan 19, 2016 at 10:00 AM, Jim Manico <jim.manico@owasp.org> wrote: > Does anyone have an online test for this? I think understand and > standardizing this behavior is important. > > - Jim > > > On 1/18/16 3:11 PM, Eric Mill 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> >> 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. > > -- Eric > > >
Received on Tuesday, 19 January 2016 16:47:05 UTC