Salta al contenuto principale


Fediverse Report – #111

A new security fund for the fediverse, and the Lemmy developers held an AMA.

The News


The Nivenly Foundation, the organisation that administers the Hachyderm.io instance, is opening a new security fund to sponsor contributors who disclose security vulnerabilities. All software has security vulnerabilities, and the fediverse is no exception. The recent Pixelfed vulnerability, which affected non-Pixelfed servers, is a clear example of how fediverse software can make software vulnerabilities more complex due to the interaction between different software platforms.

The Nivenly Fediverse Security Fund will sponsor $250 USD for vulnerabilities that are rated as high risk (7-9 CVSS score) and $500 USD for vulnerabilities with a critical score (9+ CVSS). The program will run until the end of September 2025. Nivenly members “hold a member vote to determine if we want to continue the program, and to establish a longer-term committee to steward and maintain the program.”

Last week, I wrote how Pixelfed’s vulnerability actually showed three different problems: The main problem is Pixelfed’s software vulnerability itself, but there were also two other problems: other software like Mastodon do not make it clear which risk comes with their private posts feature. And once a leak like this one happens, very few fediverse software admins communicated to their users that they might have been affected.

A security fund contributes to combating software vulnerabilities, but it can also help with communication to the rest of the fediverse once a vulnerability is found. It incentives that standard industry practices regarding software vulnerability get followed, and make communication clearer to a wider audience. For example, if Pixelfed’s recent vulnerability had gotten a CVSS classification, it might have been easier to make the severity of the vulnerability explicit to other fediverse software admins. In turn, this might have made it more likely that server admins would communicate the situation with their users.

In last week’s email essay I also wrote about how the fediverse is missing governance infrastructure that connects the various independent nodes and communities. One way to view the fediverse is as a response to centralised Big Tech platforms. These platforms have centralised governance, and are under the control of few people. The fediverse’s response to this is to build a social network that consists of tens of thousands of independent communities, all with their own governance structure. The fediverse has been successful in decentralising the single entity that oversees a social network into many pieces that all oversee a small portion of the network. But it has struggled to build a governance structure that ties all these individual pieces together again.

The Nivenly Fediverse Security Fund is a good example of this problem: software security impacts all the thousands of independent fediverse communities, but there is no overarching structure to collaborate and improve the security. It took one server taking the initiative into their own hands and provide a service for the entire network, at their own cost. Ideally, communities would collaborate on such a security fund instead. Nivenly’s announcement does leave space for such a future direction of the fund, saying that they are open to “establish a longer-term committee to steward and maintain the program”.

Note: if you sign up for my email newsletter, you get a weekly essay about the open social web that I do not publish anywhere else. You can sign up right here:

The Lemmy developers, Dessalines and nutomic, held an Ask Me Anything recently, and here are some of the answers that stood out to me:

  • Lemmy is working towards their 1.0 release. This is currently expected to be in the fall, although nutomic also says that “these things always take longer than expected”. He also expects some instances like lemmy.ml already to upgrade some months before.
  • One of the main features for Lemmy 1.0 is private communities, where only approved accounts can browse and posts to the community. This type of closed group functionality is in high demand, and both Mastodon and Pixelfed have tried to implement it. Mastodon got a grant for it, but the proof-of-concept code has been sitting there since 2022. Pixelfed has announced and teased a group feature multiple times over the year and showed screenshots of it, but it also is not publicly available yet.
  • Lemmy posts are interoperable with Mastodon, but the interoperability is not great: a Lemmy post appears on Mastodon as the title plus the URL. There has been many conversations about how Mastodon handles content from other platforms, with no changes so far. In this AMA, nutomic is explicit in saying that it is up to Mastodon to change this. While Mastodon seems open to the idea, and has been in conversations with developers from platforms like Ghost and NodeBB on how to show their content better on Mastodon, there has been little indication that Mastodon is taking steps towards making Lemmy content also better visible on Mastodon.
  • On the subject of how Lemmy can grow, Dessalines describes it as an organic progress, saying: “niche communities on reddit will keep getting fed up with the changes, and migrate to lemmy.” Nutomic describes a similar dynamic for fedi and Bluesky more broadly, saying that he expects that over the long term the fediverse might grow in a similar manner: “when the Bluesky admins make decisions that the community doesnt like, and then there may be another migration wave to the Fediverse”. Both replies indicate Lemmy’s vision of how the project can grow in the long run: stay consistently working on your product, and because platforms like Lemmy are not beholden to investors, they can have a longer lifespan, and outlive platforms who are beholden to shareholder expectations.
  • Grouping of communities (similar to PieFed’s topics or Reddit’s multireddits) “will be implemented soon“.

