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