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
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
While I am in favor of this change, once it's launched it will be very hard to undo because sites will start to rely on it and a rollback will cause mixed content warnings to appear. So I'd like to see explicit support from the Chrome security team before giving my looks-good-to-me.
I looked more closely at the spec with Mike's help, and realized that I misunderstood some aspects.LGTM, but would still like to hear from others on Chrome security team that they agree this is a good change.
LGTM3, but it's only been 22 hours, so maybe wait for a few days to give everyone time time to object if necessary.
> 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.
I don't know that I'd go quite that far
but the security folks that I've talked to about it like it too. I'll take another look at the spec and chat with you if I have any remaining concerns.