Please boost as I need lots of votes on this one to decide:
Would you rather have a Matrix server with fully encrypted disk that needs manual unlocking by the admin but will cause downtime on unexpected reboots (crashes or hoster, while admin asleep) or have automatic unlock (less secure) but no unexpected downtime...?
Automatic unlock will keep things running smoothly on unexpected reboots but server owners (hosters) could get to data.
Note that chat end-to-end encryption is always on.
I really want things to run smoothly but I also want paranoid security levels. I can't have both, so you the potential users need to vote on this. Note that unexpected reboots are not that common but when it happens it can be very annoying, especially in the middle of a conversation. 🤔
I mean, if the server gets forcefully rebooted by the hosters and things will be down until manual unlocking of the drives. 🤔
Honestly, it should happen once a month at most. I think I'd take paranoid security levels for a few hours downtime. I could have a trusted person unlock the drives if I'm asleep, too. 🤔
Yes, I'm thinking out loud.
@sindastra I've commented on Matrix, and managed to get one person to refuse to listen to my comments and insist that I was making things up, so... I'm going to just leave it alone (:
@Truck I'm not sure I follow. 🤔
@Truck Ah I remember you mentioned you don't like Matrix. To be honest I don't like it either as it has many issues. But I think I can live with using it on my own instance. My biggest issue with Matrix is that it's basically a distributed database and it's easy to get all the metadata. 😔
@Truck PS Have you heard of Threema?
@sindastra not in the past week, and I think I may have heard of it in _passing._
I could look it up but I'm compiling things for my reform2 (:
@sindastra As someone who runs a matrix server with FDE enabled (literally all my machines run on FDE), I can tell you my choice was to manually unlock. So far it caused unexpected downtimes exactly once.
Try to figure out your personal SLA. Probably you want to end up with 99%/year or even less. Then even a day offline is no problem and you can sleep well :)
@sheogorath @sindastra I'm just going to echo this - there is nothing wrong with 'even less' for a personal instance; for a group instance, if the group wants someone to handle everything all the time, they'd better be willing to pay for it. And not with 'freedom' or 'free beer' - eventually the beer adds up and you're drunk and unable to handle the server (:
@sindastra Just put half of the encryption key on the machine and half of it to a certain web adress where you obtain the second half via protocol of your choice. Now you can revoke the key easily and the machine can start without you. A malicious hoster or secret service could always try to get the LUKS key out of the RAM.
@sindastra @fmai Sorry if I'm misunderstanding, but couldn't the hoster physically read out RAM contents in any case if they have physical access, as long as the server is running (which is its job)? So – What's the scenario against which manual unlock protects, and is it more severe/significantly easier to execute than physical readouts?
@Xjs It is true that they could read it out of the RAM, especially on a virtual server. 😔 I guess a scenario would be when someone requests access and you can shut it down beforehand. The reason for a hoster would be the uptime, bandwidth and dedicated, static IPs (dual-stack). But since I'd enforce end-to-end encryption on Matrix anyway, worst thing anyone could get is meta-data (yes that's still bad, I know)... There's a lot to think about which is why I'm reaching out. @fmai
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!