Ipfs cid v1 base32

[pldespaigne]

Fixes #5724

Recent IPFS update let user query gateways with the following url construction <ipfs-hash>.gateway.com. This url construct break same origin policy. Thus making ipfs resolved web site more secured as they will not share cookies & locaStorage anymore.

The problem is that usual ipfs hash are base58 encoded and contains capital letters, and so it cannot be used in the host part of urls. Before being resolved ipfs hash must be converted to a base32 encoding. To do that I have added a simple helper function to my content-hash library (already used to resolve ENS content).

This PR add the following features to MetaMask :

• use new content-hash helper function to convert base58 ipfs hash into base32 (url compatible)
• use new orgin secure ipfs gateway by default
• let the user choose the ipfs gateway in "settings > advanced" menu

To test it you can :

1. load this PR's MetaMask version in your browser
2. use the Goerli network
3. go to https://wikipedia.secure-origin.eth
4. open browser developer console and set a random value into the localStorage
5. go to https://other.secure-origin.eth
6. re open localStorage, you should not see the previous value
7. (optional) repeat without this PR updated code and you should be able to see the same localStorage on every .eth website

[pldespaigne]

@rekmarks 🙌

[rekmarks]

Awesome! Here's the unit test output from CircleCI:

1312 passing (10s)
  2 failing

  1) AdvancedTab Component
       should render correctly when threeBoxFeatureFlag:

      AssertionError [ERR_ASSERTION]: 10 == 9
      + expected - actual

      -10
      +9
      
      at Context.equal (ui/app/pages/settings/advanced-tab/tests/advanced-tab-component.test.js:19:12)

  2) AdvancedTab Container
       should map state to props correctly:

      AssertionError [ERR_ASSERTION]: { warning: null,
  sendHexData: false,
  advancedInlineGas: false,
  showFiatInTestnets: false,
  autoLogoutTimeLimit: 0,
  t... deepEqual { warning: null,
  sendHexData: false,
  advancedInlineGas: false,
  showFiatInTestnets: false,
  autoLogoutTimeLimit: 0,
  t...
      + expected - actual

       {
         "advancedInlineGas": false
         "autoLogoutTimeLimit": 0
      -  "ipfsGateway": [undefined]
         "sendHexData": false
         "showFiatInTestnets": false
         "threeBoxDisabled": false
         "threeBoxSyncingAllowed": false
      
      at Context.deepEqual (ui/app/pages/settings/advanced-tab/tests/advanced-tab-container.test.js:38:12)

[danfinlay]

I've tested this branch and verified its behavior. It redirects to subdomained gateway links, allowing different "decentralized" sites to not collide with cookie storage.

This is an immediate improvement in the security of our ens/IPFS loading, so thank you very much! It's great to see the feature so nicely integrated into our settings page and the rest of our files, this is a very clean contribution.

There are still some improvements we could make, but they can be in a future change:

I believe we may be able to incorporate redirecting so that we could preserve the URL context (either ens:// or ipfs:// etc). This would also allow decentrally-hosted sites to persist cookies even after the gateway is changed.

I think that API may be webRequest.onBeforeRequest().

Anyways, just noting that so we can investigate it next.

[danfinlay]

Oh sorry, before approving, I wanted to check if we'd been in contact with the ipfs gateway that's added here. Are they ready for our traffic?

[danfinlay]

It would also be nice if we could resolve ens:// not just https:// as I now notice this works with (I've been messing with it. It's fun!)

[rekmarks]

I think that API may be webRequest.onBeforeRequest().

Yeah, that API can definitely be used to accomplish what you're proposing. Just for context, after discussing this with @kumavis, I recommended that @pldespaigne pursue the CIDv1 gateway solution primarily.

[danfinlay]

Yeah, that API can definitely be used to accomplish what you're proposing. Just for context, after discussing this with @kumavis, I recommended that @pldespaigne pursue the CIDv1 gateway solution primarily.

Makes sense to me. Just noting that API to make sure we capture it. I've opened a new issue for that extension of this.

Only blocker left here to me is get the go-ahead from ipfs to use that gateway.

[rekmarks]

Only blocker left here to me is get the go-ahead from ipfs to use that gateway.

Awaiting answer from IPFS: ipfs/infra#493

[rekmarks]

@pldespaigne IPFS recommends that we switch to the dedicated ENS Gateway eth.link, see issue comment here: ipfs/infra#493 (comment)

Can you make that switch and add the IPFS gateway currently used as a fallback? The bounty deadline has been extended.

See docs here: https://eth.link/

Edit: @pldespaigne, just see about that PR against content-hash and make any updates here as necessary, and you're off the hook. Job well done.

[danfinlay]

Ehh, hold on to that thought an extra second. I don't think they were accounting for the fact that some of our users run full ethereum nodes, and would also configure IPFS nodes, so this eth-link solution is actually a hard turn for the unconfigurable, and a fair amount of work more.

Let's take a little more time, maybe work with infura, to get an ipfs gateway that we can use as default, and possibly continue using this approach for now.

[pldespaigne]

just updated content-hash with @lidel 's PR and published it as 2.5.2

[danfinlay]

A little update, we have not found anyone who wants to freely host IPFS content in this format yet. We may need to explore an option where we use js-ipfs by default, and allow users to configure their own ipfs node if they have access to one.

[whymarrh]

@rekmarks I've added one last comment, then this LGTM

[rekmarks]

Approving after review by @whymarrh and earlier review by @danfinlay

resolved out of band

[whymarrh]

LGTM