Migrate chrome extension to mv3

[imolorhe]

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

[imolorhe]

Using iframes to isolate the plugin scripts might actually work. This requires an overhaul of the plugin system architecture though.

https://surma.dev/things/is-postmessage-slow/
https://adeesh.hashnode.dev/micro-fe-with-iframes-and-postmessages
https://www.basedash.com/blog/typescript-object-with-dynamic-keys

[imolorhe]

Using a local sandbox page with the allow-same-origin sandbox attribute not set for proper isolation forces the origin to be null which then requires other compromises like using * for the postMessage since we can't target a null origin and the inability to verify the origin of the message. Doing this requires additional validation to be put in place to be sure the data being sent, but even that doesn't have the strong guarantees that checking the origin provides. So scratching that option for now.

We'll fallback to using the special sandbox domain instead, which will require an internet connection to work. Later we can investigate using service workers on the sandbox domain to cache its content for offline usage.

[imolorhe]

iframe with srcdoc inherits current page's CSP