Re: Upgrade mixed content URLs through HTTP header

On 3 February 2015 at 05:04, 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.)

And it's why people pay tens or hundreds of thousands of dollars to
CDNs to support clients who don't send SNI? Clearly not. =)  I think
maintaining compatibility with existing clients is very important for
businesses, and a feature that breaks the experience for some
percentage of them is a feature they won't use.

I'm not opposed to an 'upgrade-unsafe' - but I see it as a stop-gap to
rewriting all the content, not a solution in place of it.

I also don't like coupling: we definitely can't make HSTS
automatically imply some new behavior and break existing sites. [0] If
anything, a new directive should be used.

On 3 February 2015 at 04:50, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, Feb 3, 2015 at 11:16 AM, Mike West <mkwst@google.com> wrote:
>> Let's say we introduce Eduardo's "upgrade-unsafe". What would you expect it
>> to do?
>>
>> I'd expect it to blindly rewrite first- and third-party HTTP images (and
>> etc.) to HTTPS before fetching, which would simply fail for images
>> unavailable over HTTPS. It's not clear to me that that's really worse than
>> the browser telling the user that the page is insecure, and it seems like
>> different site authors would react differently.
>
> This is what I would expect. And from experience with deploying TLS on
> whatwg.org and html5.org I know that we had made sure that the thirty
> or so domains for in use (for both primary and subresources) supported
> TLS. It was just an enormous hassle to make sure that the content also
> matched that. If we had a header to upgrade the content deployment of
> TLS would have gone a lot smoother.

This seems to be a great argument for Mike's proposal to do something
to CSP help people do the content rewriting:

> Content-Security-Policy-Report-Only: default-src https:; report-uri /insecure-resources-go-here/

-tom

[0] This was done inadvertently (I think/hope) with CSP and I thought
it was quite bad.
http://blog.sendsafely.com/post/108919388080/notes-about-chrome-v40-and-content-security-policy

Received on Wednesday, 4 February 2015 02:12:39 UTC