Nothing to laugh at here in my view. It is FOSS. The reason it isn’t on there is sort of procedural. You could easily build signal from source, but signal prefers only their builds connect to their servers. They of course can’t enforce this but fdroid is happy to do so.

https://github.com/signalapp/Signal-Android AGPL

Looks like there are prebuilt binaries in the release.

Lots of good advice here. Best method arises but cannot be sought. When you run into something broken or you don’t like, don’t set it aside hoping somebody else will fix it. Fix it.

Even if the maintainer doesn’t want your change. This is the best way to grow the seeds of software freedom you’ve already planted by caring. This is the fundamental ethos in my view of a good steward of the community. When something isn’t ideal, they make it work for themself and then are willing to share if others find it useful.

Just hearing of it, but it looks like it is blink based (no thanks) and windows based (double no thanks). But I hope it works for you.

What‽ I haven’t heard customer support like that for decades from a company large enough to be recognizable. I’m a Proton user, but this is a hell of an endorsement.

Noooooo. Need integrated contacts. Priority 1!

They don’t seem to realize that higher level languages help us understand the code. Language models will be similarly capable of reading the binaries they ship. So what they doing is hiding code from users, not machines.

To clarify, I don’t mean right now. They haven’t been sufficiently trained on machine code and that lacks some semantic help. But the future they fear will have transformers just as capable with lower level code.

I think tools like Open Collective, Ko-fi, et al. are sort of that already. So you’d be building centralization atop centralization. That may be useful, but it is another place that would require a rake to keep the lights on, so again less money donated.

And what happens if two or more such services exist? Then you need a layer above that.

Yeah ok but zen is actually pretty good for a free browser.

Pretty sure it dates back to the dawn of commerce.

More anti-signal propaganda? Who is claiming it can’t be associated to a user. The messages are private, not anonymous.

I do each to the extent that I can, but it is a bit more difficult outside the country. And what actions we do each take isn’t always something we want to post about online. At any rate, petitions won’t do it.

Generally need a reason to do something. Don’t see how signing this moves the needle. Protest and contact congressmen. Internet petitions won’t save you. Collective action irl, strikes, and raising hell might.

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.

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

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.

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.