Migrate to Chrome Manifest v3

[tiero]

https://developer.chrome.com/blog/mv2-transition/

[bordalix]

We have a kind of a pickle with manifest v3.

MV3 disallows certain CSP modifications for extension_pages that were permitted in MV2.
The script-src, object-src, and worker-src directives may only have the following values:

- self
- none

So, this needed to be changed:

   "content_security_policy": {
-    "extension_pages": "script-src 'self' 'unsafe-eval'; object-src 'self'"
+    "extension_pages": "script-src 'self'; object-src 'self'"
   },

But, by removing 'unsafe-eval' from CSP, this means our code can't have any of this:

eval()
Function()     // typically new Function()
setTimeout()   // with non-callable argument
setInterval()  // with non-callable argument
setImmediate()
execScript()

While our code seems ok, some of the node modules we use do have this.
For example, https://github.com/facebook/regenerator has this:

Function(...)

This means Chrome refuses to registrate the service worker (the new background script).

facebook/regenerator#450

During our investigation, we also found that Taxi has the same problem, and that's to the fact it uses grpc-web which in turn uses protcolbuffers JS code generation:

shumbo/grpc-web-error-details#3
protocolbuffers/protobuf-javascript#25

So, at the time, we are stucked.

[tiero]

Ideally we can migrate grpc-web to plain JSON over HTTP endpoint for Taxi API. Working on this server side as we speak cc/ @altafan

[bordalix]

Great.

I was worried on loosing the information we already gathered so I write it down here.
It's essentially a copy & paste with some editions from our Slack conversation.

[tiero]

grpc.liquid.taxi exposes now a HTTP JSON interface

The proto defintion is here https://github.com/vulpemventures/taxi-protobuf/blob/master/taxi.proto#L8-L24

the two RPCs becomes

• get: "/v1/assets
• post: "/v1/asset/topup

The Swagger JSON as well

[tiero]

We can now implement the REST interface and drop protobuf dependency.

We are going to deploy a testnet instance later today @altafan

[altafan]

The Taxi daemon on testnet is up&running. It's ready to serve topups paid with tUSDT and can be reached at https://grpc.liquid.taxi:18000

[bordalix]

This Issue will be on hold, until we figure out a way to fix the following problems:

XMLHttpRequest

With Manifest v3 it is mandatory to use service workers instead of the background script. Workers no longer provide XMLHttpRequest, but instead support the more modern fetch(). Since axios uses XMLHttpRequest, it no longer works.

So, all axios calls must be changed to fetch, including all dependencies, and at least ldk is using axios.

Further investigation is needed to find out if any other dependencies are using axios.

in https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/

WebAssembly

It seems that Chrome requires script-src: 'unsafe-eval' CSP directive to be active for WebAssembly compilation. But one of the conditions of Manifest v3 is the absence of this directive. So, we cannot have any modules on our dependencies using WebAssembly, but it seems liquid uses it.

Conclusion

Since we still have a full year where we can still use Manifest v2 (and make upgrades) we’re leaving this Issue on hold.

Links

Manifest v3 timeline:
https://adguard.com/en/blog/manifestv3-timeline.html

Discussion about wasm not working in extensions Manifest v3:
https://bugs.chromium.org/p/chromium/issues/detail?id=1173354#c33

Lack of XMLHttpRequest
https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/