You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Migrating the chrome extension to manifest version 3 since manifest version 2 will soon be deprecated.
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.
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
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
The text was updated successfully, but these errors were encountered:
imolorhe
changed the title
Migrate to mv3
Migrate chrome extension to mv3
Apr 21, 2024
Migrating the chrome extension to manifest version 3 since manifest version 2 will soon be deprecated.
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.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 witheval
. 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 extensionslocalhost
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 requiredSandbox 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
The text was updated successfully, but these errors were encountered: