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

The other use case that folks often bring up related to plugin-types
is the ability to scope the types by origin.  For example, allowing
Flash from YouTube, but not from other sources.  One possible syntax
would be something like:

plugin-types http://youtube.com http://vimeo.com
application/shockwave-flash http://www.time.gov application/java

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.

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:32:48 UTC