Re: [spec-reviews] Strawman spec review for upgrade insecure requests (#54)

> +
> +### IDEA: Allow Sites to Signal That They Are Upgradeable Resources
> +
> +One downside of fetch (and Firefox/Chrome's implementation of mixed content
> +blocking) is that HSTS is applied after mixed content blocking has happened. So
> +sites that are known to support HTTPS are *still* blocked.
> +
> +This spec allows a site to indicate that its subresouces should be upgraded.
> +However, there is still no way for a site to say, "Upgrade me when I am
> +a subresource, because I know I support HTTPS."
> +
> +## End Notes
> +
> +This draft is a very welcome move towards better handling of mixed content
> +blocking. However, in its current form, it entirely depends on the *embedding*
> +site setting the CSP header. We would like to see ways for the *embedded* sites

The non-determinism seems workaroundable - send a preflight before mixed content blocking to see if the resource serves the HSTS header?

A more convincing reason agl brought up is that sites who do the work of turning on HTTPS can usually do the work of sending the upgrade-insecure header at the same time, so this mechanism isn't actually useful except as a belt-and-suspenders approach to the mixed content problem. 

But I'm now in agreement that this doesn't seem to be worth the added complexity. :)

yay progress!

---
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/pull/54/files#r29879976