Migrating the chrome extension to manifest version 3 since manifest version 2 will soon be deprecated.

https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline

Extension pages

Attempted a naive migration of the extension but got hit with the "invalid CSP source" error right off the bat. The extension pages aren't allowed to execute any untrusted or remote scripts, so the existing script-src CSP was violating this on multiple grounds.

script-src 'self' 'sha256-765ndVO8s0mJNdlCDVQJVuWyBpugFWusu1COU8BNbI8=' 'sha256-kFTKSG2YSVB69S6DWzferO6LmwbqfHmYBTqvVbPEp4I=' 'unsafe-eval' https://cdn.jsdelivr.net https://apis.google.com https://www.gstatic.com/ https://*.firebaseio.com https://www.googleapis.com localhost:* http://localhost:8002 http://localhost:8080

Why do we have all these script-src non-self values

• unsafe-eval is required for the pre- and post-request scripts to work which use a web worker to execute the untrusted user code with eval. A workaround would be to use the iframe implementation. Currently this manages isolation by using a special sandbox domain, but this can potentially still be achieved by omitting the allow-same-origin value in the iframe sandbox even if hosted from the same origin (additional reading)
• cdn.jsdelivr.net is used for loading altair plugins dynamically. There is no real workaround for this. If we choose to use extension pages, we can no longer support plugins in the chrome extensions, other than overhauling the plugin architecture
• localhost et al are for loading altair plugins during development. Same as above, no real workaround for this.
• apis.google.com, www.gstatic.com, *.firebaseio.com, www.googleapis.com were used for the firebase setup, but should no longer be required

Sandbox pages

Chrome extension also allows hosting sandbox pages which allows more flexibility with its CSP but other constraints apply to it. The most problematic constraint is the blocked access to localStorage (we are not allowed to set the allow-same-origin flag which also means we can't access localStorage on the page). localStorage is used in a number of places per this spec.

The only workaround I can think of is to monkeypatch the localStorage with a fake object that proxies to something else .e.g. sessionStorage or indexedDb. i haven't yet tested if it's possible to monkeypatch it, or if the other storage APIs even exist in the sandbox pages though.

Another issue with the sandbox pages is that they have no access to the chrome APIs. This means losing the ability to display chrome notifications. One workaround would be communicating with the extension background worker via post messaging