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.


--dev


> Adam
>
>
> On Mon, Jul 23, 2012 at 4:09 PM, Devdatta Akhawe <dev.akhawe@gmail.com> 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 <w3c@adambarth.com> wrote:
>>> On Mon, Jul 23, 2012 at 7:32 AM, Odin Hørthe Omdal <odinho@opera.com> wrote:
>>>> On Mon, 23 Jul 2012 07:28:46 +0200, Mike West <mkwst@google.com> 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