W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2015

Re: CfC: Mixed Content to PR; deadline July 6th.

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 6 Jul 2015 10:17:31 -0700
Message-ID: <CACvaWvaPsEWSho8sSBR8tE7DmRN9CwqrdGRVt_RT4o2uO+U_=Q@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: Mike West <mkwst@google.com>, Anne van Kesteren <annevk@annevk.nl>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>, Brad Hill <hillbrad@gmail.com>, Kristijan Burnik <burnik@google.com>
On Mon, Jul 6, 2015 at 10:14 AM, Brian Smith <brian@briansmith.org> wrote:

> 1. Nobody implemented it, so we don't really know if it can be
> implemented. In fact, my understanding, from observing Google's work on
> SHA-1 deprecation, is that it is actually much harder to implement than was
> originally thought.

hard from policy, not from code.

> 2. The specification would be simpler without it. In particular, without
> the deprecated TLS stuff, it could be made much clearer that the blocking
> described in the document always happens before any data (HTTP request,
> Websocket handshake, etc.) is sent on the wire. (Note that I think that CSP
> should be defined to work like that too.)

Part of the reason it's important is I think to highlight the fact that
blocking *may* require first making the connection. That is, put
differently, it would be a somewhat limiting design choice to always assume
that blocking can be done before any data is sent on the wire.

Now, we can say to introduce it later, but to the extent it affects design,
it may help more to highlight up front.

> To be clear, I support the abstract idea of blocking deprecated
> TLS-protected subresources, and I do think that a specification for how
> that should work should appear in a future version of some specification,
> but not the current one.

When you say "not the current one" - do you mean not MIX at all? Or not
this version of MIX?
Received on Monday, 6 July 2015 17:18:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:49 UTC