W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2014

Re: CfC: Mixed Content to Last Call?

From: Mike West <mkwst@google.com>
Date: Thu, 30 Oct 2014 09:35:44 +0100
Message-ID: <CAKXHy=f6Vc77EuVdzd2-KbT8aOUFWJ9LK4n-9NAnUimYMHpkgQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>, Chris Palmer <palmer@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Mark Nottingham <mnot@mnot.net>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>
On Wed, Oct 29, 2014 at 7:46 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Oct 29, 2014 at 4:06 PM, Mike West <mkwst@google.com> wrote:
> > 2. Moving the TLS checks to a new attribute on the Request's client, and
> on
> > the Response, which Anne was kind enough to add to Fetch for me. It's
> > currently named "authentication state", which probably needs some
> > bikeshedding, but the name shouldn't block progress on MIX.
> Authentication is confusing with HTTP authentication.
> Secure does not work because there is no such guarantee.
> Trusted does not work because trust is up to the end user.
> Validation might work, based on CAB's "Domain Validation".
> All these terms get irky when you apply them to resources created from
> blob or data URLs.

+Chris Palmer, who loves nothing more than naming things.

> > I don't believe there are any substantive controversies remaining, but if
> > I've missed anything, this CfC is a nice forcing function to get it out
> into
> > the open. :)
> I think it is still problematic that it tries to make claims based on
> origins. I thought the idea was to do away with that and instead base
> those checks on objects that can actually assertions about involvement
> of TLS or localhost, namely responses and environment settings
> objects.

Hrm. Yeah, I did want to do something with that. I'll poke at it today.

Received on Thursday, 30 October 2014 08:36:36 UTC

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