EIP-5749: The 'window.evmproviders' object

EIPs
41

Now we have to add a whole another encryption layer to communication as well, at the same time this encryption public key needs to be random, otherwise anyone would know the decryption key. Also the dapps needs to generate an encryption key as well to receive the communication. Now we have to define what is the proper encryption type …etc. I strongly believe we shouldn’t decide how the communication should be handled from dapp to extension, specially we dont know which new more secure ways would be introduced in the future.

Like I mentioned before iframe wallets are not a priority at least for me based on the issues which I outlined earlier.
WebRTC solution is where the extension acts as a webrtc server and dapps can connect to it. This is just an example on different ways to communicate which are way more secure than window.postMessage

For me this itself a huge vulnerability with window.postMessage just imagine, you are on MEW and we decided to embed an iframe thinking it is safe however it turned out to be a bad actor, now the user will get a popup to sign a tx and since they are on MEW they thinks it is from MEW however, the tx is malicious

I think as an EIP our goal should be to standardize the methods which dapps needs to access to communicate rather than the actual communication protocol.

42

I’m strongly in agreement with not building ourselves into a corner which is why I advocate for a versioned protocol. That being said, we do need to standardize on something for the communication protocol as we want all dapps to be able to talk to all wallets. We could have multiple competing versions of this protocol and iterate on it over time but we need something for v1. My preference is to not include encryption in v1 and then work on a v2 that adds encryption. This is because I think the use case that would be protected here is fairly narrow (users with a malicious extension installed that is snooping on their wallet traffic) and the risks are somewhat low (snooping extension farms public user transaction that many wallets/pages/extensions are already farming anyway).

An iframe inside of MEW won’t have access to the window message bus of MEW. The iframe host has window message bus access for any iframes it hosts, and extensions have message bus access to all pages and iframes.

1 Like
43

I agree on the version, and I think something like encryption could be added later.

The good thing about my proposal is that you can do one initial call, receive a notification from each extension, And then the dapps extension lib (self loaded, it injected) could show a nice selection, modal, or simply connect to one if only one responded.
This gives a lot more flexibility on the dapp side, a lot more improvements overtime on the UI side, and the ability to access any extension directly without d the user having to click away every extensions modal. At the same time it prevents extensions from overriding each other (except they pretend being another one, which becomes very fast obvious, as to extensions, would respond with almost the same
Message. And the user wouldn’t notice it right away, when he clicks on an extension, I can, and another extension pops up. Like @MicahZoltu said malicious extensions are an edge case anyway)

The issue with not standardizing the way we communicate, is that you create a very difficult way for the apps to talk to extensions. Dapps should not be concerned to talk to a specific extension, they should ideally not care which extensions used as long as you user chose it.

The idea of the encryption key is great. And can be added a little later. Also new ways of communication can be added later including switching to webrtc, after the initial handshake notification.

In order to make a standard adopt, they cannot require too many massive changes. Otherwise no one will adopt it, except the change is specifically better.

the RPC might not be the best communication, but it’s good enough, and I don’t see any reason to change this now because there’s nothing significantly better right now.

So I would propose one step at a time, to switch to window post message. It’s already a huge one different changes can be discussed later in different discussions.

1 Like
44

@frozeman @kvhnuke I encourage you to join the Ethereum Wallets discord server as we have been having a lot of discussions on this topic over there. Ethereum Wallets I think it would really help to have you two join in those discussions. There is also a monthly AllWalletDevs voice call where we discuss this sort of thing regularly that would be great to get your input into!

45

I would, if my time allows that. But the link is expired.

46

Sorry, here is an update link that shouldn’t expire: Ethereum Wallets

47

Frame Wallet supports being connected to multiple chains now fwiw.

48

@frozeman @MicahZoltu did you guys make any progress in discord?
I am not a discord user so I wont be able to join, plus I believe discussions related to EIPs should happen at the discussion link. If you made any progress that could be converted to an EIP let me know if not I’d like to move forward with this EIP in the mean time. More complicated an EIP can get will only decrease the adoption process.

Also no matter which way we take, we still need same amount of permissions for chrome extensions

49

We have discussed all of this (plus other stuff) more, but I don’t think anyone in discord currently is strongly in favor of window.evmproviders so it is mostly just everyone discussing the viability of alternative options to that.

I do agree that any fruitful discussions that happen in Discord should eventually make their way into a broader and more publicly accessible discussion forum!

If you don’t want to join Discord but want to participate in the AllWalletDev community a bit more, you could perhaps attend the All Wallet Dev meetings. I think @SamWilsn is planning on moving them to Zoom (or similar) in the near future specifically so they are more accessible to people without Discord accounts.

I’m quite confident that this is not true. If no injection is happening (only winodw.postMessage), then the extension doesn’t need the ability to read/write to all pages (sudo).

