Conversation

Notices

1. Embed this notice
   The Nexus of Privacy (thenexusofprivacy@infosec.exchange)'s status on Thursday, 24-Apr-2025 03:29:29 JST The Nexus of Privacy

   • Jorge Caballero, MD

   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

   • Embed this notice
     The Nexus of Privacy (thenexusofprivacy@infosec.exchange)'s status on Thursday, 24-Apr-2025 03:29:29 JST The Nexus of Privacy

     in reply to

     • Christine Lemmer-Webber

     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.

   • Embed this notice
     Christine Lemmer-Webber (cwebber@social.coop)'s status on Thursday, 24-Apr-2025 03:29:29 JST Christine Lemmer-Webber

     in reply to

     @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.