Synopsis: The article discusses the FBI’s seizure of the Mastodon server and emphasizes the need for privacy protection in decentralized platforms like the Fediverse. It calls for hosts to implement basic security measures, adopt policies to protect users, and notify them of law enforcement actions. Users are encouraged to evaluate server precautions and voice concerns. Developers should prioritize end-to-end encryption for direct messages. Overall, the Fediverse community must prioritize user privacy and security to create a safer environment for all.
Summary:
Introduction
- We are in an exciting time for users wanting to regain control from major platforms like Twitter and Facebook.
- However, decentralized platforms like the Fediverse and Bluesky must be mindful of user privacy challenges and risks.
- Last May, the Mastodon server Kolektiva.social was compromised when the FBI seized all electronics, including a backup of the instance database, during an unrelated raid on one of the server’s admins.
- This incident serves as a reminder to protect user privacy on decentralized platforms.
A Fediverse Wake-up Call
- The story of equipment seizure echoes past digital rights cases like Steve Jackson Games v. Secret Service, emphasizing the need for more focused seizures.
- Law enforcement must improve its approach to seizing equipment and should only do so when relevant to an investigation.
- Decentralized web hosts need to have their users’ backs and protect their privacy.
Why Protecting the Fediverse Matters
- The Fediverse serves marginalized communities targeted by law enforcement, making user privacy protection crucial.
- The FBI’s seizure of Kolektiva’s database compromised personal information, posts, and interactions from thousands of users, affecting other instances as well.
- Users’ data collected by the government can be used for unrelated investigations, highlighting the importance of strong privacy measures.
What is a decentralized server host to do?
- Basic security practices, such as firewalls and limited user access, should be implemented for servers exposed to the internet.
- Limit data collection and storage to what is necessary and stay informed about security threats in the platform’s code.
- Adopt policies and practices to protect users, including transparency reports about law enforcement attempts and notification to users about any access to their information.
What can users do?
- Evaluate a server’s precautions before joining the Fediverse and raise privacy concerns with admins and users on the instance.
- Encourage servers to include privacy commitments in their terms of service to resist law enforcement demands.
- Users have the freedom to move to another instance if they are dissatisfied with the privacy measures.
What can developers do?
- Implement end-to-end encryption of direct messages to protect sensitive content.
- The Kolektiva raid highlights the need for all decentralized content hosts to prioritize privacy and follow EFF’s recommendations.
Conclusion
- Decentralized platforms offer opportunities for user control, but user privacy protection is vital.
- Hosts, users, and developers must work together to build a more secure and privacy-focused Fediverse.
I’m curious, how would you do this in such a way that it wouldn’t come at the expense of effecting your high availability?
If the server were on-prem or in the cloud… and the system crashed/rebooted, how would you decrypt (or add the passphrase) to the encrypted drive?.. cause the likehood of the kernel crashing or a reboot after and update is higher than an FBI raid… and it would get tiresome to have the site being down, while we wait for Bob to wake up, log in, and type the passphrase to mount the encrypted hdd.
You could use something like HashiCorp Vault, but it isn’t perfect either. If the server were rebooted, it could talk to Vault and request the passphrase (automatically) , but this also means that the FBI could also “plug in” the server (at their leisure) and have it re-request the passphrase. … and if Vault were restarted there’s quite a process to unseal (unlock) a vault - so, it would be as cumbersome as needing to type in the passphrase on reboot.
My point / question is: yes, encryption (conceptually) is easy, but if you look at “the whole life cycle / workflow” - it’s much more complicated and you (as an administrator) might ask yourself “does this complexity improve anything or actually protect my users?”
Encrypting user data is pretty standard in the industry, and even required by law in the instance of servers hosting medical information in the US. Consumer software for disk encryption like you mentioned is substantially different from usual encryption solutions employed by data centers. Whole disk encryption is commonly done at a firmware or hardware level. For an example, iPhone embedded storage is fully encrypted and tied to the rest of the phone’s hardware. No user input required.
It wouldn’t have mattered if the guy had encryption any way because, as the article mentioned:
Where does HIPA state the medical data must be encrypted on the machine? I am not an expert on HIPA put don’t remember seeing that when looking at it before.
There are several methods available for encrypting server disks without compromising availability but the best I’ve used is Network Bound Disk Encryption in the form of tang and clevis utilities. The encrypted server consults a tang server (or multiple servers using Shamir’s Secret Sharing) for the decryption key and then boots without user intervention. You can put a range of controls and redundancies around tang servers but the idea is they are only available on the local network.
Before you say there’s no point encrypting a disk and then automatically decrypting it, think about the use case. The encrypted server will auto decrypt if everything is fine, but remain protected if that server is stolen or the decryption servers are shutdown or modified. It provides convenience while maintaining a level of protection. It also ensures disks are preemptively encrypted if they ever need to be returned for a warranty claim, which is a much more likely event.
If you’ve got proper HA, then your secondary could still be up and running just but not receiving connections or running certain services (assuming a standard active/passive). Yes, one could still have a passphrase on encrypted boot and enter that via RA (DRAC,ILO, SSH preboot), or the credentials could be in a TPM etc.
None of those are foolproof, but protecting users’ data isn’t just about FBI raids, and disk encryption in general should still be part of the security toolkit because stuff like lost drives or improper disposal still happens.