Correction: nothing prevents the attacker from using the app's legit package ID other than requiring the uninstall of the existing app.

The spoofed app can't request passkeys for the legit app because the legit app's domain is associated with the legit app's signing key fingerprint via .well-known/assetlinks.json, and the CredentialManager service checks that association.

▲

mwwaters 2 hours ago | parent | next [-]

If the side loaded app does not have permission to use the passkeys and cannot somehow get the user to approve passkey access of the new app, that would be a good alternative to still allow custom apps.

	▲	tadfisher 2 hours ago \| parent [-]
		I don't think you understand. This exists _today_, regardless of how you install apps, because attackers can't spoof app signatures. If I don't have Bank of America's private signing key, I cannot make an app that requests passkeys for bankofamerica.com, because bankofamerica.com publishes a file [0] that says "only apps signed with this key fingerprint are allowed to request passkeys for bankofamerica.com" and Android's credential service checks that file. No need for locking down the app ecosystem, no need to verify developers. Just don't use phishable credentials and you are not vulnerable to malware trying to phish credentials. 0: https://www.bankofamerica.com/.well-known/assetlinks.json

▲

3 hours ago | parent | prev [-]

[deleted]