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.

I ran out of hope any of this was missing context long ago. This is some twisted shit.

The sandboxes are different. The embeddable Java plugin sandbox was a bit different and susceptible to confused deputy and other attacks. So yeah, I guess you can say it is iterative but they’re kind of worlds apart. You can run thousands of wasm modules in a single process and have them all be completely isolated. Its performance and security gains, portability, and usability are all superb.

I guess I can’t really defend it well, but I think it is interesting and important.

It isn’t interesting for being bytecode. Rather for being the first universal sandboxed runtime for the browser and elsewhere. Being able to write in many languages and compile to wasm targets is awesome. Safety guarantees and performance are both great too. And it can run in tiny environments.

Great article. I think wasm is one of the more interesting things to happen in the last few decades in computer science, though there are many. I think it’s here to stay for sure, but am always curious where the adoption curve will go.

You can really just stop. If you leave it to languish and the community wants to continue, it will be forked. Nature of the beast. And nobody can fault you for that as long as you tell the community, “I’m out”.

I’m not saying that is the best method, but for anybody out there feeling a ton of pressure to the point it affects your wellbeing, you can stop.

Hell yeah. Sounds like a party. Is there an after lan party?

I wish that were true. But evil people get away with terrible stuff all the time and karma isn’t real.

It also means the people operating them will have a high threshold for consequences and maybe not care so much about the community.