50 
{
  "author": "https://www.enkrypt.com",
  "homepage_url": "https://www.enkrypt.com",
  "version": "1.11.1",
  "name": "Enkrypt: Ethereum, Polkadot & Canto Wallet",
  "short_name": "Enkrypt",
  "permissions": [
    "storage",
    "unlimitedStorage",
    "notifications",
    "tabs",
    "clipboardRead",
    "clipboardWrite"
  ],
  "commands": {
    "_execute_action": {
      "suggested_key": {
        "windows": "Alt+Shift+E",
        "mac": "Alt+Shift+E",
        "chromeos": "Alt+Shift+E",
        "linux": "Alt+Shift+E"
      }
    }
  },
  "content_scripts": [
    {
      "matches": [
        "file://*/*",
        "http://*/*",
        "https://*/*"
      ],
      "js": [
        "scripts/contentscript.js"
      ],
      "run_at": "document_start",
      "all_frames": false
    },
    {
      "matches": [
        "*://connect.trezor.io/*/popup.html"
      ],
      "js": [
        "vendor/trezor-content-script.js"
      ],
      "run_at": "document_start"
    }
  ],
  "description": "Everything in the blockchain made easy",
  "icons": {
    "16": "assets/img/icons/icon16.png",
    "32": "assets/img/icons/icon32.png",
    "64": "assets/img/icons/icon64.png",
    "192": "assets/img/icons/icon192.png"
  },
  "manifest_version": 3,
  "action": {
    "default_icon": {
      "16": "assets/img/icons/icon16.png",
      "32": "assets/img/icons/icon32.png",
      "64": "assets/img/icons/icon64.png",
      "192": "assets/img/icons/icon192.png"
    },
    "default_title": "Enkrypt",
    "default_popup": "action.html"
  },
  "background": {
    "service_worker": "scripts/background.js"
  },
  "web_accessible_resources": [
    {
      "resources": [
        "scripts/inject.js",
        "scripts/*.js.map"
      ],
      "use_dynamic_url": false,
      "matches": [
        "http://*/*",
        "https://*/*"
      ]
    }
  ],
  "minimum_chrome_version": "95",
  "content_security_policy": {
    "extension_pages": "script-src 'self'; object-src 'self'"
  }
}

this is the current manifest for Enkrypt (with injection) which permission do you think we can remove?

51

I’m able to receive a postMessage with just:

{
  "manifest_version": 3,
  "name": "WalletDemo",
  "version": "1.0",
  "description": "Is a fake wallet",
  "icons": {},

  "background": {
    "service_worker": "worker.js"
  },

  "web_accessible_resources": [
    {
      "resources": [ "wallet.html" ],
      "matches": [ "<all_urls>" ]
    }
  ]
}

source

52

it is because your wallet.html is hosted inside the extension

chrome.runtime.sendMessage({
        data: event.data,
        origin: event.origin,
    });

this call cannot be done if you are not in chrome-extension://

in order to listen to messages from other domains you need a contentscript, and contentscript requires

