Re: MIX: Exiting last call?

On Mon, Dec 15, 2014 at 3:46 AM, Brian Smith <brian@briansmith.org> wrote:
>
> Mike West <mkwst@google.com> wrote:
> > 1. Brian, you suggested that "deprecated TLS-protection" ought to be
> removed
> > from the spec, if only because no one has implemented it yet.
>
> That is a very incomplete, to the point of being
> misleading--unintentially, no doubt--summary of my explanation as to
> why it should be removed. However, because there are no SHOULD/MUST
> requirements in that section, I also feel like the section is
> effectively meaningless--though well-intentioned--and thus it's purely
> an editorial issue, so marking it at risk pending implementations is
> fine with me.
>

Sorry. I didn't mean to misstate your position. I'm glad to hear, however,
that the compromise sounds like a reasonable resolution to you. I've marked
the concept as "at risk" in the current draft.


> > Are there other pieces of feedback I've missed, or whose authors believe
> > haven't been adequately addressed? Barring negative responses here, I'd
> like
> > to issue a CfC next week to kick off the formal process of moving to CR.
>
> Yes, there are four issues that I think haven't been adequately addressed:
>
> 1. I appreciate you incorporated most of my feedback in [1]. However,
> at least one very unimportant point in that message was not addressed.
> In explaining the criteria for determining whether something should be
> considered optionally-blockable mixed content, the current draft still
> says "This could be because mixed usage of the resource type is
> sufficiently high, or because the resource is low-risk in and of
> itself." As I noted in my earlier message, it is important to change
> the "or" to "and". "And" accurately reflects the logic that was used
> to arrive at the policy as it was written (except, possibly, for
> window.fetch; see below), and is also consistent with the idea that we
> intend to avoid adding new kinds of optionally-blockable mixed content
> in the future. Conversely, "or" creates a very--too--weak policy for
> us going forward. Because this establishes policy, it isn't an
> editorial issue or a minor issue, despite being a tiny change
> textually, and must be resolved before going to CR because it could
> have substantial effects on other parts of the document.
>

Changed.


> 2. In [2] and [3], it was noted that the way that HSTS is dealt with
> in the Fetch and Mixed Content draft standards does not match how
> Chrome and Firefox actually do mixed content blocking. Again, I'm
> happy to defer to others on the topic, but the inconsistency should be
> resolved ASAP. MSIE 11 is implementing HSTS, and it could be very
> problematic if major browsers disagree on this, which would happen if
> Microsoft does what is currently written in the draft specs. I'm not
> sure how much of this is a Mixed Content spec issue and how much of it
> is a Fetch spec issue.
>

This is currently step 1 of https://fetch.spec.whatwg.org/#fetching, and it
doesn't match reality in any browser I know of. We've heard from Chrome
folks (Ryan and Adam) who are uninterested in changing Chrome's
implementation to match that spec. It would be useful to get similar
opinions from the responsible folks at Mozilla. If they're similarly
disposed, changing Fetch seems like a reasonable resolution.


> 3. Whether to change how currently-optionally-blockable mixed content
> in iframes is dealt with [4]--in particular, whether to treat all
> mixed content in iframes as mixed content--hasn't been adequately
> addressed. There doesn't seem to be sufficient agreement either way,
> and also we lack sufficient data to make a determination about the
> feasibility of making a change. My suggestion would be to note the
> issue as something to be resolved during CR/PR, if that can be done
> without prejudice against making the change to block it if we get data
> showing it is feasible.
>

We ended up in
http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0355.html; I
think it's totally reasonable to add something to frames that would
silently block all mixed content in any nested browsing context to give the
parent some assurance regarding the page's security indicator.

I don't think this is something we could add at CR; it's really a new
feature. It's not clear to me that there's sufficient agreement on what we
should do here to proceed, but I'll draft some text that we can argue
about. :)


> 4. In [5] and [6], I suggested changing the rules for ServiceWorkers.
> As I said before, I agree that my initial proposal was unnecessarily
> heavy-handed. However, I made a follow-up suggestion that allows a
> ServiceWorker to avoid breaking a page that has mixed content, without
> allowing window.fetch to become a new vector for mixed content
> vulnerabilities. Since window.fetch is almost the same as XHR, it
> doesn't make sense for window.fetch to have a significantly different
> mixed content policy than XHR. This is a fundamental problem with the
> current draft that hasn't been sufficiently addressed.
>

I'm going to fork this into a separate thread, because I expect it will be
a longer conversation.


>
> Cheers,
> Brian
>
> [1] http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0340.html
> [2] http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0305.html
> [3] http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0307.html
> [4] http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0249.html
> [5] http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0282.html
> [6] http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0283.html


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