- From: Mike West <mkwst@google.com>
- Date: Wed, 18 Feb 2015 15:59:36 +0100
- 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>
- Message-ID: <CAKXHy=czjwzsOixez+yWyfPyUHfLsikL_qocNgecn1_n+g=Lew@mail.gmail.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 -- 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.)
Received on Wednesday, 18 February 2015 15:00:31 UTC