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

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

From: Mike West <mkwst@google.com>
Date: Mon, 6 Jul 2015 17:09:26 +0200
Message-ID: <CAKXHy=dbUrRy6SFJbEF6GUGDkGccw1EbM=pqRM935GVO9GRSmw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Brian Smith <brian@briansmith.org>, "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>, Ryan Sleevi <sleevi@google.com>
On Mon, Jul 6, 2015 at 5:00 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Mon, Jul 6, 2015 at 4:51 PM, Mike West <mkwst@google.com> wrote:
> > Another option that I could live with would be to drop the concept from
> the
> > spec explicitly, and to simply rely on Fetch's "HTTPS State" in
> >
> https://w3c.github.io/webappsec/specs/mixedcontent/#should-block-response.
> > This has the practical effect of making it possible for Chrome to
> continue
> > our SHA-1 deprecation plans, simply deferring the conversation around
> > "deprecation" from MIX to Fetch. I'm not sure that's an improvement.
> WDYT,
> > Brian and Anne?
>
> It seems like a net improvement to ground things in primitives.


That's a reasonable argument.


> whether that primitive should exist... I'm kind of okay keeping it.
> TLS stack transitions are never really clean so giving user agents
> some leeway there seems fine.
>

1. If we drop the concept from MIX, it might be reasonable for Fetch to
give examples of the cases in which a Response's HTTPS State might be
"deprecated authentication".

2. WebSockets doesn't have a similar concept, which makes rewriting
https://w3c.github.io/webappsec/specs/mixedcontent/#websockets-integration
in terms of something else difficult.

-mike
Received on Monday, 6 July 2015 15:10:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:13 UTC