- From: Mike West <mkwst@google.com>
- Date: Wed, 23 Apr 2014 14:26:09 +0200
- To: Tanvi Vyas <tanvi@mozilla.com>
- Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=cG5mm4-wQKPWq4W9U2FMs=9yK2U3YU8qwdbA3FAj2-4w@mail.gmail.com>
On Wed, Apr 23, 2014 at 7:21 AM, Tanvi Vyas <tanvi@mozilla.com> wrote: > Thanks Dev and Brad for your responses! Two things I'd still like to > discuss (perhaps during tomorrow's call) - > * why do we need separate fallback mode and a block modes? If the website > wanted to fallback, they would include a src and a noncanonical source, > along with an integrity attribute. If they did not want to fallback, they > would just provide the src and the integrity attribute. > The CSP bits of the spec are certainly half-baked. I can see value in dropping the fallback policy type in favor of an explicit fallback possibility for individual resources. It might be worthwhile, however, to offer authors the ability to turn off the fallback ability entirely. That is, perhaps we should replace the default policy with 'fallback', while allowing authors to choose the more restrictive 'block', which would disable the noncanonical bits. > * if the non canonical source fails the integrity check, should we require > that the actual source be retrieved over https? > That sounds reasonable to me, but Brad and others might have opinions about the use-cases here that would be relevant... -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.)
Received on Wednesday, 23 April 2014 12:26:59 UTC