Re: An HTTP->HTTPS upgrading strawman. (was Re: Upgrade mixed content URLs through HTTP header)

I was hoping this would work as a *-src directive, since there are sites
that will (for ever) need to fetch http:// resources over XHR (eg,
Chromecast).


On Tue, Feb 3, 2015 at 3:16 PM, Mike West <mkwst@google.com> wrote:

> 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/
>>
>
>