[MIX] Initial feedback on Mixed Content

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