A #closedweb Critique
- Design for Abuse: The #AP protocol is vulnerable to abuse, particularly in terms of Distributed Denial of Service (#DDOS) attacks.
- Push-Based Model: The push-based notification model leads to overloading servers, especially when a popular account generates a large amount of activity.
- Harassment Concerns: There is a perceived inadequacy in control issues to address the worry of harassment, with issues like the inability to disable replies not being implemented.
- Need for Defensive Model: A #geekproblem call for abandoning the working “native” #openweb path and push a “native” #closedweb path, with a complete overhaul of the protocol to incorporate defensive measures from the outset.
The Critique
From an #openweb and #4opens perspective, the critique highlights a different mindset that is clearly incompatible with the current path. But yes, there are questions about the balance between openness and security. Let’s not get lost in the #geekproblem and look at them:
Design for Abuse
Critique: The assertion that the protocol is designed for abuse is an overstatement, but it highlights genuine vulnerabilities. The open “trust” based nature of #ActivityPub and the #Fediverse, promotes decentralization and federation, but can indeed be exploited by malicious actors, people do brake “trust”. Transparency in code is crucial. Vulnerabilities should be openly discussed and addressed through community collaboration, most can be fixed by social norms rather than hardcoding. Data sharing is core, there should be as little as possible “private data” to abuse. Protocols should work with slow revisions to improved community feedback. Decision-making processes around security, should be based on social rather than coding, #openprocess is a core part of this.
Push-Based Model
Critique : The push-based model can indeed lead to server overloads. Popular accounts generating a lot of traffic can unintentionally cause DDOS-like situations. This is a normal lossy part of the “native” #openweb, we should work on this. Implementing caching strategies and lossy notification systems should be developed and tested within the community. Efficient data handling techniques should balance ease of hosting and speed of application, with ease of hosting first. Exploring hybrid models (push/pull) with RSS backup can lead to more resilient protocols use. Real time is less important than the app keeps working. Part of this is about ensuring that changes to the protocol are hard and slow, with debate and consensus.
Harassment Concerns
Critique : The constant talking about harassment tools and features such as disabling replies is a concern. Yes open networks are just that open, it’s the social norms of federation that make them a safe space, we need to build up our communes of trust. Developing robust moderation tools and anti-harassment features should balance with building strong social instances, who in the end do the work, be very careful of #closedweb paths in coding these features. Socialise data on harassment patterns helps to improve trust based moderation tools. The stories we tell and the way we work for moderation and anti-abuse measures should be developed collaboratively. Including diverse voices, especially those of vulnerable communities, in the social decision-making process for instances is crucial.
Need for Defensive Model
Critique: Starting with a defensive model is the wrong path. Many security and abuse issues can be mitigated with a trust-first approach. A good culture should be built into the core from the beginning, with active community involvement. Developing norms of behaver through community consensus helps build a more resilient system.
Conclusion
The #closedweb path tries to raise points about vulnerabilities and shortcomings of the current #ActivityPub and #Mastodon implementations. From an #openweb and #4opens perspective, the solution lies not in suggesting we abandon the native path and implemented protocol but in addressing these issues through open, collaborative, and transparent social processes. By leveraging the strengths of the #4opens framework, the community can work to creating secure, resilient, and user-friendly networks that are on the already on the successful native #openweb path.