Intent to Implement: opt-in to upgrading insecure resource requests.

[Mike West]

Contact emails

mk...@chromium.org

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.

Motivation

https://w3c.github.io/webappsec/specs/upgrade/#intro lays out the main use-case: we'd like folks to upgrade to HTTPS from HTTP, but mixed content blocking makes that difficult, especially for folks with large, legacy sites they'd need to update by hand. This mechanism allows authors to ask the user agent to do some work on their behalf.

Compatibility Risk

Moderate.

The feedback from Mozilla and EFF has been positive (see the thread at https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0037.html), but we're still very much in flux with regard to feature's contours: it's not at all clear that the proposed solution is the right one. An experimental implementation will allow authors (and other folks in WebAppSec) to play around with the behavior in order to determine whether it has the properties we want.

Happily, the implementation turns out to be relatively trivial (strawman https://codereview.chromium.org/901903003/), which I hope justifies the early and flexible experimentation with the semantics.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug?

https://crbug.com/455674

Link to entry on the feature dashboard

https://www.chromestatus.com/features/6534575509471232

Requesting approval to ship?

No. Not even close.

-mike

[Philip Jägenstedt]

I've had a quick look at the introduction and outline of the spec,
sounds pretty great to me! SPGTM!

Quote from http://open.blogs.nytimes.com/2014/11/13/embracing-https/
"To successfully move to HTTPS, all requests to page assets need to be
made over a secure channel. It’s a daunting challenge, and there are a
lot of moving parts. We have to consider resources that are currently
being loaded from insecure domains — everything from JavaScript to
advertisement assets."

From the CL, it looks this is all one needs to add:
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-content">

Or a HTTP header, if the content is hard to modify.

Philip

> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[Yoav Weiss]

On Thu, Feb 5, 2015 at 5:15 PM, Philip Jägenstedt <phi...@opera.com> wrote:

I've had a quick look at the introduction and outline of the spec,
sounds pretty great to me! SPGTM!

Quote from http://open.blogs.nytimes.com/2014/11/13/embracing-https/
"To successfully move to HTTPS, all requests to page assets need to be
made over a secure channel. It’s a daunting challenge, and there are a
lot of moving parts. We have to consider resources that are currently
being loaded from insecure domains — everything from JavaScript to
advertisement assets."

From the CL, it looks this is all one needs to add:
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-content">

Well, assuming that your 3rd party assets *can* be served over HTTPS ;)

But I totally agree that this would make the life of content providers moving to HTTPS significantly easier. 

[Chris Harrelson]

LGTM++

This is great. Incremental is the best strategy for upgrading web content.

[Alex Russell]

This is AMAZING. It's going to solve massive problems for Service Worker adopting sites....can't have this soon enough.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.