Re: "Mixed Content" draft up for review.

On Fri, May 30, 2014 at 11:04 AM, Mike West <mkwst@google.com> wrote:

> As we (briefly) discussed in the May 7th call[1]
> <http://www.w3.org/2011/webappsec/draft-minutes/2014-05-07-webappsec-minutes.html#item07>,
> mixed content is poorly defined, and doesn't really belong in either Fetch
> or CSP directly. I've put together a draft "Mixed Content"
> specification[2] <https://w3c.github.io/webappsec/specs/mixedcontent/> in
> the hopes of addressing those concerns.
>
> This draft does not attempt to invent new functionality, but instead to
> document and refine the mixed content behavior user agents already exhibit.
> I hope it contains no real surprises. Your feedback would be very much
> appreciated.
>

<snip>


> [2]: https://w3c.github.io/webappsec/specs/mixedcontent/
>

Hi Mike,

Thanks for writing this. I'd like to suggest two large changes:

Change 1: I would like to have the scope expanded beyond TLS-protected vs.
non-TLS-protected. In particular, I'd like to see Firefox's rules for
blocking file:// subresources in non-file://-documents incorporated into
the specification. I'd also like to see the MSIE11's zone rules for local
(intranet) vs. non-local (internet) servers considered for incorporation
(something that Firefox is also working on adopting). This way, the
specification would completely document/define which origins a subresource
could be loaded from as a function of the document's origin. This would
also solve the problem with defining "assumed secure origin."

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). If it isn't reasonable to state that mixed content must be
blocked in general, 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 and
that user agents may impose restrictions and/or change those mixed content
subresource requests in unspecified ways.

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.

I'd like for Part 1 to be normative and for Part 2 to be non-normative.
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. 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. 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.

Cheers,
Brian