The fedi discourse on Bluesky's verification is very frustrating Don't et me wrong, there's a lot to critique with Bluesky's approach of combining their own platform-level verification with initially annointing a handful of third-party verifiers:

• community-oriented verification, along the lines that @rudyfraser.com suggests, would be much more power-distributive and equitable

• as @ngerakines.me notes, Bluesky's approach is missing something critical: consent

• as @DataDrivenMD points out, the current framework functionally disenfranchises community organizers who lack social networks with access to mainstream media and other institutions that are designed to exclude marginalized people

• just like on Twitter, he people initially verified are overwhelmingly cis, white, and male;

• the three initial external verifiers include the anti-trans NYTimes and one of their subsidiaries

• Bluesky hasn't said anything about their process for making decisions about who's "notable" enough for them to verify and how they decide somebody's "authentic".

To be fair, I am seeing a bit of discussion of some of these issues here. But I'm not seeing anything about consent, or community moderation, or equity. Instead, the vast majority of what I'm seeing is people saying hat the approach of external verifiers (run by entities other than Bluesky) and the Bluesky app attaching privileged semantics to the annointed ones isn't "decentraized."

Is that really the important thing here?

#bluesky #verification #fediverse

The fedi discourse on Bluesky's verification is very frustrating Don't et me wrong, there's a lot to critique with Bluesky's approach of combining their own platform-level verification with initially annointing a handful of third-party verifiers:

• community-oriented verification, along the lines that @rudyfraser.com suggests, would be much more power-distributive and equitable

• as @ngerakines.me notes, Bluesky's approach is missing something critical: consent

• as @DataDrivenMD points out, the current framework functionally disenfranchises community organizers who lack social networks with access to mainstream media and other institutions that are designed to exclude marginalized people

• just like on Twitter, he people initially verified are overwhelmingly cis, white, and male;

• the three initial external verifiers include the anti-trans NYTimes and one of their subsidiaries

• Bluesky hasn't said anything about their process for making decisions about who's "notable" enough for them to verify and how they decide somebody's "authentic".

To be fair, I am seeing a bit of discussion of some of these issues here. But I'm not seeing anything about consent, or community moderation, or equity. Instead, the vast majority of what I'm seeing is people saying hat the approach of external verifiers (run by entities other than Bluesky) and the Bluesky app attaching privileged semantics to the annointed ones isn't "decentraized."

Is that really the important thing here?

#bluesky #verification #fediverse

@thenexusofprivacy @rudyfraser.com @ngerakines.me @DataDrivenMD

Did the Self-Verification via DNS thing on Bluesky months ago—@islandinthenet.com. Before the new blue checks.

Anyone with a domain can do this.

@khurtwilliams Sure, I did it too - @thenexusofprivacy.net. But a lot of people don't have domains, and it's easy enough to set up a real-looking domain for an individual account as part of impersonation, so it's useful to have other mechanisms as well.

@thenexusofprivacy @thenexusofprivacy.net I hear you—and you make a valid point. Not everyone has a domain, and yes, domains can be faked. But I think it's worth asking: what would a better approach look like?

What kind of verification could Bluesky offer that’s fair, accessible, and still resistant to impersonation?

I’d love to see more focus on that kind of constructive thinking. It’s easy to spot flaws, harder (but more rewarding) to help shape solutions.

And here's another example. ‪Frank Hecker discussed he analogy between Bluesky's approach and certificate authorities (CAs) in browsers on Bluesky; so did @cwebber here on fedi. Good points by both! But ...

The Bluesky discussion included discussions of verification as a security measure (and the risks of ad hoc security functionality), power dynamics, and other possible approaches like petnames, Trust over IP, using DV/IV/OV/EV SSL certificates, and other interesting topics.

The fedi discussion was almost completely developers discussing situations where people overrode the browser's (or OS's) list of root CA's. Is that really the key point here?

Again, don't get me wrong: the point Christine is making in the original post is a good one -- my frustration relates to where the discussion went from there. I'd use somewhat different language than Christine (since Bluesky's initial implementation does involve mutliple independently-run verifiers I'd consider it at least somewhat decentralized, but power centralizing) but that's not the important thing here. I certainly agree that this implementation approach very much fits the pattern of Bluesky introducing something that's architecturally decentralized but initially almost completely centralized operationally, with vague plans for more future operational decentralization and no discussion of pwer dynamics. Like I say, there's a lot to critique here!

But there's also a lot to learn, and at least from the discussions I'm seeing on fedi, people are generally taking a pass on the learning opportunities.

@thenexusofprivacy You're right that the original post discussed those other things, and maybe I should have highlighted that.

Still, I don't think the "mulitple verifiers" changes much in the analysis of whether it resembles CAs: browsers also ship with multiple certificate authorities, which each act like verifiers in this case.

And here's another example. ‪Frank Hecker discussed he analogy between Bluesky's approach and certificate authorities (CAs) in browsers on Bluesky; so did @cwebber here on fedi. Good points by both! But ...

The Bluesky discussion included discussions of verification as a security measure (and the risks of ad hoc security functionality), power dynamics, and other possible approaches like petnames, Trust over IP, using DV/IV/OV/EV SSL certificates, and other interesting topics.

The fedi discussion was almost completely developers discussing situations where people overrode the browser's (or OS's) list of root CA's. Is that really the key point here?

Again, don't get me wrong: the point Christine is making in the original post is a good one -- my frustration relates to where the discussion went from there. I'd use somewhat different language than Christine (since Bluesky's initial implementation does involve mutliple independently-run verifiers I'd consider it at least somewhat decentralized, but power centralizing) but that's not the important thing here. I certainly agree that this implementation approach very much fits the pattern of Bluesky introducing something that's architecturally decentralized but initially almost completely centralized operationally, with vague plans for more future operational decentralization and no discussion of pwer dynamics. Like I say, there's a lot to critique here!

But there's also a lot to learn, and at least from the discussions I'm seeing on fedi, people are generally taking a pass on the learning opportunities.