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

Sounds good to me, then.  Thanks for reading more closely than I!

On Mon, Jul 6, 2015 at 2:28 PM Tanvi Vyas <tanvi@mozilla.com> wrote:

>  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> 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.)
>>
>>
>>
>