Browser extension provider communication #348
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Alex Donesky <alex.donesky@consensys.net>
Co-authored-by: Alex Donesky <alex.donesky@consensys.net>
Co-authored-by: Alex Donesky <alex.donesky@consensys.net>
…nication' into browser-extension-provider-communication
Co-authored-by: Alex Donesky <alex.donesky@consensys.net>
Co-authored-by: Alex Donesky <alex.donesky@consensys.net>
Co-authored-by: Alex Donesky <alex.donesky@consensys.net>
…nication' into browser-extension-provider-communication
Contributor
Author
|
WIP. I still need to address comments in the old PR here. Opening this now to secure a caip number since we have need for this in our implementation we will soon be exposing publicly |
bumblefudge
reviewed
Apr 11, 2025
|
|
||
| ## Security Considerations | ||
| <!--Please add an explicit list of intra-actor assumptions and known risk factors if applicable. Any normative definition of an interface requires these to be implementable; assumptions and risks should be at both individual interaction/use-case scale and systemically, should the interface specified gain ecosystem-namespace adoption. --> | ||
| `externally_connectable` has seen a decade of usage via extensions on Chrome. It has a strictly better security when compared to postMessage over contentscript. |
Collaborator
There was a problem hiding this comment.
Suggested change
| `externally_connectable` has seen a decade of usage via extensions on Chrome. It has a strictly better security when compared to postMessage over contentscript. | |
| `externally_connectable` has seen a decade of usage via extensions on Chrome. It has strictly better security properties when compared to `postMessage` over content scripts. |
This was referenced Apr 15, 2025
jiexi
added a commit
to MetaMask/test-dapp-multichain
that referenced
this pull request
Apr 16, 2025
Replace `caip-x` with `caip-348` See: ChainAgnostic/CAIPs#348 See: MetaMask/metamask-extension#32070
Collaborator
bumblefudge
reviewed
Jun 9, 2025
| While web extensions could realize the benefits of `externally_connectable` without using it with a standardized interface, this would mean that every web extension would have to ship a provider library that worked specifically for their interface and that Dapps would need to import them. It wouldn't be feasible for Dapps to import every single web extension's specific provider implementation, making this approach less viable. | ||
|
|
||
| Web extension inter-operability is the key to enabling generalized provider implementations. Generalized provider implementations allows for convenient adoption by Dapps, leading to more wide spread adoption of the standard as a result. | ||
|
|
Collaborator
There was a problem hiding this comment.
reminder: maybe mention other uses of the transport being possible?
octavio12345300
approved these changes
Jul 24, 2025
bumblefudge
reviewed
Jul 30, 2025
Member
|
Shouldnt this be closed in favor of the recently merged #282 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This CAIP discusses the motivation, specification, and rationale for a proposal aimed at improving how web extension wallets interact with websites. It outlines the current method of injecting JavaScript provider APIs into websites, its advantages, and its numerous disadvantages, such as security concerns, performance issues, and the risk of breaking websites. An alternative strategy is proposed that specifies a standard communication specification over a new transport layer which enables websites to be able to embed their own provider as a library, addressing the disadvantages of injecting providers into websites and improving web extension interoperability as a whole.