Re: UPGRADE: Do we need granular control?

+ 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