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

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

From: Mike West <mkwst@google.com>
Date: Wed, 18 Feb 2015 15:59:36 +0100
Message-ID: <CAKXHy=czjwzsOixez+yWyfPyUHfLsikL_qocNgecn1_n+g=Lew@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
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 Tue, Feb 17, 2015 at 7:12 PM, Brian Smith <brian@briansmith.org> wrote:

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

For MIX1, I think it's resolved exactly as you'd like. There's a proposal
floating around that I've pointed to on the other thread, but deferring
that to MIX2 seems like a good way to lock in a baseline you're happy with
before we start talking about things I kinda expect you not to like. :)

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.

I think the current language in MIX that encourages this sort of
experimentation (see
https://w3c.github.io/webappsec/specs/mixedcontent/#further-action) is
enough. If user agents pick up on it and *de facto* standardize on some
behavior, then it's absolutely something we should formalize in MIX2.

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

I'll put that down as a vote for #2. :)

I'll try to jam these together to see how it looks. As I said in the other
thread, I think there's a focus and clarity gained by distinct documents
that I'm not sure we can retain when combining the documents, but I'll take
a stab at it.


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
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Wednesday, 18 February 2015 15:00:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC