

Nice. This is one of a few promising forks. I think they’re on Codeberg too.


Nice. This is one of a few promising forks. I think they’re on Codeberg too.


I agree, but how is that related?


Yeah, he would never do cynical murders that violate international law, defenestration notwithstanding.


This is not going to be good.


This is a really good article and refreshing to see this being recognized as the double edged sword it is (albeit with one edge much sharper than the other). It will be interesting to see how different organizations deal with this. The temporary interaction limitation will be a bandaid in some cases but the deluge will just keep coming.
I’ve been interested in Mitchell Hashimoto’s new trust tooling. I’m not sure it will become a standard, but is a very interesting attempt, and dead simple.


I think he, like many, mistakenly think Iran is like other countries in the region that the US bullied in recent decades. He probably doesn’t listen to his command staff much, who no doubt tell him this is a foe much greater than you suspect.
Subterfuge there is one thing, but outright aggression is going to be very painful for everybody involved.


Okay but your best masons are. Architects and developers are different.


It’s a mixed bag.


Maybe I came off as dismissive or just stupid, but I really did mean to be helpful. Of course you don’t want users experience bad interactions. I meant if those interactions were for an actual intended reason. So yeah, never mind.
Bummer you’ve had a hard time. I think they and the free software community are trying to put together a good solution.


What server are you using and with which client most recently? It sounds like your device is unverified so untrusted or the key isn’t present.
To expand, “unable to decrypt” would affect a lot of users. That’s a good thing and exactly what you want it to do when not correctly trusted.


I use it all the time. There are many mature clients, and matrix is a protocol, so I don’t know what you mean. Since the sliding sync implementations, I have found it really nice to use.
Yes, subpoena was poorly worded. NSL is more likely. But still it is a time-forward threat, which means there is value while the server is or was accepting sealed sender.
And I wasn’t suggesting timing attack is required to defeat sealed sender. I was, on the contrary, pointing out that was a threat even with sealed sender. Though that is non-trivial, especially with CGNAT.
So in summary. You’re right. Sealed sender is not a great solution. But it is a mitigation for the period where those messages are being accepted. A better solution is probably out there. I hope somebody implements it. In the meantime, for somebody who needs that level of metadata privacy, Signal isn’t the solution; maybe cwtch or briar.
Sure. If a state serves a subpoena to gather logs for metadata analysis, sealed sender will prevent associating senders to receivers, making this task very difficult.
On the other hand, what it doesn’t address is if the host itself is compromised where sealed sender can be disabled allowing such analysis (not posthoc though). This is also probably sensitive to strong actors with sufficient resources via a timing attack.
But still, as long as the server is accepting sealed sender messages the mitigation is useful.
Don’t mistake me for saying you’re wrong. I agree with you, mostly. But sealed sender isn’t theater, in my view. It is a best effort attempt to mitigate one potential threat. I think everybody would like that solved but actually solving it isn’t easy as I understand it. Maybe not intractable, but if you have a solution, you can implement it. That is one of the things I like about free software.
In any case, I’m only saying Signal is good for a subset of privacy concerns. Certainly not that it is the best solution in all cases.
It isn’t a meme. It is a fact of modern cryptography in many settings. For example TLS, which is a huge bulk of the traffic, guarantees again privacy not anonymity. I’m not saying one shouldn’t care about metadata privacy. Every communication one engages in requires risk benefit analysis. If your threat modeling shows that for a given message, anonymity is required, then signal, and nearly every single other protocol out there is insufficient.
That doesn’t mean TLS or lib signal, or any other cryptographic tool is not useful, especially in conjunction with other tools.
There are many cases where I want my messages to be private and the cost of entry for the message receiver to be low. Signal is great for that. But I’m not saying no other tools should be considered, just that signal is good at what it does.
You’re the one making insults and I’m smug? Care to actually dispute anything said with reason?
Cool strawmen; I didn’t say any of that. Signal protocol is awesome for privacy, not anonymity. Maybe I don’t have half a brain, but I happen to think the double ratchet implementation is an impressive piece of tech. Maybe I’m as dumb as your fever dream, but compromised exits doesn’t make tor any less of an achievement. Though i2p is also superb. I guess my brain is too weak to understand why those statements are mutually exclusive.
It isn’t. But I see this same post over and over. Really feels like there is a campaign against signal. Also tor developed by US Naval Research, so I guess it’s bad too.
It also matters if you value organizations changing terms after attracting a community and changing to non-transparent solutions while claiming to be “open”. It matters if your values are different.
But you’re right too. If not logging in, your liability is probably not changing.