- From: Brian Smith <brian@briansmith.org>
- Date: Thu, 13 Nov 2014 19:59:45 -0800
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
I read the editor's draft, not the working group draft. Generally, I think that this draft has way too many unnecessary words, with a lot of non-normative text repeating the normative text. As a reviewer of the document, it is basically impossible to be certain that the repeated stuff is consistent. To be clear, I'm not saying the work is bad. I think overall it is great work. But, there's just too many words. Here's a strawman proposal: Delete everything except section 5, section 6, and section 8. What stuff in the other sections is truly necessary? Imagine that we were doing this in the HTML working group. There's no way we would add so much text into the HTML spec. (It's a stawman: I know we can't/shouldn't delete all of the rest of the text. However, I think a large amount of cutting is warranted, and the default should be to cut rather than keep.) I disagree with the way the mixed content blocking was integrated with Fetch for "a priori insecure" requests. In particular, if the fetch should fail with a synthesized network error if a Service Worker would handle the request. Otherwise, the Service Worker could easily subvert the blocking of Websocket and XHR requests. The support of mixed content images, video, and audio content is done for legacy reasons. However, there is no legacy use of Service Workers. If a website that has mixed content wishes to use Service Workers, then they will notice and fix the mixed content before they do so. In particular, the types of sites that are going to be using Service Workers in the short term already do pretty well as far as mixed content is concerned. To fix this, I suggest adding an additional step along the lines of "If any service worker was registered, then return blocked" before "If request’s mode is CORS or CORS-with-forced-preflight, return blocked." Also, please replace "If context is a blockable request context, return blocked." with "If context is a not an optionally-blockable request context, return blocked." In other words, operate as a whitelist, not a blacklist. This way, you don't even have to define "blockable" only "optionally-blockable". And, it makes it easier to see why it is unnecessary to enumerate any/all of the blockable fetch types. Cheers, Brian
Received on Friday, 14 November 2014 04:00:15 UTC