W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2015

Re: [UPGRADE]: What's left?

From: Ted Guild <ted@w3.org>
Date: Fri, 06 Mar 2015 10:02:53 -0500
Message-ID: <1425654173.2852.23.camel@w3.org>
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

>         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
Received on Friday, 6 March 2015 15:04:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:47 UTC