- From: Ted Guild <ted@w3.org>
- Date: Fri, 06 Mar 2015 10:02:53 -0500
- To: Mike West <mkwst@google.com>
- Cc: Yves Lafon <ylafon@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Jeff Hodges <Jeff.Hodges@kingsmountain.com>, Tanvi Vyas <tanvi@mozilla.com>, Peter Eckersley <pde@eff.org>, Daniel Appelquist <appelquist@gmail.com>, Alex Russell <slightlyoff@google.com>, Jose Kahan <jose.kahan@w3.org>
Thank you Mike for doing this. On Fri, 2015-03-06 at 11:28 +0100, Mike West wrote: > On Fri, Mar 6, 2015 at 11:10 AM, Yves Lafon <ylafon@w3.org> wrote: > On Fri, 6 Mar 2015, Mike West wrote: > > I've done some work on the "Upgrade Insecure Requests" > spec since the FPWD > was published (and have a 90% functional > implementation behind a flag in > Chrome). I'd appreciate it if folks here would take > another look at the > document to see if we're converging on something we > like: > https://w3c.github.io/webappsec/specs/upgrade/ Especially given how a couple prominent examples are archives you may want to include an archivist perspective. It is not just about the cost of editing all the content but the hesitation for a curator as a preservationist to do so. I would be very reluctant for instance to modify historic content on w3.org that has been untouched for twenty years and predated https being a standard. > The only issue noted in the document is > https://github.com/w3c/webappsec/issues/184, which > suggests changing from a > value-less directive to a whitelist of hosts. I can > see how that would be > valuable, but it seems like a complicated thing to add > if we don't actually > need it. Do folks here think it is necessary? > > Well, if you are able to select what to upgrade on a > fine-grain basis, you are not solving the issue, just reducing > the surface of attacks (the number of insecure links to > upgrade), in that case, they can rewrite part of the content > to that effect. Here the goal was to mass-upgrade things you > were not able to rewrite, so not worth the complexity of > adding it, IMHO. > > > Alright. That's three votes for "Leave it like it is." Thanks! You can add a fourth if that helps. > In particular, I'm CCing some W3C folks (Ted and Yves) > who participated in > an earlier thread[1] to see if this would help them > more quickly migrate to > HTTPS. Hi! Does this help for the W3C's use-case? > > There were a few things, this document addresses the use case > of upgrading content that are not upgraded by HSTS, which is > great! > > > Are there other barriers to migration that this doesn't address? Not that I'm aware of. There is another colleague, Jose Kahan, I would like to consult, he is away at present and can hopefully respond next week. > I'm wondering about the "insecure content warning" on browers, > so would this make the warning disappear in implementations > (ie: is it linked to the enforced policies), but that's more > implementation-specific. > > > Exactly. The intent is to avoid the insecure content warning, and > that's how Chrome's experimental implementation works. Perhaps it's > worth adding a note about that to the document... We would be interested in trying out your experimental implementation against a test instance of our site. -- Ted Guild <ted@w3.org> W3C Systems Team http://www.w3.org
Received on Friday, 6 March 2015 15:04:04 UTC