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

Re: Upgrade mixed content URLs through HTTP header

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 3 Feb 2015 12:04:15 +0100
Message-ID: <CADnb78iheA7v794ZPkA9QFfrmMQ=OXQS8C7KsczDWxWCE3ehPA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Ryan Sleevi <sleevi@google.com>, "Eduardo' Vela" <evn@google.com>, Wendy Seltzer <wseltzer@w3.org>, Adam Langley <agl@google.com>, WebAppSec WG <public-webappsec@w3.org>, Peter Eckersley <pde@eff.org>
On Tue, Feb 3, 2015 at 11:53 AM, Mike West <mkwst@google.com> wrote:
> My worry is that we're papering over the problem for newer clients, thereby
> removing incentive to fix the problem for existing clients.

I don't really see this as a big deal. Compatibility with existing
clients is not interesting long term. (If it was we would not have had
the Host header, we would not have had SNI, etc.)


> While I agree
> with Peter's earlier assertion that we shouldn't hold up progress, I think
> this is a concern we'd need to address in order to ensure that sites and
> applications remain as accessible as possible.
>
> Ensuring that CSP-Report-Only works correctly is important, for example.

I'm not really convinced. Why would there be a report if the content
is augmented in such a way that ensures successful fetches? The only
reason would be legacy clients (which fade away). Perhaps during the
transition user agents could issue a warning of sorts.

Say we make this upgrade-downgrade part of CSP. That means Fetch has
another CSP hook (somewhere as first step) to "upgrade downgrade
URLs". CSP could use that opportunity to return an upgraded URL and
issue a warning (or store the warning to be reported later at some
synchronization point).


-- 
https://annevankesteren.nl/
Received on Tuesday, 3 February 2015 11:04:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:10 UTC