thenexusofprivacy

thenexusofprivacy , 5 days ago

@clacke great thread. It would be great to know more about the word fediverse was getting used in 2012, the The Federated SNS (Fediverse) Historical Timeline likes to a Twitter archive that doesn't show usage really picking up until early 2013. But then again that's usage on Twitter ... what about actually on the (proto-)fediverse?

thenexusofprivacy OP , 21 days ago

Fork it! It's time for a Mastodon hard fork proposes a new fork of Mastodon that focuses on safety, community, accessibility, working well with others -- and takes a community-driven and inclusive approach

If a project like that goes forward, would you consider helping?

Please pick all that apply! And, if you've got suggestions for other areas, please leave them in the replies

#ForkIt

thenexusofprivacy OP , 1 month ago

Suppose that a new fork of Mastodon starts up with an explicit goal of taking a community-driven and inclusive approach -- and prioritizing safety and accessibilty. Would you be interested in helping?

Please pick all that apply!

thenexusofprivacy , 1 month ago

@jerry congrats, and kudos to you for all the hard work!

thenexusofprivacy OP , 1 month ago

@oliphant You provided a widely-used blocklist that included threads.net. Now, you provide a replacement blocklist filling the same role that doesn't include threads.net. That certainly seems welcoming to me!

If you don't want the Oliphant blocklists to be so welcoming to threads.net, there are other alternatives to maintaining that old list. For example you could provide two lists, Tier0 and Tier0-with-threads. Or you could even do two, Tier0 and Threads-blocklist. I'm sure there are other possibilities as well.

thenexusofprivacy OP , 1 month ago

That's certainly true ... but the creation and distribution of the Oliphant blocklists does fall to Oliphant alone.

@thisismissem @oliphant

thenexusofprivacy , 1 month ago

useful, thanks very much @ilja!

thenexusofprivacy OP , 1 month ago

I released an updated version of the post, using a different approach.

https://privacy.thenexus.today/how-to-block-threads-on-mastodon/

thenexusofprivacy OP , 1 month ago

Here's another update tor "How to Block Threads on Mastodon", now with two different options and a discussion of privacy tradeoffs!

https://privacy.thenexus.today/how-to-block-threads-on-mastodon/

