1587494 - Investigate what CSP should be applied to userScripts

Status: NEW

(WebExtensions :: General, task, P3)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

As part of Bug 1581611 we are working on changes to the CSP applied to extension content scripts.

The extensions userScripts are a feature pretty similar to the extension content scripts and so we should also look into cover the extensions user scripts with the "extension content scripts" CSP.

Comment 1

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: WIP: Bug 1587494 - Exploratory patch to investigate userScript CSP changes for MV3

This patch is not meant to be reviewed and merged as is, it is meant to be used as an
exploratory patch to evaluate:

• which kind of changes we would need to be able to apply a CSP to the userScript sandbox
  (would the userScript's CSP have a goal different from the one we are going to apply
  to MV3 content scripts? e.g. meant to protect the userScript from the webpages)

• evaluate which goals a default CSP applied to userScript would have in practice
  (while considering that in MV3 this may be the only API still allowed to pass
  as strings some js code to run in the content process)

And, if we decide to proceed with experimenting which CSP on userScripts:

• evaluate what should be the selfURL for a userScript CSP, what would be the implications
  of those possible choices (e.g. should the selfURL be set to the website that the
  userScript is attached on? or some kind of unique url like a null principal spec?)

• what level of per-userScript CSP configurability we may still need to allow
  (e.g. we may apply a default CSP that we determined to be provide a reasonable
  balance between security and flexibility, but allow the extension to customize
  it, by adding restriction to a more relaxed base CSP)

Comment 2

[Shane Caraveo (:mixedpuppy)]

We have enough details for M1, moving this to M3 to sync it with work on the implementation.

Comment 3

[Luca Greco [:rpl] [:luca] [:lgreco]]

Given that we plan to get back to this as part of mv3-m3, P3 seems a more appropriate priority than P2.

Comment 4

[Luca Greco [:rpl] [:luca] [:lgreco]]

Given that we already did the initial analysis and agreed to defer to milestone 3 for planning more work related to this issue, I'm clearing the assignee to better reflect that.
(I may still be the one to pick this up during milestone 3, but we can decide that once we got to that milestone).

Comment 5

[Rob Wu [:robwu]]

The userScripts API is currently marked as MV2 only, because we're designing a cross-browser compatible API at https://github.com/w3c/webextensions/issues/279 . Once that has reached a resolution, we will resume work on the implementation.

The current direction of the API design is for the user script context's CSP to be independent of the page, and at least permit (inline) script injection in the page.

If we do end up needing to customize the CSP of the user script sandbox, then we should be aware that there is an effort to move CSP off ExpandedPrincipal - bug 1548468.

Comment 6

[Luca Greco [:rpl] [:luca] [:lgreco]]

Removed this task from the dependencies of Bug 1595853 (related to the Firefox-only userScripts API namespace that has been already deprecated for MV3 extensions) before closing it as wontfix, and instead adding it as see also on Bug 1875475 (tracking introducing a new MV3 API that is meant to cover the same kind of use cases) to be re-evaluated in the context of the new MV3 userScripts API.