Re: Mixed Content Spec feedback

Hi David! Thank you for your feedback!

When describing passive content, the spec currently states
<http://w3c.github.io/webappsec/specs/mixedcontent/#categories-passive> "Future
versions of this specification will update these subcategories with the
intent of moving towards a world where all mixed content is blocked; that
is the end goal, but this is the best we can do for now." Is that a
statement that Microsoft can get behind?

If so, then the proposal to allow certain types of XHR responses seems to
move in the wrong direction, as there's general agreement between vendors
today (the latest versions of Firefox and IE both block mixed XHR, and I've
just landed a similar patch in Blink).

Allowing media to flow over unencrypted channels on an otherwise encrypted
site opens up some real concerns, especially with regard to content
filtering or targeting of users based on content viewed. I'm sympathetic to
performance concerns, but I don't believe they should be overriding given
this wider context.

-mike


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


On Wed, Jul 2, 2014 at 2:32 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Jul 2, 2014 at 4:43 AM, David Walp <David.Walp@microsoft.com>
> wrote:
> > To address this use case we would propose that "arraybuffer" response
> > types be categorized as "Optionally-blockable passive content".
> > Although there are methods to pass non-media content through an
> > array buffer, we think the both server and client would need to
> > participate (agree in the encoding) in order to use an arraybuffer as a
> > security hole.  Because both sides would need to be complicit, the
> > exploitable surface area seems acceptable.
>
> Wait what? ArrayBuffer encompasses everything. If you allow
> ArrayBuffer you might as well allow the rest too. That's not helping.
> Besides, it's already demonstrated that XMLHttpRequest can be blocked
> (yay us) and that media sites, such as YouTube, can run over TLS.
>
>
> --
> http://annevankesteren.nl/
>
>