Ahoy! is a one-day conference for the European Social Web, and will be held on April 24th 2025 in Hamburg, Germany. The conference is mainly focused on Bluesky and the AT Protocol, and has some super fascinating speakers of people who are in the forefront of building new communities on the open social web. If you’re around I can definitely recommend it. I’ll be doing some interviews with people there, so if you are considering joining, let me know and we can say hi!

The Links


That’s all for this week, thanks for reading! You can subscribe to my newsletter to get all my weekly updates via email, which gets you some interesting extra analysis as a bonus, that is not posted here on the website. You can subscribe below:

#fediverse

fediversereport.com/fediverse-…


Fediverse Report – #110

A vulnerability in Pixelfed caused private posts from other platforms to leak, a post-mortem on the CSAM scanner from IFTAS, and Fediforum has been cancelled.

Pixelfed vulnerability impacts private posts across most of the fediverse


The fediverse suffered from a significant breach for private accounts, that affects the large majority of fediverse servers, due to a vulnerability in the Pixelfed software. What is notable about the situation is that the software vulnerability is in Pixelfed, but the affected accounts are not exclusive to Pixelfed: accounts on Mastodon and other fediverse software with a form of private accounts are also vulnerable. The vulnerability was found by the independent developer Fiona, who wrote a blog post about the vulnerability and the disclosure process.

To understand the situation, a short explanation of two features of Mastodon and some other fediverse microblogging software, locked accounts, and follower-only posts. Together these two features make it possible to have a form of private accounts. Locked accounts means that you cannot automatically follow that account, it has to be approved instead. Follower-only posts means that the post will only be displayed to your followers.

When a locked account approves a follower, follower-only posts now get send to the server that this follower is on. Because the receiving server now has this follower-only post in their database, they need to correctly handle whom they show this post to and whom they do not. If another account on the other server also tries to follow the locked account, but the locked account does not approve, this third account should not be able to see the messages. This is where Pixelfed’s vulnerability comes in: Pixelfed was not waiting for a confirmation if a follow request was approved, it assumed that it was automatically approved. That is how any private posts made on (almost) any fediverse server could be leaked: if a Pixelfed server already had the private post (because of someone of Pixelfed followed the locked account with approval), it would show it to anyone else who also tried to follow the locked account, even if the locked account rejected the follow request.

Pixelfed’s vulnerability points to deeper issues with the fediverse, activitypub and private posts. If all it takes to leak private messages is another server to be misconfigured, than it indicates the huge security risk inherent in private posts via ActivityPub. Even more so considering that the network incentivises and encourages people to build their own software implementations, which increases the risk of security vulnerability and other misconfigurations significantly. For simplicity I’ll focus here on Mastodon, although it also goes for other microblogging fediverse software that offers a combination of follower-only posts and locked accounts. At its core, private posts via ActivityPub requires to trust other servers. This is how ActivityPub works: your server sends posts to another server. There is no way to enforce that this other server respects your preference on how they should handle this post. If you do not trust another server to handle your data properly, the only way to deal with that is by not sending your post to that server.

When you make a follower-only post on Mastodon, the UI prompt warns you that followers-only posts without setting your account to locked allows anyone to view your posts by simply following you. The documentation for Mastodon also reinforces this, saying: “To effectively publish private (followers-only) posts, you must lock your account–otherwise, anyone could follow you to view older posts.” The documentation makes it clear that Mastodon views the combination of follower-only posts with a locked account as private posts. But nowhere is it made clear that these posts being private depends on other servers being good actors and not having an error in their code. So using private posts on Mastodon comes with the risk of the private posts being leaked due to flaws in other software, without people being aware of this risk.

Once a leak like this one happens, it is unclear who is responsible for communications with affected users. It was a flaw in Pixelfed that caused the vulnerability, but it is other people on other fediverse servers that are affected. Pixelfed developer Daniel Supernault has only made minimal announcements, urging Pixelfed admins to upgrade, without further explanation to the people who are actually affected by the vulnerability. Personally I think Supernault should have handled communications significantly better. But it is the thousands of fediverse server admins who provide the actual social networking to people on their server. They are the ones who are offering a social networking site with a variety of features, including the ability to make private posts (as advertised by the Mastodon software), and are the ones who are responsible for handling the data of their users. I could only find one example of a server admin that has informed their users of the situation, even though it is the data of their users that is affected. I’m unclear if this is because the admins are not aware of what’s going on, or the admins view it as the responsibility of someone else to inform people that data they thought was private might potentially have been leaked.

