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

On Tue, Jun 10, 2014 at 7:12 AM, Mike West <mkwst@google.com> wrote:

> On Tue, Jun 10, 2014 at 12:34 AM, Brian Smith <brian@briansmith.org>
> wrote:
>
>> 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.
>>
>
> I'm not entirely convinced that removing the "active" and "passive"
> definitions from the doc is the right thing to do. Given how widely used
> those terms are when discussing mixed content on the web, it would be nice
> to have normative definitions folks can refer to.
>

Let's look at what is currently defined in the draft as
optionally-blockable passive content:

   * Images loaded via img
<http://www.w3.org/html/wg/drafts/html/CR/embedded-content-0.html#the-img-element>
or picture (includes SVG)
   * Video loaded via video
<http://www.w3.org/html/wg/drafts/html/CR/embedded-content-0.html#video>
and source
<http://www.w3.org/html/wg/drafts/html/CR/embedded-content-0.html#the-source-element>
elements
   * Audio loaded via audio
<http://www.w3.org/html/wg/drafts/html/CR/embedded-content-0.html#audio>
and source
<http://www.w3.org/html/wg/drafts/html/CR/embedded-content-0.html#the-source-element>
elements
   * Subtitles and captions loaded via track
<http://www.w3.org/html/wg/drafts/html/CR/embedded-content-0.html#the-track-element>
elements
   * Beacon [BEACON]
<https://w3c.github.io/webappsec/specs/mixedcontent/#biblio-beacon>
and hyperlink
auditing pings
<http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#hyperlink-auditing>
   * Prefetched content
<http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#hyperlink-auditing>

(I think prefetched content is something quite different than the rest of
this stuff so I'm going to ignore it for now.)

You and I already seem to agree that BEACON and <a ping> should be blocked
and I haven't heard anybody suggest otherwise, so let's remove them from
the list. Now, I would guess that there is not much existing <track> or
<picture>/<srcset> content either, so I think we could probably block those
now without any significant compatibility impact. And, I wouldn't be
surprised if we were to find that there is very little <audio> mixed
content either. So, why not just start blocking all of those right away too?

Then, potentially the only things that wouldn't be blocked by default would
be <img> and <video>. If that were to become the case soon, and we also
agree we're going to block all new kinds of mixed content by default, then
the old active vs. passive distinction would be more confusing than
helpful, since it would have basically no relation to how we ultimately
decide why mixed content <img> and <video> are not blocked but other kinds
of mixed content (even things that have the same security considerations
like <picture>) are blocked.


> I think that's pretty reasonable. The current document has a "User agents
> MAY screw with mixed content requests however they like." clause (#4 in section
> 4.1
> <http://w3c.github.io/webappsec/specs/mixedcontent/#requirements-fetching>);
> I think that's probably enough for this version of the doc. It gives
> browsers room to experiment, and we can come back to the WG with
> experiences to share.
>

Yes, I think that is quite reasonable.

Cheers,
Brian