Thanks @LaurensHof and @renchap for the discussion of what information is (and isn't) shared with Threads when you visit a profile.

thenexusofprivacy OP , 1 month ago

infosec.exchange is also federating, and @jerry also set up infosec.space for people who want an account on an instance that does't federate.

As somebody who's lften critical of Meta on the prvacy side I find it very ironic that they're making federatin opt-in at the user whereas on Mastodon it's opt-out 😂

@seb
@spmatich

thenexusofprivacy OP , 1 month ago

:100a: PixelFed did add an opt-in for individual users ... Mastodon, not so much. Sigh.

@jerry @seb @spmatich

thenexusofprivacy , 1 month ago

Yeah, this is a situation where the fediverse's reliance on instance-level blocking means that instances and people that want to federate don't have good tools. With Threads' tolerance for hate groups (etc), account-level blocking's seems like it's going to be pretty vital. Can instances upload lists of individual blocks? How easy would it be to adapt infrastructure like FediBlockHole and FediCheck to handle individual blocklists?

@thisismissem @evan

thenexusofprivacy , 1 month ago

that seems suboptimal. @thisismissem @evan

thenexusofprivacy , 1 month ago

On the one hand that makes sense, on the other hand that means that every fediverse instance has to wait for Libs of Tik Tok to federate there before blocking them which seems ... suboptimial. @tchambers you often say "we have the tools" but it seems like this is a situation where we not only don't have the tool but it'll be hard to build.

@thisismissem @evan

thenexusofprivacy , 2 months ago

Looks great!
@hacks4pancakes @pancakescon

thenexusofprivacy , 2 months ago

Well one clear lesson is that you absolutely need either an allowlist or a denylist. It's like the old maps that say "here there be dragons" except it's "here there be nazis, terfs, csam, and more".

I was just looking at the GoToSocial code and they have a very nicely symmetrical implementation of domain blocks and allows - https://docs.gotosocial.org/en/latest/admin/federation_modes/ describes how they work in blocklist mode and allowlist mode.
But I think one of the things that makes allow-list more challenging in practice for anything but "i only want to federate with this know list of instances" is that you have to build some kind of mechanism on top of that.

Of course mechanisms are also needed on top of blocklist mode, As long as most instances aren't bad actors (which has historically been the case today) and you don't mind a little abuse, doing it in reactive mode works okay ... and there's now infrastructure for importing and updating a list of "known bad actors". I could certainly imagine getting a similar list of "known good actors" but for historical reasons the current infrastructure doesn't really support that, or at least has never been used in that way. And what about when new instances start up? So actually making it work at scale is still something of an open problem.

@devnull @jdp23

thenexusofprivacy , 2 months ago

@dansup Hopefully the rest of the fediverse would follow @pixelfed 's lead on this!

How did Autospam hold up against the current wave?

thenexusofprivacy , 3 months ago

@jerry remember, it's always Monday somewhere in the solar system!

thenexusofprivacy , 4 months ago

@maegul have there been any active user numbers on bsky? Mastodon's historical retention is < 15% so there are < 1M MAU today (not counting the broadly-defederaed "bad fedi" instances). Bluesky started invite-only which makes it easier to have a higher retention rate and it's newer so it wouldn't surprise me if it's bigger than Mastodon already or at least fairly close.

To me it's not so much a reason to dump on #Mastodon or the #fediverse, as an indication that the opportunity that Mastodon didn't take advantage of is still there. Bluesky hasn't addressed their moderation problems and so it's going to be very bumpy when they open it up, and also they haven't really started to federate and there are likely to be bumps there as well. They've got some good things as well, there's a lot the fediverse can learn from BlackSky, and it's not an either-or thing. https://privacy.thenexus.today/work-together-with-metas-fediverses-and-bluesky/ talks about some ways the fediverse and the Bluesky/ATProto world can work together.

thenexusofprivacy , 4 months ago

Yes @aendra is great, i assume you saw https://www.aendra.com/posts/my-top-bluesky-feature-requests-for-2024 -- the point about how "some part of me feels strongly that the "federate by default, public by default" nature of the Fediverse is a huge driver of these issues is" is completely on target. And functionality aside, I agree that Mastodon today acts like they don't want journalists around. Of course some of it's also that the more positive aspects of not wanting transphobic journalists around -- which has been an issue for newsie.social and journa.host -- and the question is how to keep that withough the exclusionary attitudes to other journalists.

@maegul @mackuba

thenexusofprivacy , 4 months ago

Great discussions, thanks for the perspectives @aendra. I very much agree about Blueksy being a better fit for a public broadcast microblogging platform and the fediverse being more a place of networked communities.

A couple of the other posts in "Strategies for the free fediverses" (the regions of the fediverses that defederate Threads) and talked about that model -- Emphasize networked communities and Support concentric federations of instances and communities. It's tricky because there's actually a school of thought in the fediverse that aspires to the big flat model, so that's kept mainline Mastodon in particular from prioritizing functionality that would be very helpful for the network-of-networks. A lot of the influential people who don't particularly care for the local communities are supporting federation with Threads so we'll see how it works out.

Agreed that it's not clear journalism-centric instances accomplish at this point. Verification is one of those areas where the fediverse thinks its in better shape than it is (and it's a hard problem in general).

@maegul

thenexusofprivacy OP , 4 months ago

The free fediverses should focus on consent (including consent-based federation), privacy, and safety

https://privacy.thenexus.today/free-fediverses-and-consent/

(Part 2 of "Strategies for the free fediverses")

#fediverse #mastodon #fedipact @fediversenews

thenexusofprivacy OP , 4 months ago

The free fediverses should emphasize networked communities

https://privacy.thenexus.today/the-free-fediverses-should-emphasize-networked-communities/

Here's how @lrhodes describes the Networked Communities view:

"instances are valuable for the relations and interactions they facilitate locally AND for their ability to connect you to other parts of the network."

By contrast, @evanprodromou notes that "Big Fedi" advocates typically see instances as typically see the instance as "mostly a dumb pipe." But The Networked Communities view aligns much better with the free fediverses' values – as does the "Social Archipelago" view @noracodes sketches in The Fediverse is Already Dead. Not only that, it's good strategy!

@fediversenews #fediverse #threads #fedipact

thenexusofprivacy OP , 4 months ago

The free fediverses should support concentric federations of instances

Part 4 of Strategies for the Free Fediverses

