Please see our previous post for full context 👆

Why did we delay in notifying our users? After extensive internal discussions and advice from multiple movement lawyers, we made the difficult decision to delay informing our users, since an earlier public statement could have made the situation worse in a number of ways.

To be clear, the physical Kolektiva servers were not targeted or affected by the FBI raid. Our actual, live servers are encrypted, in that the hard drives are encrypted at rest. We have no reason to believe that any Kolektiva.social data has been compromised, outside of the database back-up that was seized. Our admin's various electronic devices and other drives were encrypted, and we swiftly rotated all passwords and keys as appropriate for any potential breach like this. In other words, we have no reason to believe this is an evolving threat to our server integrity, or our users' data security.

So then, why are we asking users to reset their passwords? The seized database did not contain user passwords, it contained hashed user passwords. To better understand why we recommend users change their password, here is a good explainer: https://www.troyhunt.com/we-didnt-encrypt-your-password-we-hashed-it-heres-what-that-means/

Without offering any excuses, we also think it warrants mentioning that the seized data would be similar to data obtained in any raid or other unauthorized access of any typical Mastodon server. It is the same data any cooperating instance admin can hand over willingly when requested. Unfortunately, there are serious limits to what admins of Mastodon instances can do to protect the data of their users. Users should always take precautions to protect the privacy of information, especially any sensitive information, they share on the Fediverse or anywhere else on the Internet. We hope that if nothing else, this situation serves as a learning experience for our users, and others on the Fediverse. It certainly has for us. For an intro to operational security on Mastodon, we strongly recommend checking out this guide: https://distro.f-91w.club/masto-opsec/

Going forward, we will continue to explore our legal options. Ideally, we would be presenting a comprehensive list of internal changes, policies and best practices that we plan to implement to avoid outcomes like this in the future. These are definitely conversations we have started having, and intend to continue, but we also want people to be aware that we're a small volunteer collective, and we are dramatically affected by these events. Things may be slow to develop. We also have to keep Kolektiva.social running and pick up the slack now that we are missing a crucial team member 💔 .

Our admin's legal situation is shitty, but they currently have the support and legal representation they need. We will post any information or calls for support if that becomes appropriate or needed.

As many understand, our political movements are currently facing high levels of state repression, which has resulted in an increase in digital and other forms of surveillance, raids and arrests, false and overblown criminal charges, increased use of pre-trial detention and lengthy prison sentences. At times like these, political movements are tested and solidarity and security culture become important touchstones for our work to make the world a better place for all.

Thank you again for your understanding, solidarity, and time taken to read all this.

@admin I'm not going to go into working on unencrypted data. Pretty certain that if your server can read the data, so could the FBI.

What I'm more concerned over is that this announcement is in July, and this is something you have known about since May.

@admin

Please cycle all RSA keys ASAP using "tootctl accounts rotate --all" !

These are stored in the database and are used for communication between instances (specifically, outgoing posts), these keys will allow impersonation when leaked.

@admin No full-disk encryption in use by your admin on their own box where they were working with your data? That's just as inexcusable as delaying the breach notification for a month.

Mindblowing.

EDIT: In addition to mindblowing, I submit that another term is also applicable: negligence. Gross negligence.

@admin

@admin Literally the only thing on my entire account that is NOT public is IP addresses and passphrase.

I just changed the passphrase-and I do not have a landline and have never had a contract phone. I get phones, prepaid SIMs, and airtime cash-only, no name.

No Google, no Facebook, no Twitter, no Tiktok etc, no ad supported apps at all. No data from personal info vacuuming monetized apps, all of them are banned on my hardware. Thus the kind of tactics used for J6 (broad warrants to Google and Apple) are useless against me.

Have fun trying to exploit my account from those kind of IP addresses motherfuckers. Want to fuck with me? Bring it on...

@admin it would be good to know if any safe guards have been put in place, either technical or social, to keep admins from holding local copies of the database for no reason.

If you really need to hack on the real user database, spin up a VM in the server environment. There is never a reason to have the database downloaded to a local drive and doing so goes against all best practices for handling user data.

@admin This may seem harsh but I believe this is an instance-ending event, and my opinion is that you should read-only your instance and give users their 3 months to get their data out.

"Please change your passwords" is an unacceptable path forward.

@admin This brings to mind this oldie but goodie from World Party...

""Someone was 'round here asking questions
'Bout someone who looks like you
I said, I don't know where you are
He said, that he was going to be back
I told him where you are..."

https://www.youtube.com/watch?v=DO1cW97Z3sU