- From: Tom Ritter <tom@ritter.vg>
- Date: Tue, 3 Feb 2015 20:11:51 -0600
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Mike West <mkwst@google.com>, 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 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