Send a GIF to Contact A, Contact B receives random private images? Absolutely inexcusable slop code project. This class of state management bugs should not be possible with a well-architected client, period.
Signal's E2E encryption is more like End 2 Random End.
So 7 months of their users getting rinsed by an extremely serious issue exposing your private photos to random contacts. Seems like slop code to me. Those kinds of state management bugs should not be possible. It indicates code divorced from best practice state management.
Knowing that bug COULD exist, means that you cannot be sure that messages you send in Signal will make it to the recipient you intend given the poor quality. This means the E2E encryption is fundamentally broken, by the way. Because the client is lying to you about the true state of who it's about to send to.
The recipient text has fundamentally zero relationship to the true recipient of the message given that bug.
Having the UI and message sending code reference two different versions of state is incredible incompetence.
Jotted down my backup process for home. Spoiler: it's a bunch of SSDs sitting on top of a Raspberry Pi. But there's a few fun things in there too: raid, encryption, cron, make, rsync, ssh, Home Assistant and a tiny loaner dog. Enjoy.
Just on your first suggestion, this also means that if a person or process can drop a file (unknown to you) into your ~/bin/ then they can wreak havoc. Eg they can override `sudo` to capture your password, or override `rm` to send your files somewhere interesting, and so on.
Btw on the second suggestion, I think there's a command named `command` that can help with that sort of thing, avoids recursive pitfalls.
That would require someone to already want to sabotage me in particular, learn my private workflows, and also have write access to my home folder. At that point, All is Lost.
Don't tell people to sacrifice agency for apocalypse insurance that doesn't work, lol
No, don't do that as a precaution. As others have already answered correctly - it's too late to worry about such things if a malicious agent has write access to your ${HOME} dir.
I used to self-host email, it was mostly all initial setup and then it just worked for years. Eventually I got a bit wary about the security side of an internet-accessible box and decided to move the whole thing over to AWS SES. Wrote it up here:
Good question. So one change I made last year was to cap the number of queues the free account could utilize. It's sort of hard to know for certain if that was what moved the needle though.
There has been a suggestion that maybe the free plan could just be a time-limited trial instead.
But it feels like there is some risk associated with that - as often a customer will use the free plan for (eg) six months, before hitting the limits and becoming a paid account.
