right, good point

WebAuthn is the mechanism that cares about DNS names. The Security Key - as a separate piece of hardware implementing CTAP2 (Client To Authenticator Protocol 2) - is not able to itself verify which web site you're visiting.

So, that verification step takes places inside your web browser. In this specific context this means a vulnerability is that your employees might install software which is also able to perform the same steps but unlike say, Chrome, does not do DNS name checks, perhaps it even intentionally always tries to generate authentications for google.com.

On a very locked down platform, such as an iPhone, or some employee laptops in corporations where employees aren't trusted to install software, there should be no way for that software to run. On Android, Google get to bless binaries with the privilege to do this, they bless the built-in Android browser, Chrome, production builds of Firefox, and I suppose it's likely there are similarly popular browsers I haven't heard of, but there is no way for a normal out-of-box Android device to just install some garbage adware that does WebAuthn even with a manual APK install. If you lack that privilege, when you ask Android to talk to a Security Key it fills out the parameter where a DNS name would go with a per-app ID. So you can use Security Keys to do cool stuff from an app, but you can't fake WebAuthn.

e.g. you can work out the ID assigned to your app, get the backend code your server people wrote for WebAuthn, and spin up another copy that checks that ID instead of your DNS name, now you've got a one touch in-app sign-in that works with fingerprint sensors on popular phones the same way WebAuthn does for your web site.

The user presence detection means that even if the DNS name matching mechanism is defeated (e.g. you have software install privileges because you work in the IT division, you install software from a phishing mail) the user needs to actually touch the sensor/ press the button/ whatever to signify presence, which requires further social engineering each time. In a spear phishing attack this is definitely conceivable but it's one last opportunity for your victim to say, hang on, what's going on here?

User Presence is a signed bitflag (it's also mandatory on most of the cheap devices anyway) which means it can't be faked even on the cheapest possible CTAP2 implementation, and a WebAuthn server implementation can have confidence in the value of that bitflag when received, the WebAuthn spec. says the implementations should reject authentications where that bitflag is not set.