Re: [UPGRADE] Consider plan B for reduced complexity?

On Fri, Mar 13, 2015 at 5:48 AM, Nottingham, Mark <mnotting@akamai.com>
wrote:

> I think it's drawing a very long bow to think that that only applies to
> user navigation and not subresource dereferences. And, doing a quick test,
> I find that Chrome and Firefox won't load <
> http://www.mnot.net/lib/script.js> when HSTS is in use, but Safari will.
>
> So arguably Chrome and Firefox aren't conformant to HSTS -- or more
> likely, the relationship between mixed content and HSTS hasn't been
> properly specified (as the HSTS spec alludes to).
>

The relationship has been specified (see step 5 of
https://fetch.spec.whatwg.org/#fetching, which comes after MIX and CSP in
step 3).

You're seeing divergent behavior in Safari because Safari doesn't block
mixed content at all. That script will load just fine over HTTP, which
isn't behavior I'd suggest we replicate. Safari does, however, warn you
about mixed content, even if HSTS is in place.

This is in-line with every other browser's behavior (including, I believe,
IE Next). Folks from Chrome have expressed explicit reluctance to change
this behavior, and I haven't seen folks from other browsers disagree.
*shrug*


> In a perfect world, this would have been all figured out before HSTS was
> deployed. As it is, I like Dan's proposal more than
> upgrade-insecure-requests (but will continue to give feedback on the latter
> regardless).


Again, I think this comes down to the developer ergonomics of a host-wide
switch vs a representation-specific switch. The latter has some advantages,
which I've tried to outline in this thread and the other (
https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0049.html,
for example). Did none of that resonate with you?

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)