Unfortunately, browsers don't invest into making a good UI for mTLS. If browsers simply put their foot down and said "we will not permit websites to ask for a certificate if the request does not contain the proper requirements" like they do in passkeys, mTLS would be just as easy to use (and even easier to manage and rotate!).
When I ran mTLS auth on my intranet, I discovered that a lot of sites will use mTLS support to do fingerprinting, which means a lot of pages will open a blocking popup (sometimes multiple times) when I just want to read an article.
It's not attempting to "read" anything, nor is it the least bit suspicious or malicious.
Your browser was asked if it would like to present a certificate to authenticate, and you were prompted to choose one if you please. You can also hit cancel as client auth can be optional and the server will either serve you the page or a 401/403.
It's like being asked to show ID to enter a pub, you can either show one or decline, and they may or may not let you enter based on that transaction.
> that no other website in the world does
That you know of. Anywhere with stringent security it's everywhere.
Clearly other sites do since the user who shared the anecdote has certificates already configured in their browser? It's uncommon but pretty easy to understand how this happened.
Bear in mind, this is public/private key crypto so it's not like the site is asking for your facebook password or something. The site owner has no way to reuse a certificate to imitate the user.
Not only is it difficult for an user to make a proper selection, it's also hard to fix a wrong one. The error pages are also terrible. There's no way for the site owner to request that when the navigation to the (auth) page fails, redirect back. Nope, no way to do error handling without some really clever iframe stuff and even then it's way too opaque.
God forbid you have to deal with CORS + mTLS.
As someone who is about to deal with exactly this, what kind of trouble am I in for?