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

Re: CSP and mixed content

From: Mike West <mkwst@google.com>
Date: Wed, 7 May 2014 15:21:25 +0200
Message-ID: <CAKXHy=fbQZKmfYHspgLJ0so5scieK3E1UrCJgH45tPUsSTS7gg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WebAppSec WG <public-webappsec@w3.org>
Do you think a 'secure-stuff' primitive would be useful, or would you like
Fetch to define what "secure" means?

-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, May 7, 2014 at 3:19 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, May 7, 2014 at 2:14 PM, Mike West <mkwst@google.com> wrote:
> > That makes sense to me. CSP could certainly be used to explain how mixed
> > content is blocked. If the resource is loaded over a secure channel, we
> > could apply a base policy of `script-src https:; style-src https:;
> > object-src https:; connect-src https: wss:` and allow the page to
> tighten it
> > from there. Is that what you had in mind?
>
> Yeah something like that. Basically when Fetch does its CSP check
> (however we decide to do that, separate thread), CSP ensures "mixed
> content" is disallowed. Making that a default policy could be a way of
> explaining it.
>
>
> > For this particular use case, it might make sense to define some sort of
> > keyword for "secure content", as 'https:' doesn't actually reflect the
> > extent of what user agents might consider securely transported.
>
>
> --
> http://annevankesteren.nl/
>
Received on Wednesday, 7 May 2014 13:22:17 UTC

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