If they "use (physical security keys) in place of (passwords and one-time codes)", that would no longer be MFA: they're authing strictly with "something they have".

A more in-depth quote is later in the article: "Once a device is enrolled for a specific Web site that supports Security Keys, the user no longer needs to enter their password at that site (unless they try to access the same account from a different device, in which case it will ask the user to insert their key)."

The parenthetical seems to imply that they're doing initial auth (and thus cookie generation) with password + U2F, and then re-validating U2F for specific actions / periodically without re-prompting for the password, similarly to how GitHub prompts for "sudo mode" when you do specific account actions.

Correct me if I am wrong, but I think the YubiKeys are PIN based. So in order to use it to authenticate you have to enter a PIN and three wrong attempts results in it locking. The PIN itself would be the, "something you know," and the YubiKey is the, "something you have."

Depends how you use the yubikeys.

They support x509 certs, which use PINs. Whether it needs the PIN once-per-session, once-per-15seconds, or once-per-use is configurable. The number of failures before it locks is also configurable. More details can be found here: https://developers.yubico.com/PIV/Introduction/

They also support TOTP/HOTP, where the computer asks the device for a code based on a secret key that the device knows. This can require a touch of the button.

EDIT: TOTP/HOTP modes do support a password, as cimnine pointed out. I'd forgotten about that setting.

Yubico OTP is similar to TOTP/HOTP, and is the mode where the yubikey emits a gibberish string when pressed. The string gets validated by the server against Yubico's servers. This does not require a PIN.

The U2F mode does challenge/response via integration with Chrome and other apps. The app provides info to the USB device about the site that's requesting auth, then you press the device and it sends a token back. This is critical to the phishing protection: barring any vulns in the local app (which have happened before), you can't create a phishing site that will ask my Yubikey for a challenge that you can then replay against the real site. This mode requires physical touch but no PIN.

YubiKeys support PINs for protecting TOTP/HOTP.

Right you are, my mistake. I've added an edit to my comment correcting that.

Thanks!

They do have a PIN but you don't enter it every time you authenticate.

The PIN is used to configure the YubiKey itself.

This isn't correct, they only have a single small button.

Poorly worded (or possibly misunderstood) — it was password + OTP → password + U2F. (In practice the OTP was also usually supplied by a dedicated USB stick, so the change was mostly transparent.)

Now the real question becomes: how often were they getting phished before the new policies? Knowing Google, there's no way they will answer THAT before another decade.

Why? What does it matter? Presumably it must have happened at least once for them to bring in this policy.

Well, for one, it would put the non negligible costs in perspective. Second, it would be an additional data point. More data is usually better than less of it. In this case, though, it's sensitive data, for a number of reasons, which is why I don't see it happening for years.