- From: yan <yan@eff.org>
- Date: Mon, 10 Aug 2015 15:14:57 -0700
- To: Brad Hill <hillbrad@gmail.com>, Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Alex Russell <slightlyoff@google.com>, Peter Eckersley <pde@eff.org>
+ pde On 8/10/15 1:59 PM, Brad Hill wrote: > I think that we could call it done and think about adding just > 'upgrade-insecure-navigations' to a Level 2. I think it is beneficial > to have that scope expansion available as extra behavior, but I don't > see any good use cases to formally "decompose" > upgrade-insecure-resources out of the existing behavior. (where it could > only be used to weaken mixed content fetching, which we don't want to do > and won't necessarily ever produce good results) Firefox/Chrome doesn't block passive mixed content. Tor Browser doesn't even block active mixed content by default. In both cases, sites can use the header with a source set to upgrade as many resources as possible. I think it's good to encourage this best-effort behavior. > > On Mon, Aug 10, 2015 at 6:46 AM Mike West <mkwst@google.com > <mailto:mkwst@google.com>> wrote: > > I believe https://github.com/w3c/webappsec/issues/184 is the only > outstanding issue on UPGRADE at the moment. The goal there is to > split the behavior into "navigational" and "other", and turn both > into source lists. We'd end up with something like (insert naming > bikeshed) `upgrade-insecure-navigations example.com > <http://example.com> other-example.com <http://other-example.com>; > upgrade-insecure-resources cdn.example.com <http://cdn.example.com> > othercdn.example.com <http://othercdn.example.com>`, and the current > `upgrade-insecure-requests` would desugar into > `upgrade-insecure-navigations [insert protected resources' host]; > upgrade-insecure-resources *`. > > Before I dive into adding that to the text, I'd like to determine > whether it's necessary. :) > > Right now, we have two more or less compatible implementations of > the current spec (though I think Firefox doesn't yet send the > signaling header). I haven't heard any requests for the > functionality from folks using the header, just from Brad and Yan. > Is it something we should add before moving to CR? It would explain > the current functionality with better primitives, but it's not clear > to me whether it's worth the added complexity. > > Brad, Yan, Alex? If any of you (or anyone else, really) feels > strongly about it, that's probably good enough, but if this is just > a nice-to-have, I'd suggest we punt it and just call v1 done. > > -- > Mike West <mkwst@google.com <mailto: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.) >
Received on Monday, 10 August 2015 22:16:27 UTC