Re: [MIX] Initial feedback on Mixed Content

Mike,

Thanks for considering my feedback. More inline.

On Fri, Nov 14, 2014 at 3:09 AM, Mike West <mkwst@google.com> wrote:
> I agree with the claim that there's overlap between non-normative and
> normative sections. I guess I'm a little more positive on that overlap than
> you are. While it is indeed _sufficient_ for the spec to list the algorithms
> in section 5 and 6 (along with whatever definitions and etc those require),
> I think doing so would make the spec harder for web developers to
> understand.
>
> The non-normative sections provide justification for the normative sections.
>
> That's not to say it's all gold; I agree that section 4 in particular can be
> trimmed down.

Yes, that would be great. I am happy to provide more specific and
concrete feedback, but it would be great to do so after that
reduction.

> I'm less interested in trimming 3 because it gives developers
> a clear delineation, and, to some extent, justification for the way things
> break down. That's important to me.

I mostly agree. However, at a minimum, the enumeration of
currently-known blockable fetch contexts in section 3.2 should be
removed. Although you do say it is non-exhaustive, I think the fact
that you attempted to exhaustively enumerate the ones that are
currently known just makes it confusing. In particular, it will add
fuel to future debates that new types of content were not
appropriately considered. And, it will prompt otherwise unnecessary
updates to the document to keep that enumeration up to date. Removal
also adds emphasis to the ideas that the optionally-blockable content
is a legacy compatibility mechanism, that we intend for future types
of content to be in the blockable category, and that blockable is the
default, all great things to emphasize.

Along those same lines, since that content is most of section 3.2,
removing it would make it more reasonable to combine section 3.1 and
section 3.2, perhaps re-titling the section "Blockable vs.
Optionally-blockable mixed content."

>> 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."
>
> If a website can request a particular video/audio/image, then it's not clear
> that a Service Worker shouldn't be able to do the same (with UI degradation,
> as appropriate). Jake (CC'd) has harangued me with the example of a
> podcasting app, for instance: it's absolutely something we'd want to see
> work offline, and the <audio> tag is perfectly capable of playing back
> insecure content.
>
> Should we block Service Worker from doing the same? I don't think that's as
> clear-cut as you suggest.

This is at odds with the reasoning in section 3, right? I'd like to
stick with the reasoning in section 3, where we tolerate mixed content
for legacy compatibility reasons only. There's no legacy compatibility
impact for ServiceWorker, because there's no legacy ServiceWorker
content.

I can see that my suggestion to disallow all mixed content if a
ServiceWorker is registered is unnecessarily heavy-handed. However, I
am not convinced that the ServiceWorker needs to be able to do
mixed-content, other than rejecting the request or allowing the
default action (the browser's default fetching mechanism) to be used
to return a response to be used as the source for a  <img>, <video>,
or <audio> element.

> Makes sense:
> https://github.com/w3c/webappsec/commit/10b0ac77dbdb6c73b68b1cd0b0622193ebffd787

Looks good.

>> And, it makes it easier to
>> see why it is unnecessary to enumerate any/all of the blockable fetch
>> types.
>
> Technically, I agree with you. Explanatorily, I disagree. :)

Please see my reasoning above. The clearest explanation is that
everything is blockable except the things explicitly listed a
optionally-blockable.

Cheers,
Brian

Received on Tuesday, 18 November 2014 05:03:08 UTC