- From: Brian Smith <brian@briansmith.org>
- Date: Sun, 14 Dec 2014 18:46:00 -0800
- To: Mike West <mkwst@google.com>
- Cc: Michael Cooper <cooper@w3.org>, David Walp <David.Walp@microsoft.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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