"content_scripts": [
    {
      "matches": [
        "file://*/*",
        "http://*/*",
        "https://*/*"
      ],
      "js": [
        "scripts/contentscript.js"
      ],
      "run_at": "document_start",
      "all_frames": false
    },
53

Or are you thinking of embedding this inside an iframe on dapps page?
so it is like dapp->iframe->extension->iframe->dapp?

54

Exactly this. The dapp inserts an <iframe src="web+evm://"> into its page, and the wallet’s wallet.html gets loaded with the help of navigator.registerProtocolHandler.

55

Im sure you are aware, chrome doesnt let you register multiple schema handlers under one namespace
assuming that issue is solved,

we can either use

or for two way communication

that way we dont have to do the dance around with iframes. If the goal is to prevent injection, I think we shouldnt inject iframes either.

At the same time, I dont know when schema handlers will be fixed, if they are not fixed we need a way to communicate the extension ids so the dapps can populate the iframes.
Even if they fix it and let a user have multiple extensions under on schema handler, itll prompt the user every time the user visit a dapp to select which extension they want to use, also if they want to use multiple extensions itll just keep prompting user multiple times, leading to bad UX

56

Yeah, that’s the main reason I haven’t been pushing hard for this approach. Telling people to navigate to chrome://settings/handlers whenever they want to switch wallets is rather impractical :rofl:

Do those work with non-extensions? Like can https://example.com communicate with an extension or a website under a different domain? If so, those sound perfect! I’m really not a web developer, so forgive my lack of knowledge here.

To be clear, the wallet doesn’t inject anything at all. The dapp would insert the iframe itself.

The iframe+scheme handler idea is basically dead if chrome doesn’t show a dialog to choose a handler. I 100% agree with you here.

Is asking the user once per session a huge issue? If it is, Firefox does have a “Use as Default” checkbox for scheme handlers.

If a user has multiple extensions, how would the dapp know which one to use? Wouldn’t it have to prompt the user too?

If, and this is a big if, we get better browser support for scheme handlers, I think they are one of the better options for the next gen wallet<->dapp communication protocol.

What we get with scheme handlers:

  • Security: Wallet dapps don’t need any permissions on arbitrary domains.
  • Privacy: Dapps can’t detect whether or not a wallet (or which wallet) is installed without alerting the user.
  • Flexibility: Wallets can be extensions, but also web page wallets (like Sequence and Portis) become first class citizens. Hardware and mobile wallets only need a tiny proxy web page to work too!

What we need before this is viable:

  • Multiple handlers in Chrome (and maybe Safari, I don’t know the story there.)
  • Better granularity for saving defaults in Firefox (per domain, global, etc.)
57

yea basically websites can directly talk to extensions, only thing the website needs is the extension id. If there is a way to communicate the available extension ids (such as using schema handlers) best way would be to use chrome.runtime

Yea but it can still get cumbersome, as the dapps needs to inject multiple iframes if they want to use multiple wallets at the same time.
This also doesn’t solve the privacy issue, if the extension wants to extract information from the dapp or change things in the dapp, it can just use window.parent.getElementById("#sensitivedata")
but then again there is only very little could be done about malicious extensions

Well dont forget the user already had to choose from a wallet select such as “web3modal” to get the browser wallet, then the user needs to select the popup from the browser, then if the user already didnt approve need to select approve on dapp connect window by the extension. Now imaging, a dapp wants to use multiple extensions at the same time. User needs to do this, all over again.

base on this EIP, all extensions will be simply part of evmproviders object, so the “wallet select modal” is already aware of approved extensions.

Privacy: Dapps can’t detect whether or not a wallet (or which wallet) is installed without alerting the user.

this can be done even with this EIP, user can decide which domains they want to inject to.

Honestly knowing how slow chromium team move, these two are kind big asks

Bottom line is, I love how you made it work. It is actually kinda cool! this can definitely be improved and lead to better communication model once we have all the right pieces.

58

I don’t think it’s really that cumbersome :stuck_out_tongue:

Oh really? That’s an issue. I assumed that if the iframe and page were on different domains, they wouldn’t be able to access each other’s DOM. Would the sandbox attribute help here?

Why would we need web3modal at all with this? Dapp injects iframe, browser prompts for wallet. Mobile/desktop/hardware/wallet connect wallets can all use Navigator.registerProtocolHandler as easily as an extension can.

Trust me, I know…

59

It appears my confidence was misplaced, sorry! I went and dug up my old extension project to see how I did it, and it appears I still inject a content script into the page. Unrelated to the discussion at hand, you can get rid of tabs and replace it with activeTab. This will require the user interact with the extension to inject it, but it makes it so the extension needs much lower permissions (no longer needs read/write all websites).

The thing I was thinking of that can be avoided with window.postMessage is that we don’t need to do the <script> injected into DOM hack that is necessary to write into the app’s sandbox.

Since I finally bothered to get my extension/iframe provider up and running, this is the prototype UI I had for a sample dapp. The iframe provider was available when the dapp first loaded, and the extension was injected later (because it uses activeTab permission). The dapp was able to detect both providers and can switch between them freely:
image

I’m pretty :-1: on scheme handlers at this point due to Chrome’s lack of support for a chooser interface. This is unfortunate because scheme handler choosers work great in Firefox and Android. :confounded:

My position still stands that I think if we are going to make a breaking change to the dapp API (window.ethereum → window.evmproviders) then I think we should fix as much as we can with a single breaking change rather than going through all of the headache of a breaking change to fix one thing (multiple wallet support).

The impression I get is that there many wallets are generally in favor of doing a big breaking change that fixes a bunch of stuff, but we currently don’t have a champion who is really pushing this forward strongly (e.g., writing specs, building prototypes, etc.) I was interested in doing so several years ago, but my energy is focused elsewhere now.

60

In my experience working in W3C, many of the browser vendors are skeptical of what web3 brings to the web platform and are unlikely to support any feature requests that are driven by web3 use cases. I’d be a -1 to holding a change like this up until we get support for specific features in the browser.

I also think it’s important that we look beyond the scope of EOA support (how’s account abstraction designs going to impact this) and EVM specific API support. Many wallets are considering going multichain (or already have like Enkrypt which prompted this discussion) so I’d be a +1 to setting the requirement that this solution MUST support non-evm based chains. That probably also means we’ll need to consider a venue other than EIPs to standardize this so that we can bring other large wallets to the table.

1 Like