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

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)

2) upgrade-insecure-requests also doesn't mandate that optionally-blockable
mixed content be blocked if an upgrade fails.

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.

-Brad

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