Once again Proton hand over data on an activist to authorities, this time to the FBI via the Swiss High Court.
Proton is unsafe for use by frontliners.
https://www.404media.co/proton-mail-helped-fbi-unmask-anonymous-stop-cop-city-protestor/
Once again Proton hand over data on an activist to authorities, this time to the FBI via the Swiss High Court.
Proton is unsafe for use by frontliners.
https://www.404media.co/proton-mail-helped-fbi-unmask-anonymous-stop-cop-city-protestor/
Group-wide selfhosted mail is so often the solution here, but it needs to be done right, and with strong operational security posture. This includes the jurisdictional layer relative to operating context.
And yet #selfhosted mail is famously hard. We dedicate much time to this, deploying a full blown high-reputation MTA with webmail frontend, in the Fortress sessions https://courses.nikau.io/fortress/
@mihamarkic @JulianOliver use public key encryption, a server can encrypt all your non-encrypted incoming email with your public key, and only your client with your private key can decrypt it. Without your private key, nothing stored on the server can be decrypted.
This is pretty easy to implement yourself, using pgp, if you already run your own mail server.
@mihamarkic @JulianOliver ah. Yes, a good question, with, IMO, no good answers. On a laptop you can just prompt for a key or password on boot. On a server that must be able to reboot without human intervention, there is nowhere to store the key that's safe from snooping.
I've daydreamed about building a USB flash drive that only stays active for N seconds after a bus reset, then shuts itself off. Thus you could store a key on it that can be read at boot time, but not long after.
@mihamarkic @JulianOliver if they're not physically present then they can only attempt to read it during a short time window at bootup, when nothing but the kernel has started.
If they're physically present, all bets are off.