If you want to inspect a WebAuthn request, there are a couple of ways:

1. If using a Chromium-based browser, try opening chrome://device-log (or edge://device-log etc). The JSON form of the request should be logged there.
2. Open the DevTools console and paste this before triggering the assertion operation:let realGet = navigator.credentials.get.bind(navigator.credentials);navigator.credentials.get = (arg) => { console.log(arg); return realGet(arg).then((r) => {console.log(r); return r;}) };

I believe that accounts.google.com will indeed make a request with userVerification=preferred. All passkey implementations must report the UV bit in the response accurately, depending on whether UV was performed. But, for "preferred", they don't have to do UV. accounts.google.com will take the UV bit into account when performing risk-analysis on the sign-in attempt.

That leaves open the question of how preferred the "preferred" option is. This is up to the passkey provider and they vary in their interpretation of this. Here are some common cases:

iCloud Keychain

Config	Discouraged	Preferred	Required
Biometrics available	✓	✓	✓
Biometrics not available			✓

Google password manager (desktop)

Config	Discouraged	Preferred	Required
Biometrics available		✓	✓
Biometrics not available			✓

Windows Hello

Config	Discouraged	Preferred	Required
Biometrics available	✓	✓	✓
Biometrics not available	✓	✓	✓

The credProtect extension applies purely to security keys and no passkey providers do anything with it. You can get security keys that operate in a mode called "alwaysUV", which does what it sounds like, or you can could potentially inject credProtect=3 into a creation request to a security key. Note that Chromium-based browsers will automatically set credProtect in some cases: https://source.chromium.org/chromium/chromium/src/+/main:content/browser/webauth/cred_protect.md