[Bug]: Site URL value is undefined for any Approve Transaction triggered by a Deeplink

[seaona]

Describe the bug
Site URL value is undefined for any Approve Transaction triggered by a Deeplink

Screenshots
If applicable, add screenshots or links to help explain your problem

undefined-site-url-deeplink.mp4

To Reproduce
Steps to reproduce the behavior

1. Select Mainnet network
2. Click on MM Scanner (top right button)
3. Scan the following QR code

4. Accept prompt
5. Wait until MM opens the Approve Confirmation screen
6. Click View details
7. See how Site URL is undefined

Expected behavior

Not sure what should be the appropiate value though. Should we display something like Depplink or similar?

Smartphone (please complete the following information):

• Device: Samsung SM-A217F
• OS: Android 11.0
• App Version: v5.12.3 (1033)

---

to be added after bug submission by internal support / PM
Severity

• How critical is the impact of this bug on a user?
• Add stats if available on % of customers impacted
• Is this visible to all users?
• Is this tech debt?

[bschorchit]

On the confirmation itself, it's showing as metamask.github.io which is also misleading, right? For me it showed up as etherscan so it might be using the last url you loaded a confirmation screen for.

[bschorchit]

Wondering what the fix might be - cc: @holantonela this will need design for the domain pill (should we just hide it in this case?) and is also security related.

Do we have docs on the deeplink and what parameters are passed on it?

[seaona]

@bschorchit from what I've seen, there are 3 different type of deeplinks:

1. Open a Dapp: we pass the dapp URL

• Example: https://metamask.app.link/dapp/uniswap.exchange

2. Payment request:

• ETH Payment: we pass the recipient address, amount (i.e. 1.5) and network (i.e. 5)
  https://metamask.app.link/send/0x07Be9763a718C0539017E2Ab6fC42853b4aEeb6B@5?value=1.5e18
• Token Transfer: we pass token contract, token decimals, recipient, amount (i.e. 1) and chainId (i.e. 1)
  https://metamask.app.link/send/0x6B175474E89094C44Da98b954EedeAC495271d0F@1/transfer?address=0x1C53dc20D1E36ed8359250dE626ACAe36BD28a29&uint256=1e18

3. Payment channel: we pass address, amount and and optional text field (not 100% how this one works though)

You can generate deeplinks here.

[holantonela]

Thanks for reporting this @seaona! Since we don't have origin the origin url does not reflect a Dapp or a website, we can hide/remove the entire Site URL line in this kind of request. We also may want to be consistent in the confirmation screen (at 0:12). Could that be possible?

Another option is allowing deeplink generators to use a specific label to expose as an "Requester/Origin name". It may be maliciously used by impersonators, opening another hell thread.

Orthogonal: Are we passing all the transaction parameters clean in that deeplink? Could be obfuscate that data? https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url

@andrepimenta @ezgi-cengiz

[bschorchit]

Ok, so based on Antonela's comment above (thank you!!), here's the scope for the fix:
For confirmations screens created from deeplink requests,

1. the origin pill (1st screenshot) should be hidden;
2. the site url in transaction details (2nd screenshot) should be hidden.

1st screenshot (origin pill):

2nd screenshot (site url):

I'm leaving the obfuscating part out of scope as there might be needed some discussion and input from Andre and Ezgi that doesn't block the above fix.

[andreahaku]

@bschorchit @seaona A simple metamask.app.link universal link does not carry the information about the dapp that triggered it. it just carries the information about the transaction itself. So metamask.app.link is not the URL generating the transaction