I put together a tiny strawman to explore how this upgrade mechanism might work: https://w3c.github.io/webappsec/specs/upgrade/ I think it has some real potential as a CSP directive, especially in combination with the pinning draft which is up for review. WDYT? (Forking the thread, as this diverges a bit from Anne's original intent, and I don't want to derail that conversation entirely.) -- Mike West <mkwst@google.com>, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) On Tue, Feb 3, 2015 at 12:04 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > 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 14:17:07 UTC