Re: CfC: Mixed Content to PR; deadline July 6th.

Hi Mike,

I still have concerns about Strict Mixed Content Checking[1] and 
upgrade-insecure-requests[2] as discussed here:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/MafYMJ3zQw0/hnVVOM4drh4J

I don't see why any website would choose Strict Mixed Content Checking 
(where content is blocked with no fallback) over 
upgrade-insecure-requests (where the browser tries the https version and 
only blocks if it doesn't exist).  The website will function better in 
the latter case.  In both cases, there is no Mixed Content Blocker UI in 
the browser chrome.  If the website wants reports on when an upgrade 
might happen, it can use csp in report-only-mode.

When Strict Mixed Content Checking was written, 
upgrade-insecure-requests didn't exist.  Now that it does, we should 
consider removing Strict Mixed Content Checking from the spec.  Are 
there use cases for strict that upgrade doesn't cover?

Thanks!

~Tanvi

[1] http://www.w3.org/TR/mixed-content/#strict-checking
[2] http://www.w3.org/TR/upgrade-insecure-requests/
On 6/22/15 7:17 AM, Mike West wrote:
> Hello, webappsecians!
>
> Mixed Content (http://www.w3.org/TR/mixed-content/) has been up as a 
> candidate recommendation since March 17th. The final patent exclusion 
> period expired on May 17th 
> (https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0178.html). 
> In the CR, we suggested that a transition to proposed recommendation 
> could be possible after a comment period extending through July 1st. 
> As that date is rapidly approaching, this is a Call for Consensus to 
> transition to Proposed Recommendation based on the version of the 
> document at:
>
> https://w3c.github.io/webappsec/specs/mixedcontent/published/2015-07-PR.html
>
> This document is substantively the same as the CR, with the following 
> normative changes:
>
> 1. I've dropped the "at risk" note for "deprecated TLS-protection": 
> https://github.com/w3c/webappsec/commit/5dd23ba69ecd39a45eceff86533dfb91f0ab645c 
> (CCing Brian, who I believe was interested in the opposite, and Ryan, 
> who might or might not have implemented the SHA-1 bits for Chrome).
>
> 2. The CA/B forum's "baseline requirements" were inadvertently listed 
> as a normative reference. The new draft correctly lists them as 
> informative: 
> https://github.com/w3c/webappsec/commit/90067b887e16d259dc01f712c7a48a0ab6e3f583.
>
> A full list of changes can be found at 
> https://github.com/w3c/webappsec/commits/master/specs/mixedcontent/index.src.html 
> (and they're almost all in response to =JeffH's comments at 
> https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0107.html).
>
> Kristijan is putting the finishing touches on an extensive test suite 
> at https://github.com/w3c/web-platform-tests/pull/1889, and we expect 
> it to land in the near future. Interested folks are encouraged to play 
> around with the suite now. We expect substantial agreement on behavior 
> across Chrome, Firefox, Internet Explorer/Edge, and (hooray!) the beta 
> release of Safari on iOS9 and El Cap.
>
> If you have any comments or concerns regarding this CfC, please reply 
> to public-webappsec@w3.org <mailto:public-webappsec@w3.org> by the end 
> of June 6th at the latest. Silence will be interpreted as glowing 
> praise and full-throated agreement, but I'd encourage you to praise 
> full-throatedly, glowingly, _and_ explicitly on the list. :)
>
> Thanks!
>
> --
> 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.)