Does anyone have opinions on what the format for the manifest key should be? We already allow extensions to specify "content_security_policy" for extension pages and also for sandboxed pages. Some options we were thinking about:
1. Have "content_security_policy" manifest key be a dictionary (it's a string today). E.g.
"content_security_policy" : {
"extension_pages" : "",
"content_scripts": "",
"sandbox" : "",
..
}
2. Alternatively, things can remain as they are today and we can add another manifest key, something like "content_scripts_csp".
Some other ideas:
1. We can potentially have a separate CSP for extension service workers. Should we?
2. Going another step further, we can potentially allow extensions to specify a separate CSP for each extension page. Should we?
Having a dictionary SGTM. I would recommend the addition of a "default" entry, which could be used for any situations we don't have a separate key. I'd also perhaps avoid introducing an "extension_pages" entry (instead using "default") for the time being, since we may or may not want finer granularity or different phrasing.
> We can potentially have a separate CSP for extension service workers. Should we?
As above, I'd recommend we hold off on this. I can see the potential utility, but it's not clear to me that many developers would want this level of granularity (over just "default"). Or, it could be that developers want *more* granularity (and I could potentially see introducing match patterns or URLs as keys to the CSP dictionary, as you mention in 2.). I think, until we know there's real demand, just having a default CSP to use for everything that isn't a script or a sandbox is probably okay.
> 2. Going another step further, we can potentially allow extensions to specify a separate CSP for each extension page. Should we?
(Same as above)
>> Having a dictionary SGTM. I would recommend the addition of a "default" entry, which could be used for any situations we don't have a separate key. I'd also perhaps avoid introducing an "extension_pages" entry (instead using "default") for the time being, since we may or may not want finer granularity or different phrasing.
Ack
As discussed offline, allowing extensions to specify a custom CSP is also useful for manifest v2. Does using "content_scripts_csp" for manifest v2 work?
I'd prefer avoiding introducing a separate key just for mv2 extensions. Could we look for either a dictionary or a string for the content_security_policy value, and assume that if there's just a string, it's to be used as the default? (This could work for mv3, as well, so that extensions can choose to just specify a single CSP, and we only use separate ones if the entry is a dictionary)
A manifest key having a different "schema" for the same manifest version doesn't seem ok to me (Confusing to explain, document).
I don't see much harm in introducing a new manifest key.
I get that the transition to manifest v3 for developers would then be more involved, but I guess that's ok.
> A manifest key having a different "schema" for the same manifest version doesn't seem ok to me (Confusing to explain, document).
I think it'd be more confusing to document two different schemas as well as two different keys. This would mean one key (content_security_policy) would be allowed in two different manifest versions, but only with a single schema in each, and the second key (content_script_csp) would only be allowed in the old manifest version.
If we keep the same content_security_policy key, we're going to have to document that it can be either a string (for mv2) or a dictionary (for mv3). I don't think it's too much more confusing to say it can be either a string (for mv2) or a dictionary (for mv2 or mv3). WDYT?
Comment 1 by karandeepb@chromium.org
, Oct 18