Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate chrome extension to mv3 #2504

Open
3 of 4 tasks
imolorhe opened this issue Apr 21, 2024 · 3 comments · Fixed by #2536
Open
3 of 4 tasks

Migrate chrome extension to mv3 #2504

imolorhe opened this issue Apr 21, 2024 · 3 comments · Fixed by #2536

Comments

@imolorhe
Copy link
Collaborator

imolorhe commented Apr 21, 2024

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.

Screenshot 2024-04-21 at 10 11 40 PM

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 imolorhe changed the title Migrate to mv3 Migrate chrome extension to mv3 Apr 21, 2024
@imolorhe imolorhe pinned this issue Apr 21, 2024
@imolorhe
Copy link
Collaborator Author

imolorhe commented Jun 3, 2024

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 imolorhe linked a pull request Jun 4, 2024 that will close this issue
7 tasks
@imolorhe
Copy link
Collaborator Author

imolorhe commented Jul 1, 2024

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
Copy link
Collaborator Author

imolorhe commented Jul 5, 2024

iframe with srcdoc inherits current page's CSP

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant