Re: CSP 1.1: Behavior when presented with an invalid plugin-types directive?

> We might or might not want to support that sort of syntax today, but
> ignoring unrecognized tokens would let use support it in the future.

I had actually considered that. My thinking was it makes more sense to
make such changes via a new directive name, rather than extending
plugin-types. I don't think the word plugin-types conveys 'list of
origins and the plugins they are allowed to load'.

But, considering previous decisions (e.g., extended host syntax),
maybe the consensus is on extensibility of existing directives.


> Adam
> On Mon, Jul 23, 2012 at 4:09 PM, Devdatta Akhawe <> wrote:
>> I agree with Mike and like #2 more. If I am not wrong (please correct
>> me!), new mime types can be and are added all the time, but the
>> `grammar' for mime types (2 part identifier) is pretty constant.
>> Note that Mike's suggestion allows for application/foobar, where
>> application/foobar is not a mime type that the browser knows what to
>> do with (and the browser could say that in the console). But it will
>> fail loudly for just application (e.g., if developer mistakenly put a
>> space and typed out application / foobar )
>> On 23 July 2012 14:07, Adam Barth <> wrote:
>>> On Mon, Jul 23, 2012 at 7:32 AM, Odin HÝrthe Omdal <> wrote:
>>>> On Mon, 23 Jul 2012 07:28:46 +0200, Mike West <> wrote:
>>>>> I lean towards #2 as it seems less likely to leave a developer with the
>>>>> mistaken impression that her directive is working the way she expects (and
>>>>> tweaked the editor's draft to that effect over the weekend[2]).
>>>>> Still, the security risk of simply ignoring invalid items is probably
>>>>> quite low, so expansion of the syntax might be a good reason to opt for #1
>>>>> instead.
>>>> I always like having a road open for expansion. Especially on something as
>>>> expansible as mime types.
>>>> Ignoring invalid tokens wouldn't exclude printing out the error in the error
>>>> console. With all the useful stuff that is turning up in that console these
>>>> days, web developers gets more and more reasons to check it ;-)
>>> Yeah, that makes sense to me.  The situation is different with
>>> script-nonce, which we expect folks to generate programmatically.
>>> Adam

Received on Monday, 23 July 2012 23:55:42 UTC