Re: [MIX] Initial feedback on Mixed Content

I trimmed things up a little bit today:
https://github.com/w3c/webappsec/compare/96b18716431c7107e6744a7f04f6d1e298a3201f...master
WDYT?

I doubt it addresses all of your concerns, but it's what I had time for
today. :)

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Tue, Nov 18, 2014 at 6:02 AM, Brian Smith <brian@briansmith.org> wrote:

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