W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: CfC: Transition Mixed Content to CR; deadline Feb 23rd.

From: Brian Smith <brian@briansmith.org>
Date: Tue, 17 Feb 2015 10:12:41 -0800
Message-ID: <CAFewVt5UUWMm3eSrozsHz1HEXwDtJLzC0d0oYK3zLRKMkGgBTA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Wendy Seltzer <wseltzer@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>, Tanvi Vyas <tanvi@mozilla.com>, David Walp <David.Walp@microsoft.com>
On Mon, Feb 16, 2015 at 7:02 AM, Mike West <mkwst@google.com> wrote:
> On the Feb. 9th call[1], we concluded that it was probably time to take the
> Mixed Content spec to CR. To that end, I've published a draft CR document at
> https://w3c.github.io/webappsec/specs/mixedcontent/published/2015-02-CR.html.
>
> I believe the only open question is whether or not to merge the "Upgrade
> insecure requests" draft into the Mixed Content draft.

1. It isn't clear if/how mixed content blocking for window.fetch was
resolved. It seems pretty clear to me that window.fetch should be
treated the same as XHR, but the discussions[1][2] on this topic
stalled. This seems like a fundamental issue to me because if
window.fetch is allowed to fetch mixed content, then much of the rest
of the specification does not make sense. Maybe it is already resolved
in the way that I think is correct; I will reply to the thread at [1].

Other than that, the previously-brought-up issues seem like they were resolved.

Should there be a change based on Microsoft's announcement that they
will treat optionally-blockable content as blockable when the document
is on an HSTS origin? I had thought that the Firefox and Chrome teams
had decided long ago specifically to NOT do that, but it looks like
people want to reconsider that now. Such a change could also happen in
MIX 2, if there will be one.

> Brian suggested doing
> so in [3]. I've responded at [4], but I'd like to explicitly request
> feedback on this topic from the rest of the list. I see ~3ish paths forward:
>
> 1. Publish MIX as-is, and work on the upgrade spec as a separate document.
> 2. Publish MIX as-is, and integrate the upgrade spec into MIX Level 2.
> 3. Integrate the upgrade spec into MIX, and hold off on the CR transition.
>
> I'd prefer #1, for the reasons outlined in [4]. What do you think
> (especially you folks who are CCd on this thread)?

Like I said in the other thread, I think either resolution that
results in all the mixed content stuff from this working group being
in one document is best.

Cheers,
Brian

[1] https://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0094.html
[2] https://github.com/slightlyoff/ServiceWorker/issues/493
Received on Tuesday, 17 February 2015 18:13:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:10 UTC