fix: Browser external application alert on trusted deeplink protocols

[jpcloureiro]

Development & PR Process

1. Follow MetaMask Mobile Coding Standards
2. Add release-xx label to identify the PR slated for a upcoming release (will be used in release discussion)
3. Add needs-dev-review label when work is completed
4. Add needs-qa label when dev review is completed
5. Add QA Passed label when QA has signed off

Description

With the introduction of Improve deeplinks experience feature, all URI are intercepted & matched with an allowlist.
URIs with protocols on this allowlist are opened by in-app browser with no restriction.

All protocols not present in this allowlist will trigger an alert box that prompts the user to allow or ignore the action.
When the user allows, this URI is forwarded to the OS deep-link handler.

We've seen this alert box might disrupt the user experience when specific deeplink protocols are used, such as wc://... or metamask://...

In order to improve such user experience, we have created a list of trusted deeplink protocols where these URI won't be opened by in-app browser but won't prompt the user to allow or reject, being automatically redirected to the OS deeplink handler.

This changes the old behavior described here

Issue

Progresses # https://github.com/MetaMask/mobile-planning/issues/779

Checklist

• There is a related GitHub issue
• Tests are included if applicable
• Any added code is fully documented

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[jpcloureiro]

Hey @sethkfman @NicholasEllul would love your thoughts on this approach

[NicholasEllul]

Overall no concerns with this. However, do we have documentation anywhere that highlights the use-cases for each deeplink protocol? Is there a reason these sites deeplink into MetaMask rather than interact with the in-page provider?

[sethkfman]

@jpcloureiro The purpose of the alert box is to make sure users are aware that the navigation is coming from an external source.

I think it make sense to add wc:// because the user is actively initiating that connection. The other protocols metamask:// & dapps:// can be triggered outside of a secure session and should be confirmed by the user.

WDYT?

[sethkfman]

LGTM

[jpcloureiro]

Overall no concerns with this. However, do we have documentation anywhere that highlights the use-cases for each deeplink protocol? Is there a reason these sites deeplink into MetaMask rather than interact with the in-page provider?

Aside from metamask: URI protocol, they are Ethereum Improvement Proposals

wc: eip-1328
ethereum: eip-831
dapp: ERC-1710

Dapps should always use the in-page provider when available. In the event of dapps not detecting / using the in-page provider, we want to support other forms of communication so we don't leave the dapp user in the dark. (for example, Uniswap does not detect in-page provider, using in-app browser on Android)

[cortisiko]

This is QA passed 👍

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

16.7% Coverage
0.0% Duplication