[MIX]: Move specifics to a non-normative section/document? (Re: "Mixed Content" draft up for review.)

On Tue, Jun 3, 2014 at 6:31 PM, Brian Smith <brian@briansmith.org> wrote:

> Change 2: I would like to suggest changing the organization of the
> document, spitting it into two primary parts:
>
> Part 1 would define what mixed content is, specify the algorithm(s) for
> determining whether a request is a mixed-content, state that mixed content
> must be blocked in general, and state the intention of the working group(s)
> involved to explicitly prohibit mixed content in any new features added to
> the web platform (like we did when Websockets was defined in the W3C, for
> example).
>

This makes complete sense:
https://github.com/w3c/webappsec/commit/577a06a8f66b6670095d0e44cfa59ddbaf8649d9


> If it isn't reasonable to state that mixed content must be blocked in
> general
>

I don't think we can say "must" when we know that we can't actually do
that. We absolutely should block mixed content images, but there's no way
we're going to do that in any near-term timeframe.


> , then instead this section could enumerate a list of subresource types
> for which mixed-content subresources must not be allowed (e.g. scripts,
> style, WebSockets, XHR, iframes, etc.) and then it could say that mixed
> content for other types of subresources SHOULD be blocked
>

This is what I've tried to do in the spec: active content must be blocked.
Blockably passive content must be blocked. Optionally blockable passive
content may be blocked.

I'll change that last bit to "should":
https://github.com/w3c/webappsec/commit/2a59f53cc3dc8b18309dfd2c563f46d83122c62c


> and that user agents may impose restrictions and/or change those mixed
> content subresource requests in unspecified ways.
>

Interesting idea!
https://github.com/w3c/webappsec/commit/a9b61739c72b17d8d9d4487ae245c232ebd0f817


> Part 2 would document the current behavior of browsers using tables
> similar to Ivan Ristić's. Potentially, it could document the detailed
> taxonomies of mixed content ("active" vs "passive", "optionally-blockable"
> vs "blockable" passive content) used by the browsers along with the
> rationales for those taxonomies.
>

Part of the goal of the spec is to lock in today's rough consensus as a
mandatory baseline. We're working to block mixed XHR and mixed WebSockets
in Chrome, for instance, which brings us in line with Firefox. I have a
patch up right now to block mixed Web Fonts.

I'd like for Part 1 to be normative and for Part 2 to be non-normative.
>

I think we ought to have normative requirements that set that baseline.


>  Actually, I would prefer Part 2 to be a separate document on the W3C Note
> track as opposed to the W3C Recommendation track. There is a lot of
> unexplored territory in improving how browsers block and/or automatically
> correct (e.g. HTTPS Everywhere and similar things) and/or limit the damage
> caused by (e.g. by stripping cookies from some kinds of mixed content
> requests) mixed content requests that they are still allowing.
>

I don't understand why it would be better to explore that territory as a
note rather than as part of the spec. If we think it's a good idea to block
cookies for mixed content requests that we allow through, then let's
mandate that behavior. That seems like a better way of improving the web
for users.


> If we were to document the browsers' current mixed content loading
> behavior in a W3C Recommendation then we'd be encouraging web content
> authors to use mixed content.
>

I don't think that's the case. At least, I hope I've been careful in the
language chosen in the document to ensure that the eventual goal is clear:
mixed content is bad, and it all ought to be blocked. As an example, I
think the "optionally-blockable" nomenclature is new in this doc, and
(hopefully) makes it clear to developers who read the spec that mixed
content images aren't "safe", just "impractical to block today without
breaking the web".

In other words, the fact that the loading of mixed content subresources is
> undocumented and cannot be relied on is itself a disincentive to
> intentionally using mixed-content subresources, and I want to keep that
> disincentive.
>

I'd rather make normative claims which indicate that the list of
optionally-blockable passive content is temporarily larger than we'd like,
and intentionally shrinking over time. That seems like more of a
disincentive than not saying anything normative at all.

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