Re: [MIX] Initial feedback on Mixed Content

On Fri, Nov 14, 2014 at 4:59 AM, Brian Smith <brian@briansmith.org> wrote:

> I read the editor's draft, not the working group draft.
>

Thanks for the feedback!


> Generally, I think that this draft has way too many unnecessary words,
> with a lot of non-normative text repeating the normative text.


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

But yes, by all means suggest specific things to excise. I'm desperately in
love with any particular thing in the doc.

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.


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


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


> 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. :)

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