techBluesky has very quickly become a serious social media platform. This means it’s having to deal with all the problems social media platforms have to deal with, including impersonation. A lot of people flocked to Bluesky from Twitter, and so recreating something like Twitter’s verification system seems like a natural step.
2024-11-29T20:46:33.430Z6/ We also hear your feedback: users want more ways to verify their identity beyond domain verification. We’re exploring additional options to enhance account verification, and we hope to share more shortly.
But you don’t need to do that! Bluesky’s current verification system is actually very good and does what verification is supposed to do.
In 2022 I wrote a retrospective essay about the “verified account” design pattern on Twitter, which tried to preempt this conversation a little bit, but unfortunately got bogged down a little with Elon breaking Twitter verification. This piece will talk about a lot of the same ideas, but applied more specifically to Bluesky’s ecosystem.
Bluesky handle verification§
Bluesky already has a very good self-verification system called domain handles. The idea is simple: if you have a website, your bluesky handle can be that website, and that verifies that the bluesky account is also the person who manages the site.
There are a number of ways to confirm your identity for this; if you own the DNS record you can verify yourself through DNS, but you can also verify yourself by putting code in the body of a page. This means any “real” website you administer, including things like neocities, can be used as verification.
These domains can also be provided by an employer, like <name>.nytimes.com
Other services, including mastodon, have a similar system for self-verifying based on web domains. Bluesky’s verification stands out better though, since it uses your website for your handle. Any verification on the account will show up in every post, at the very top. You don’t need to dig through someone’s profile to confirm their identity, everyone wears it on their sleeve.
Don’t overload verification§
One of my main points from The Failure of Account Verification was that the reason the blue check was ineffective was that it was semantically overloaded. It wasn’t clear what it was supposed to mean, because it could mean so many things. Does it confirm you’re who you claim to be? Or does it confirm that you’re a celebrity? Or does it constitute endorsement by the platform? Or does it mean you’re a first-class citizen of Elon Musk’s X The Everything App?
Bluesky has the perfect opportunity to short-circuit this problem, because verification is already explicitly defined. It means you control a specific web domain.
Web domains§
Web domains are a heirarchial system. The components of the domain name are separated by .s, and each component is a subdomain of the domain to its right. So mail.google.com means com has the subdomain google, which has the subdomain mail. google controls mail.google.com, and com (an ICANN top-level domain) controls google.com.
A really useful feature of this system is that the trust chain is visible in the domain name, and you can understand the hierarchical relationship a domain represents at a glance. This means you don’t have to memorize every domain that exists, as some people have ludicrously argued. You just have to be able to read a domain name, which is not much to ask. It’s not an esoteric skill, it’s basic literacy.
This trust-chain-in-the-name feature is what lets verification work for domains like neocities or senate.gov: If you have a neocities account, you control <site>.neocities.com. You can’t pose as neocities itself, or a different neocities user, because you only have access to that one subdomain.
2024-12-02T20:09:36.196ZUpdate: I'm now @dylanfreedman.nytimes.com!
Non-verified Bluesky handles conform to this system too. If you have a <user>.bsky.social handle, that just means bsky.social has you as a user. The hierarchy is still there and it’s still correct.
What do you want verification to do?§
If you want a “pure” system of verification that verifies the authenticity — and only the authenticity — of accounts, Bluesky already has exactly what you want: an unambiguous, purely technical verification system that isn’t dependent on value judgements from human moderators. It doesn’t mean someone is “trustworthy”, it just means they are who they say they are. “Legit” is not an intrinsic property a person can have. Domain verification communicates one thing, and does it well: this person is the same person from this website.
Trying to add an additional verification system (like a badge) that adds other connotations (like prestige) can only add confusion to this signal.
I’ve seen lots of people on Bluesky complaining that domain verification is “insufficient” because people can make generic impersonation accounts under bsky.social, or that there’s some need for a “real” verification system. But this logic doesn’t hold up.
Having a blue checkmark in your name won’t stop people from making unverified accounts impersonating you on the generic bsky.social domain, obviously. The blue check only helps in comparing a fake account to the real one, because the real one will have authenticating information in the handle. This is, of course, exactly the same thing domain verification does.
Problems with Bluesky verification§
Just because the current system is “pure” and “unambiguous” doesn’t mean there aren’t issues. I don’t think any of these are helped by a badge system, but I do think they’re weaknesses it’s good to be aware of.
Revocation§
If your verified Bluesky handle is <name>.<newsroom>.com, to verify that you’re currently employed by newsroom, what happens when you quit?
Assuming newsroom correctly deactivates your page (hopefully leaving it up for historical purposes, but removing the verification code), what happens on Bluesky?
There has to be a system to periodically re-check these verified handles to see if something has changed in the domain verification chain, like your company no longer authenticating you as an active member. If that happens, what happens to your Bluesky handle? Is there action required to fix it (i.e. the “invalid handle” state), or are you reassigned a generic name again? What happens to links to your old name; can you leave a redirection notice?
Currently, in this case, Bluesky will revert the account to a .bsky.social handle, but accounts will keep their history and followers.
Bad actor domains§
Domains themselves can be fake. We already see this as part of phishing attack chains: you get an email from your bank with a link to <bankname>.net, but you don’t realize bankname’s real domain is <bankname>.com!
Now, imagine the same attack but with Bluesky handles. You’re contacted by service.<bankname>.net, and it seems like they’ve verified themselves as authorized representatives of bankname. But they’re not!
2024-12-04T01:38:30.821ZSpeaking of verification via domain name handle. This is fake.
There are a few ways to handle this. Accounts that are engaged in malicious impersonation can still be banned by Bluesky moderation, regardless of their handle.
But in this case, the top-level domain and ICANN can also exert pressure from the domain side.
Web hosts do not want to be responsible for phishing campaigns, and reputable top-level domains don’t want to implicitly approve fake subdomains. In the above example, .net itself can moderate the fake site, and even remove it from the .net domain.
It doesn’t mark who the angels are§
This is what everybody wants, right? I think a lot boils down to this.
People want a filter they can put over the world that tells them who they can trust and who they can’t, ingroup-outgroup membership signifies, friend-or-foe colors. People want shinigami eyes. But that’s just not how society works! It’s not how trust works, it’s not how people work. And if you take this vague, impossible wish, and try to build a technical system to accomplish it, you end up making a confused, overloaded system that just injects more bad information.
Domain verification is good§
It’s a good system! It does exactly what it says it does. Compared to domain handles, a human-approved badge system would add more room for errors in judgement, not less.