W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: [CSP3] Allow plugin-types "none"

From: Mike West <mkwst@google.com>
Date: Thu, 8 Jan 2015 17:13:04 +0100
Message-ID: <CAKXHy=c5o=7XEcEC0Uc1P6xByjtMDbZ+Ucdx40PKM2O9hXEzSA@mail.gmail.com>
To: Joel Weinberger <jww@chromium.org>
Cc: Craig Francis <craig@craigfrancis.co.uk>, Brad Hill <hillbrad@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
I would happily review such a patch to Chrome, but I don't think we'd need
to change the spec to allow it.

-mike

--
Mike West <mkwst@google.com>, @mikewest

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 Thu, Jan 8, 2015 at 4:57 PM, Joel Weinberger <jww@chromium.org> wrote:

> I can see how this is confusing, and we really shouldn't expect developers
> to know the syntactic differences between source-list and media-type-list,
> so maybe user agents could/should provide a more helpful error message?
> Something like, "you've set plugin-type to 'none', which is an unknown
> value. perhaps you meant to set object-src to 'none'?"
>
>
> On Thu Jan 08 2015 at 6:43:25 AM Craig Francis <craig@craigfrancis.co.uk>
> wrote:
>
>> On 8 Jan 2015, at 12:49, Mike West <mkwst@google.com> wrote:
>>
>>
>> Note that `plugin-types` isn't the same as directives like `default-src`.
>> The latter are "source list
>> <https://w3c.github.io/webappsec/specs/content-security-policy/#source-list>"
>> directives, and generally fall back to `default-src`. `plugin-types` is a "media
>> type list
>> <https://w3c.github.io/webappsec/specs/content-security-policy/#media-type-list>"
>> directive, and does not fall back to `default-src`. For that reason, I
>> think the consistency argument isn't particularly persuasive. The two
>> directives have different grammars, do different things, and I don't see a
>> real issue in making their behaviors distinct.
>>
>> If you don't want any restrictions on plugins based on their types, it
>> makes sense to me not to include the directive. If you want to ensure that
>> you don't have any plugins at all, it makes sense to me to use `object-src
>> 'none'`. Having two ways of saying that doesn't seem like a helpful
>> direction to go in.
>>
>>
>>
>>
>> Fair enough... and even if I did send 'none', all it would do is show a
>> warning in the console (and still do as I would expect).
>>
>> One other possible argument, 'none' does show the developer of a website
>> has considered this directive :-P
>>
>> Anyway (and just for my own reference), the list of directives that do
>> (or do not) currently support 'none' include...
>>
>> source-list (allows 'none')
>> base-uri
>> child-src
>> connect-src
>> default-src
>> font-src
>> form-action
>> frame-ancestors
>> frame-src
>> img-src
>> manifest-src
>> media-src
>> object-src
>> script-src
>> style-src
>>
>> other (allows 'none')
>> referrer
>>
>> other (not 'none')
>> reflected-xss
>> sandbox
>> report-uri
>> plugin-types
>>
>>
Received on Thursday, 8 January 2015 16:13:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:09 UTC