The problem with Twitter (before the whole blue check system was gutted into meaninglessness) was that not enough verification badges were handed out. It's not exactly a dangerous situation.
Bluesky's idea of verified orgs granting verification badges to its own org members would be an example of a much more robust and hands off system than what Twitter had.
The dangerous scenario is what happened to Twitter after the Elon takeover: verification becomes meaningless overnight while users still give the same gravity to verification badges which causes a huge impersonation problem. But that possibility is not a reason to have zero verification.
The problem I had with twitter was the check was supposed to mean one thing and one thing only: that the person was who he or she claimed to be.
What twitter starting doing was removing blue checks from people who were causing problems for the platform (but not behaving bad enough to kick off). This made no sense because people still needed to know if a person was who he claimed to be (e.g., Milo Yiannopoulos) even if the person was controversial or problematic or just plain nasty.
Blue Checks weren't "gutted". Now they just mean something else -- you're a premium subscriber.
This is absolutely correct—I remember quite clearly how it all went down. When Twitter first rolled out verification, it was supposed to ensure that the person you were following or interacting with was the person they claimed to be.
This was also because there were so many people setting up fake accounts using real celebs. The most famous of which was probably the Dave Chapelle, Kat Williams story that Chapelle tells where a fake Chapelle account was feuding with a fake Kat Williams account.
I use the word "gutted" to refer to the level of trust in the old system that was abandoned in the identical-looking new system.
The correct way to have rolled that out would have been a brand new icon, but they wanted to cash in on the reputation of the old system. "Now you can pay for this once-coveted badge!"
The problem is that X (formerly Twitter) is still calling blue checks "verified". Even though nothing about the account is verified. It's deliberately misleading.
Nothing: anyone can hand out verifications to anyone they'd like.
Now, how those are displayed is up to the display software. BlueSky themselves get to decide who gets a blue check based on verification records, but if you wrote your own software, you could do whatever you'd like. There's a bsky fork that already has an account option to let you hide blue checks in your own view.
If anyone can hand out verifications to anyone they like then we’re back to square one. Why do we need these “Blue Checks”? It feels like BlueSky is trying to reclaim the lost clout for some of their influential users.
That’s a really weak argument because normie users want TikTokified social media with a clout based caste system. I thought BlueSky had a different goal in mind.
BlueSky wants to make a social media platform that normies want to use. The whole idea is to design a protocol that can achieve huge scale and behave a lot like existing social media apps (which people "like") while still being open and flexible.
I'm not sure about the details of the protocol (maybe someone can check?), but the client software can probably distrust certain trusted verifiers or even use a public list of such revocations. If this opportunity is exploited by malicious actors, there must be a simple and fast escalation path to revoke verification (you complain to verifier, then to maintainers of revocation list).
> Revocation is deletion, so it's hard to enumerate revocations.
In decentralized design it is not. A server can continue to list verified accounts, a 3rd party revocation list may mention some of them, a client will show only accounts not in the list as verified.
We need the blue checks to combat impersonation attacks. If a malicious actor pretends to represent a New York Times journalist, or your bank, or a government agency, you don't want users to be tricked into believing them.
Verification is a different thing than a "blue check". I might be against blue checks, but for sure I'm for anyone being able to hand out verifications. It creates a web of trust, and ideally one can choose who they trust and how many transitive levels.
Presumably a contractual agreement with BlueSky. Trust needs to stem from somewhere, so you’re either looking at a web-of-trust model where somebody (BlueSky or BlueSky clients) makes decisions on what sign-offs to trust, or you trust BlueSky to perform due diligence on partner orgs that provide this service and to hold them accountable when that trust is breached.
The WoT model works but as GPG has shown it requires your end users (people? BlueSky client developers?) to manage who they trust as an authority on anything.
Your profile says you're a security engineer, so I'm hoping you can help me understand.
What was the problem with the current DNS system? I definitely think there could be improvements like displaying domain instead of TLD but still.
And why not move into a system like multiparty keys? Keys assigned by domain holder, need to be signed, and verified accounts must login with a private key that validates. That way you don't just get that the account is validated but the post is too. Yeah, this would require more technical expertise to do but the organizations we're usually most concerned about would have no problem with that. Besides, tooling gets easier when there's meaningful pushes to make it available to general audiences
There was once Handshake, but they failed mainly because they didn't want to work along side the current system, they wanted to replace it completely with a blockchain. It's actually one of the good use case IMHO, but their leadership didn't want to play nice with what we already have so transition could happen smoothly
What is appropriate here really depends on what properties BlueSky wants to assert about it's ecosystem.
> What was the problem with the current DNS system? I definitely think there could be improvements like displaying domain instead of TLD but still.
As commenters earlier in this thread have noted, one property BlueSky claims it wants to develop/maintain is resistance against BlueSky itself becoming an adversarial party--say in the event it is bought out by an eccentric multi-billionaire who may take steps to discredit certain parties or reduce their reach or reputation.
I don't think the current DNS verification methodology helps or hurts in a BlueSky is hostile scenario. I think the only issues with the current DNS username verification system as I understand it are the same issues with any DNS based verification system in that vanilla DNS was not a protocol designed to be resistant to adversarial use and as a result there are many ways for people to tamper with DNS records, DNS queries, and confuse systems that incorrectly trust DNS records to be trustworthy or well-formed. DNS cache poisoning is a thing. Domain takeovers have and will continue to happen.
Now, if we're talking about what technologies are suitable for username verification in a word where BlueSky is adversarial, we have a very different conversation. I think the scope of such a scenario extends a lot further than usernames. If your primary interface into the AT Protocol feed is the BlueSky website or the official BlueSky application, you are trusting BlueSky to validate usernames. An adversarial BlueSky could easily decide if your interface marks someone as trusted or untrusted without your knowledge.
The only way I could think to avoid this would be to use a different interface to the global feed, but then you run into new problems that are more difficult to avoid: the fact that most BlueSky users don't host their own data (though this is doable with https://atproto.com/guides/self-hosting). BlueSky also manages the global feed, so barring a competitive global index, you'll still be consuming a feed curated by BlueSky's AT Protocol services and implementation.
I'd close this by saying I am _not_ an expert in the AT Protocol, BlueSky's systems, or this space in general. This is a very fast and loose risk assessment I made after reviewing the AT Protocol and a bit of research on how BlueSky says it provides it's services. My current assessment is that if the community wants to be robust against BlueSky becoming adversarial, there needs to be a lot more support for self-hosting of PSPs and similar data stores, alternative global indexes, and likely also independent governance of the AT Protocol itself.
Thanks for the insights and disclosure. While maybe not a expert in the AT Protocol, certainly you are closer to the issue than myself and presumably most users.
Were you given the ability to make a trustless or more decentralized system is there some route you would pursue? Maybe ignoring the AT protocol so I (and others?) can get a better sense of how such systems might be employed to ensure that an arbitrary organization can build defenses against themselves becoming adversaries (seems like a fairly useful mindset in general).
> Maybe ignoring the AT protocol so I (and others?) can get a better sense of how such systems might be employed to ensure that an arbitrary organization can build defenses against themselves becoming adversaries (seems like a fairly useful mindset in general).
There are ways to do this, but being trustless in the context of a social network is a thorny problem I'm not sure I can provide an answer to. The whole purpose of such networks is to enable communication with people you may not necessarily know (or trust). Furthermore, you implicitly trust the medium in which you use to communicate (BlueSky, Twitter, SMS, Zoom, etc.).
There are ways to make things difficult for a service provider; you see many of them in high security contexts. For example, when storing data on AWS GovCloud or similar, you have the option have AWS use user or company provided encryption that they do not have control over. Should AWS be compromised in some way, they would still need to have your cryptographic keys in order to access unencrypted data (https://docs.aws.amazon.com/AmazonS3/latest/userguide/Server...).
Another approach is message signing. An example of that is PGP signing of emails or files. You can use these cryptographic signatures to verify a message (email) or binary blob (file) has not been tampered with.
Another common approach, which you have alluded to, is some kind of multi-party scheme. Many cryptographic blockchains are good examples of this: You need a majority of parties in such schemes to agree on something for it to be considered valid or true.
A combination of these things can be used to make it more difficult for a service provider to be compromised or act against their user's interests. Sadly, this does not make it _impossible_ for them to do so. A user or customer who doesn't want to tolerate the worst case scenarios here still needs to make their own back ups, decide what entities to trust, and ensure they have robust procedures for doing things like trusting new entities or managing cryptographic material.
I'll also note that there are in fact live examples of such systems if you look for them. See IPFS for one such example: https://ipfs.tech/
> For example, the New York Times can now issue blue checks to its journalists directly in the app. Bluesky’s moderation team reviews each verification to ensure authenticity.
It's no more than any client only showing the information it wants to; anyone can verify anyone else, without permission from the company. Any client can surface this information in any way they'd like, without permission from the company.
Regardless of the intent or future this is an incredibly neat rhetorical trick that Bluesky's designers have pulled. Any semi-motivated contrarian can make the required arguments for either concern. It even happens to be true!
Meanwhile every mastodon discussion required (requires?) someone who deeply understands the system to spend "10 comments deep" energy just to arrive at a much less amenable position.
Nothing, however AppViews like Bluesky decide which verifiers they trust. An AppView could also allow for user choice, like how algos and moderation work.
The problem with Twitter (before the whole blue check system was gutted into meaninglessness) was that verification badges were merit and nepotism and not identity based
Here is probably the most well-known instance of Pre-Musk Twitter removing blue checks from the accounts of public figures for reasons other than the account not being who it claims to be:
Not pictured: innumerable other accounts which were never granted a blue check in the first place, despite being the easily verifiable real accounts of journalists and public figures.
It was de facto a caste system of political favor and connections.
Nearly everyone I interacted with on Twitter (pre-Musk) got their verification badge by essentially being in the San Francisco tech community.
No matter how prominent someone might be on this side of the Atlantic, it never mattered, meanwhile mid-managers and coders at no-name startups had blue checks because, I mean, they knew someone at Twitter- and who else is verifying people? I don’t really fault them for verifying people they personally knew.
But it meant that you had a situation where (and no offence meant to them) “nobodies” (as in, non-promenant figures) were “in the club” with heads of state, companies and heads of industry.
So there was a definite whiff of nepotism, because it was a de-facto status symbol.
Yep, same with "journalists". Publication companies were given a fast-track process that basically allowed them to hand out verifications to anyone who ever had a byline with them. The most reliable way to get verified was to sell some words to an online news website. It didn't matter how notable you or the publication were.
When GP says "that’s not true though" I can't even tell which part he is talking about. This is fairly recent and well-documented stuff.
Except journalism was happening on Twitter, so by restricting verification to more or less legacy media—-an elite circle of Columbia/NW/Ivy grads that is what, 5% merit-based—-it becomes somewhat of a caste system.
Because the original point of it was to distinguish journalists and public figures, so you could tell imposters apart from real people. Now its purpose is to show who has a premium subscription. Totally different feature using the same name.
But not all "journalists and public figures" received the checkmark. It was entirely up to the ultra-woke Twitter management who gets a checkmark and who doesn't. I frankly don't see why the current, deterministic setup is better than the former non-deterministic one.
Now it's ultra-racist ultra-fascist Twitter management. Do you actually think that's better? Why are you whining about "woke" people who have long since been fired, but embracing the racists and fascists who are now running and being platformed and amplified on Twitter?
Yes, "Twitter". If Elon Musk can publicly abuse, humiliate, lie about, deadname, and misgender his own daughter to his millions of followers, than I can deadname Twitter.
The problem with Twitter (before the whole blue check system was gutted into meaninglessness) was that not enough verification badges were handed out. It's not exactly a dangerous situation.
Bluesky's idea of verified orgs granting verification badges to its own org members would be an example of a much more robust and hands off system than what Twitter had.
The dangerous scenario is what happened to Twitter after the Elon takeover: verification becomes meaningless overnight while users still give the same gravity to verification badges which causes a huge impersonation problem. But that possibility is not a reason to have zero verification.