https://privacy.thenexus.today/the-free-fediverses-should-support-concentric-federations-of-instances/

Here's how @zkat describes caracoles: "you essentially ask to join concentric federations of instances ... with smaller caracoles able to vote to federate with entire other caracoles."

And @ophiocephalic's "fedifams" are a similar idea: "Communities could align into fedifams based on whatever conditions of identity, philosophy or interest are relevant to them. Instances allied into fedifams could share resources and mutually support each other in many way"

The idea's a natural match for community-focused, anti-surveillance capitalism free fediverses, fits in well with the Networked Communities model discussed in part 3, and helps address scalability of consent-based federation discussed in Part 2.

https://privacy.thenexus.today/the-free-fediverses-should-support-concentric-federations-of-instances/

#fediverse #fedipact #threads @fediversenews @fediverse

thenexusofprivacy OP , 4 months ago

The free fediverses should make it easier to move between (and create) instances

Part 5 of Strategies for the Free Fediverse

https://privacy.thenexus.today/make-it-easier-to-move-to-instances-in-the-free-fediverses/

There's likely to be a lot of moving between instances as people and instances sort themselves out into the free fediverses and Meta's fediverses -- and today, moving accounts on the fediverse today. There are lots of straightforward ways to improve it, many of which don't even require improvements to the software. And there are also opportunities to make creating, customizing, and connecting instances easier.

#fediverse #fedipact #threads @fediversenews

thenexusofprivacy OP , 4 months ago

The free fediverses should work together with people and instances in Meta's fediverses and on Bluesky whose goals and values align with the free fediverse

https://privacy.thenexus.today/work-together-with-metas-fediverses-and-bluesky/

Part 6 of Strategies for the free fediverses

Many of the Meta advocates I've talked to share the free fediverses' long-term goal of building a sustainable alternative to surveillance capitalism -- and the same is true for people on Bluesky. So there are likely to be situations where some of the people and instances in Meta's fediverses and Bluesky wind up as situational allies to the free fediverses.

A few areas where collaboration could be very useful:

• A key principle of organizing is meeting people where they are.

• Moderation on decentralized networks is a shared challenge.

• Bringing concepts similar to Bluesky's custom feeds to the fediverses, and more generally focusing on human-focused and liberatory (as opposed to oppressive) uses of algorithms in decentralized social networks designed from the margins.

• Meta's fediverses, Bluesky, and the free fediverses are all vulnerable to disinformation.

https://privacy.thenexus.today/work-together-with-metas-fediverses-and-bluesky/

#fediverse #threads #bluesky #organizing @fediversenews

thenexusofprivacy OP , 4 months ago

Thanks for the lengthy response @tallship I'm using the plural of "fediverses" to emphasize the evolution to regions. The split between instances that federate with Meta (Meta's fediverss) and ones that don't but instead reject surveillance capitalism (the free fediverses) isn't the only one.

As to what Meta's up to, here's my thoughts. https://privacy.thenexus.today/embrace-extend-and-exploit/

@fediversenews

thenexusofprivacy OP , 4 months ago

Instances in the free fediverses should consider "transitive defederation" from instances that federate with Meta

https://privacy.thenexus.today/consider-transitively-defederatiion/

Part 7 of Strategies for the free fediverses

Transitive defederation -- defederating from instances that federate with Threads as well as defederating from Threads -- isn't likely to be an all-or-nothing thing in the free fediverses. Tradeoffs are different for different people and instances. This is one of the strengths of the fediverse, so however much transitive defederation there winds up being, I see it as overall as a positive thing -- although also messy and complicated.

So the recommendation here is for instances to consider #TransitiveDefederation: discuss, and decide what to do. I've also got some thoughts on how to have the discussion -- and the strategic aspects.

https://privacy.thenexus.today/consider-transitively-defederatiion/

@fediversenews @fediverse #fediverse #fedipact #threads

thenexusofprivacy , 4 months ago (edited 4 months ago)

@jerry it's a very reasonable plan, as always you do know what you're talking about. The only suggestion I'd make is to consider holding off on unlimiting threads until 30 days after they give all threads users access to federation to give some time to see how it'll shake out.

