Re: MIX: Exiting last call?

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--thoguh well-intentioned--and thus it's purely
an editorial issue, so marking it at risk pending implementations is
fine with me.

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

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.

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.

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.

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

Received on Monday, 15 December 2014 02:46:27 UTC