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

On Wed, Jun 4, 2014 at 5:40 AM, Mike West <mkwst@google.com> wrote:

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

Thanks. I agree with that change, generally. It is definitely in the spirit
of what I was asking for.


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

If active content and blockable passive content must be blocked, why
distinguish them in the document? I'd rather find a term that identifies
the type of mixed content that we admit we do not know how to block by
default in a reasonable way right now and give it a name (e.g.
"optionally-loadable mixed content"), and drop the finer-grained
distinctoins between the content we're agreeing to block. The rationale and
detailed taxonomy is interesting to some people but it distracts too much
from the main point of the document, which is to specify which mixed
content must be blocked.


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

I agree the document must say which types of content must be blocked and
which types of content should be blocked but may be loaded due to
compatibility reasons. What I am saying is that a lot of the reasoning
behind the taxonomy, and part of the taxonomy itself, is irrelevant.

When Chromium first started blocking mixed content, the Chromium team had a
very well-reasoned argument for what it blocked and why, which is basically
what you have written in the document, though what you've written in the
document reflects newer thinking than what Chromium originally did.

When Firefox implemented mixed content blocking, I pushed us to adopt a
classification system that is mostly compatible with what Chrome was doing:
We'll block all the mixed content we can get away with blocking, and we
won't block the stuff we can't get away with blocking. Then, when
evaluating the security properties of what we ended up with, we saw it made
sense because we were blocking all the most dangerous stuff ("active mixed
content") plus more.

Another way of thinking about it is that Chromium seems (seemed) to focus
more on ensuring the integrity of the page, whereas I tried to get Firefox
to be focused more on optimizing for users' perception and understanding.
The user can't be expected to understand even what an iframe is, so mixed
content iframes have to be blocked, for example. Similar considerations
apply to <a ping> and sendBeacon. But, they apply less to images, videos,
and audio. In theory, a browser could have an infobar that says, .e.g.
"Some of the pictures and videos on this page are not private or secure" or
some better text, and there is a chance that users might not be completely
confused by it.

(Looking at what Firefox does now, I see we've already made a mistake in
not blocking mixed-content sendBeacon and mixed-content <a ping>, and I'll
file a bug to fix that.)


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

I mostly agree with you, but I think it is more important for us to
document what we agree to block already ASAP than it is to document
everything at once. Whether or not we can strip cookies from mixed-content
images and whatnot is something that needs to be implemented and thoroughly
tested, and I think that means it is likely to be too far off in the future
to be in the first version of this document.


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

That seems like it could be reasonable. I'd say that what you said in this
paragraph is really all we need to say in explaining why, for a whitelist
of types of content, we avoid saying that mixed content loads MUST be
blocked. We may want to also explain the negative consequences of that
(e.g. leaking cookies, confusing user interface, etc.) but I don't think
the document needs to have a lot of text justifying allowing the loading of
that content.

Cheers,
Brian