Intent to Ship: Upgrade Insecure Requests.
Mike West
Contact emails
Spec
https://w3c.github.io/webappsec/specs/upgrade/
Summary
We encourage authors to transition their sites and applications away from insecure transport, and onto encrypted and authenticated connections, but mixed content checking causes headaches. This feature defines a CSP directive which allows authors to ask the user agent to transparently upgrade HTTP resources to HTTPS to ease the migration burden.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/rjeFL53OV4I/_NvMh0_qsWEJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Demo link
https://mikewest.github.io/upgrade-demo/ (flip the "Experimental Web Platform Features" flag in Canary to avoid the mixed content error. Wow, right?).
Debuggability
1. Network requests will show up in the inspector, just as any other request will.
2. Content Security Policy's report only mode can be used to track down upgraded requests, as discussed in https://w3c.github.io/webappsec/specs/upgrade/#reporting-upgrades.
Compatibility Risk
Moderate to low.
We've had spirited discussion on the public-webappsec@ mailing list (the threads at https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0005.html and https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0015.html are illustrative). While there's still discussion about what we can do by default, and some details of the spec (https://github.com/w3c/webappsec/issues/184, for instance), I believe we've got what we need for a minimum-viable implementation that we can ship to developers to start gathering feedback regarding whether or not this actually solves real-world problems. I suspect that we'll end up wanting to more than the current state of the spec, and I very much doubt that we'll end up wanting to do less.
Mozilla hasn't signaled disagreement with the spec, but also hasn't been incredibly positive. https://bugzilla.mozilla.org/show_bug.cgi?id=1139297 covers the feature, but no one has picked it up yet. CCing Anne and Tanvi to see if they have thoughts.
Microsoft hasn't participated much since the publication of the FPWD. CCing Crispin and David to see if they have specific feedback.
Yoav reviewed most of the patches, and mnot@ had some feedback, both of which I'll take as an explicit signal that Akamai supports the plan at the highest levels of their org.
The Let's Encrypt folks at EFF are excited about it (though they want even more), and plan to use the feature as part of their deployment toolset. If that takes off, a certain subset of sites might come to depend upon the feature over HTTPS, and fail to work without it due to mixed content errors. I think this in particular is somewhat low risk, given that these sites still support HTTP and the feature detection outlined in https://w3c.github.io/webappsec/specs/upgrade/#feature-detect will allow them to downgrade browsers that don't support the feature (that was the main driver of adding those signals to the spec). CCing Peter Eckersley to verify that I'm not overstating his enthusiasm for the spec as it stands.
OWP launch tracking bug?
Link to entry on the feature dashboard
https://www.chromestatus.com/features/6534575509471232