Overall, it means that there actually three separate problems going on at the same time:

  • The first problem is that Pixelfed had a vulnerability which leaked private data from people on other platforms.
  • The second problem is that software like Mastodon and others promise private posts, without explaining what the risks are of using private posts, and that this depends on other servers behaving correctly. The Pixelfed vulnerability shows that these concerns are not theoretical or minor, but can happen to one of the biggest fediverse software/server.
  • The third problem is that when private data gets leaked, most fediverse server admins do not inform the people on their platform that they might have been affected by this.

It is still unclear to what the direct impact is of the Pixelfed vulnerability, and how many people’s private post have been accessed by others, and it’s unsure if that will ever be answered. But it is the indirect impact of the situation that I’m most interested in: will this change how people perceive private posts, and will it fediverse server admins take a clear position on when they should inform their users, and when the should not?

IFTAS’s post-mortem on their Content Classification System


IFTAS, the Independent Federated Trust And Safety organisation, has released a post mortem on their content classification system (CCS). The CCS project was a pilot project to detect and report CSAM for a small group of Mastodon servers, and lasted for half a year. The pilot was shut down after IFTAS did not manage to find the funding they were looking for, and the organisation had to shut down most of their projects this month.

CCS operated on 8 servers, which combined have around 30k monthly active users, and IFTAS found a total of 80 matches, averaging 4.29 matches per 100,000 media files. IFTAS writes:

“4.29 matches per 100,000 may not sound like a large number. However, to be clear, this is a higher number than many services would expect to see, and it includes a broad range of media, from “barely legal” minors posted publicly, to intimate imagery shared without consent, to the very, very worst media imaginable. In some cases, it was apparent that users were creating accounts on host services to transact or pre-sale media before moving to an encrypted platform, under the belief that Mastodon would not be able to detect the activity.”

The results show that there is a clear need for proper CSAM scanning and reporting services for the fediverse, and that IFTAS does not have the funding to provide such a service is a significant loss to the network.

On a note related to IFTAS’s funding: Erin Kissane gave a talk at the AT Protocol conference recently, in which she talked about ‘vernacular institutions’. She described vernacular institutions as emergent and local organisations, which solve practical needs on the ground. Kissane describes vernacular institutions as ‘more useful than legible’. She then mentions IFTAS as a clear example; it provides a need for local communities (as illustrated by the CCS project), but its illegibility made it hard for funding organisations to understand what IFTAS was doing and provide them with the funding they need.

Fediforum has been cancelled


Fediforum has been cancelled, to be rescheduled at a later date. The unconference about the fediverse and the open social web was scheduled for today and tomorrow, April 1-2. This was supposed to be the 5th edition of Fediforum, which consists of speed demos and sessions that anyone can run on any topic. Fediforum is organised by Johannes Erst, with Kaliya ‘IdentityWoman’ Young as the co-organiser. Transphobic tweets by Young had surfaced in the days leading up to the event, and various prominent community members announced that they were either withdrawing themselves from the event, or said that they personally would not want to go to the event. Ernst then announced on his personal account that Young would be “transitioning out of Fediforum”. A day later (March 31), the official Fediforum account confirmed that Young would no longer be involved. At this point, community trust in Ernst was damaged and the discourse had reached a harmful stage, and Ernst decided to cancel the unconference and reschedule it to a later date. WeDistribute has a more extensive writeup of the situation here.

An unconference like Fediforum depends to a large extent on community trust and good intentions, and it was clear that the vibe was not great for constructive conversation at the point that Ernst decided to postpone the event altogether. Still, Fediforum provided a great place for fediverse projects to do some promotion with the speed demos, and Fediforum said that they even had a waiting list for this edition. There is a clear demand for an (un)conference like Fediforum, but the fediverse has not managed to create other community events that allow people to showcase their fediverse project in the last few years, besides Fediforum itself.

At the time of publishing, Fediforum held a 90minute long townhall/roundtable discussion on the future of Fediforum and the broader issues. I’ll write more about this next week.

The Links


That’s all for this week, thanks for reading! You can subscribe to my newsletter to get all my weekly updates via email, which gets you some interesting extra analysis as a bonus, that is not posted here on the website. You can subscribe below:

#fediverse

fediversereport.com/fediverse-…


reshared this