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

Hi Brad,

On 7/6/15 1:55 PM, Brad Hill wrote:
> Tanvi,
>
> 1) upgrade-insecure-requests does not cascade to child browsing 
> contexts like iframes.  So if I want to guarantee that, e.g. an 
> advertisement served in an iframe could never "break the lock" of the 
> parent page (a common request from many resource operators)
upgrade-insecure-requests does cascade per 
http://www.w3.org/TR/upgrade-insecure-requests/#nesting.  Firefox has 
implemented this and it's close to landing.  Mike, does Chrome's 
implementation enforce upgrades on nested contexts?

> 2) upgrade-insecure-requests also doesn't mandate that 
> optionally-blockable mixed content be blocked if an upgrade fails.
>
I don't see any language in the spec distinguishing between blockable 
and optionally-blockable content.  Firefox's implementation treats them 
both the same.  If the upgrade fails, the resource doesn't load.  Mike, 
can you comment on Chrome's implementation

> I think we could make the semantics of upgrade more strict, but 
> they're really targeting different things.  "Upgrade" is really 
> targeted to a resource I control with "hard-coded" links to other 
> resources I'm pretty sure are available over https.  "Strict" is 
> targeted for making sure that even 3rd party content I don't control, 
> may not know about in advance, and which may not have secure 
> equivalents available, can never will make an http request in the 
> context of my resource or its child contexts.
>
Given the above, I think upgrade meets the use case you describe for 
strict - it ensures that 3rd party content can never make an http 
request in your context.

> -Brad
>
> On Mon, Jul 6, 2015 at 12:25 PM Tanvi Vyas <tanvi@mozilla.com 
> <mailto:tanvi@mozilla.com>> wrote:
>
>     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.)
>