- From: Mike West <mkwst@google.com>
- Date: Wed, 7 May 2014 15:21:25 +0200
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WebAppSec WG <public-webappsec@w3.org>
- Message-ID: <CAKXHy=fbQZKmfYHspgLJ0so5scieK3E1UrCJgH45tPUsSTS7gg@mail.gmail.com>
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