I don't think we have such metrics today. I would be good to have some. A couple of things to keep in mind when gathering and interpreting metrics though:

1. Client certificates are primarily an enterprise feature, and enterprise is often underrepresented in UMA.

2. The user's client certificate selection is cached until browser restart, both implicitly via the TLS session cache and explicitly via SSLClientAuthCache. So a deployment may depend on it yet report very few prompts.

A few notes:
1) It's unclear if we want to keep the Android tag. The Android OS fully controls the prompting and display here, and by-design does not provide apps, including Chrome, any details that would allow them to do their own prompts, on privacy and security grounds. So, at best, this would require a major Android OS update to change.

2) We don't display prompts at all if a user has zero certificates present (or zero that match the server's selected parameters, if it supplied them). So I suspect there is a metric which is "Would have shown, if the user had client certs", as this would identify if external factors cause an increase in that first metric (for example, users w/ and w/o client certs being asked by servers for them, as the prompt only triggers for the former; a rise in the # of the former could be explained by external factors such as this)

3) Whether or not it is an Enterprise with an AutoSelectCertificateForUrls policy configured. For example, the existence of an ASCFU suggests an intent to suppress prompts, and thus an increase may be explained by a misconfiguration of ASCFU, rather than any Chrome issue or external factor.


The place to touch is //chrome/browser/chrome_content_browser_client.cc ChromeContentBrowserClient::SelectClientCertificates , although for #2, that's short-circuited early in //content/browser/ssl/ssl_client_auth_handler.cc.

This will not measure Android, but I would suggest ignoring Android entirely for the time being; it has a separate code-path and its own set of limitations that make achieving the stated goal ("improving the dialog") a separate root cause/fix for Android.

Thanks folks.

I have an early version of this that carlosil@ may have feedback on once he's back. I'm OOO next week, so I expect further progress to happen the week after.