In terms of transitive blocking, it's not just punitive; it decreases the opportunities for indirect data flow to threads and indirect harassment from threads. It's still TBD how signifiacnt those threats will be, and how much transitive blocking will mitigate them, so I can certainly see why you're not doing that, but there are indeed real non-punitive reasons.

thenexusofprivacy , 4 months ago

Agreed. Some instances will decide to block Threads, that's a valid choice. Other instances will decide not to block Threads, also a valid choice, but that leaves the question as to whether people on that instance federate by default. Opt-in at the individual level offers more safety and privacy, and is in keeping with the fediverse's values of consent (which, while intermittent and somewhat aspirational, is still a good value)

@reflex @downey @fediversenews

thenexusofprivacy , 5 months ago

I asked a similar question a couple of days ago and it seems like the answer depends on whether Sue's server is running authorized fetch, -- and also on how Joe's server implements boosts and whether Threads verifies posts, per @Lady's post at https://glitch.cat.family/@Lady/111597669731975795

@darius @misc

thenexusofprivacy , 4 months ago

@jerry Sorry I missed this when it came out ... if it's still something you're considering:

If there's a desire to federate then I think the idea of running a job that domain blocks them from each account is a very good one -- it basically makes it opt-in.

Is auth-fetch turned on here? If not, people should know that once Threads starts accepting inbound federation, even if they block Threads, their posts could still get to Threads if others boost them. [This would be true even if infosec.exchange blocked Threads -- people on other instances who have followers on Threads boosting our posts.]

thenexusofprivacy , 5 months ago

@Gargron Compare and contrast what Threads' privacy policy says they can do with this data to a privacy policy like @admin's and it's clear that Threads' privacy policy tries to give the company as much ability to use data without requesting additional consent (although EU DPC's may have something to say about it). Also, unlike every Mastodon server out there, Meta's business model relies on exploiting people's data -- and they have a long track record of using data without consent.

So while it's true that every well-written social network pricacy policy does cover this kind of data, no it's not at all "absolutely the same thing".

Also you suggested elsewhere that "Personal data usually carries a slightly different meaning than a public profile and posts you choose to broadcast to the open web." In the EU, GDPR is very explicit that personal data includes publicly available data such as this.

@mastodonmigration @rexum

thenexusofprivacy OP , 5 months ago

@drwho Not necessarily. In the short term, the huge split in the Republican party means that the NDAA's already not a slam-dunk, so throwing gasoline on the fire with FISA activism could potentially have an impact. It also adds to pressure on Speaker Johnson, who's under a lot of fire from Republicans for how badly he's handled this mess.

And even if they do the short-term reauth (which I agree is more likely than not), it's still very much an open question as to what happens next -- it could be anything from GSRA or PLEWSA (with significant reforms) to a straightforward longer-term reauth with minimal reforms as a "compromise" to the odious FFRA (which broadens the scope). So pressure now is also a preparation for the next battle.

thenexusofprivacy OP , 3 months ago

Compare and contrast: Fediseer, FIRES, and The Bad Space

https://privacy.thenexus.today/fediseer-fires-and-the-bad-space/

Part 4 of "Golden opportunities for the fediverse – and whatever comes next"

The Bad Space is only one of the projects exploring different ways of moving beyond the fediverse's current reliance on instance-level blocking and blocklists. It's especially interesting to compare and contrast The Bad Space with two somewhat-similar projects:

• Fediseer is another instance catalog, including endorsements as well as negative judgments about instances.
• FIRES (an acronym for Fediverse Intelligence Recommendations & Replication Endpoint Server) is infrastructure for moderation advisories and recommendations.

(I originally shared this post here but forgot to included it in this thread. Oops! So I'm cut-and-pasting and sharing again. There's some interesting dialog in the comments in the original post.)

thenexusofprivacy OP , 2 months ago

Steps to a safer fediverse

https://privacy.thenexus.today/steps-towards-a-safer-fediverse/

Part 5 of "Golden opportunities for the fediverse – and whatever comes next"

The good news is that there are some straightforward opportunities for significant short-term safety improvements. If fediverse funders, developers, businesses, and "influencers" start prioritizing investing in safety, the fediverse can turn what's currently a big weakness into a huge strategic advantage.

Contents:

• It's about people, not just the software and the protocol

• It's also about the software

• And it's about the protocol, too

• Threat modeling and privacy by design can play a big role here

• Design from the margins – and fund it!

#fediverse @fediversenews