[akerl_]

There's no future-proof suggestion that's immune to the government declaring it a crime.

If you want a suggestion for secure messaging, it's Signal/WhatsApp. If you want to LARP at security with a handful of other folks, GPG is a fine way to do that.

[goldsteinq]

> If you want a suggestion for secure messaging, it's Signal/WhatsApp. If you want to LARP at security with a handful of other folks, GPG is a fine way to do that.

I want secure messaging, not encrypted SMS. I want my messages to sync properly between arbitrary number of devices. I want my messaging history to not be lost when I lose a device. I want not losing my messaging history to not be a paid feature. I want to not depend on a shady crypto company to send a message.

[tptacek]

I seriously don't care what messenger you use, as long as it isn't email, which can't be made secure. Pick something open source. It'll be less secure than Signal, but way more secure than email.

[Natanael_L]

Then your next best bet is Matrix.org. Not to the same security standard as Signal, but if you don't have a specific threat against you then it's fine.

[goldsteinq]

Pros of Matrix: it actually has a consistent history (in theory); no vendor lock-in. Cons of Matrix: encryption breaks constantly. Right now I’m stuck in a fun loop of endlessly changing recovery keys: https://github.com/element-hq/element-web/issues/31392

[Arathorn]

bleurgh. that issue is very actively under investigation (modulo xmas). please can you submit debug logs from Element Web referencing that issue.

[goldsteinq]

I’m facing it on Element Desktop, but I’ll try to reproduce it on Element Web. I’ve tried to submit logs from Element Desktop, but it says that `/rageshake` (which I was told to do) is not a command. I’m happy to help with debugging this, but I’m not sure how to submit logs from Desktop.

Something like this happens basically every time I try to use Matrix though. Messages are not decrypting, or not being delivered, or devices can’t be authenticated for some cryptic reason. The reason I even tried to use Element Desktop is because my nheko is seemingly now incapable of sending direct messages (the recepient just gets infinite “waiting for message”).

[Arathorn]

Weird. Encryption these days (in Element Web/Desktop and Element X at least) should be pretty robust - although this whole identity reset thing is a known bug on Element Web/Desktop. You can submit debug logs from Settings: Help & About: Submit Debug Logs, and hopefully that might give a hint on what's going wrong.

[some_furry]

> I want secure messaging, not encrypted SMS.

I send long messages via Signal, typed on a desktop computer, all the time. (In fact, I almost exclusively use Signal through my desktop app.)

You don't have to use it like "encrypted SMS"! You're free.

> I want my messages to sync properly between arbitrary number of devices. I want my messaging history to not be lost when I lose a device.

OK. https://signal.org/blog/a-synchronized-start-for-linked-devi...

> I want not losing my messaging history to not be a paid feature.

I genuinely don't understand what you mean here. From https://signal.org/blog/introducing-secure-backups/

"If you do decide to opt in to secure backups, you’ll be able to securely back up all of your text messages and the last 45 days’ worth of media for free."

If you have a metric fuckton of messages, that does cost money, sure, but as they say:

"If you want to back up your media history beyond 45 days, as well as your message history, we also offer a paid subscription plan for US$1.99 per month."

"This is the first time we’ve offered a paid feature. The reason we’re doing this is simple: media requires a lot of storage, and storing and transferring large amounts of data is expensive. As a nonprofit that refuses to collect or sell your data, Signal needs to cover those costs differently than other tech organizations that offer similar products but support themselves by selling ads and monetizing data."

If you want Signal to host the encrypted storage, that costs money. If you don't want to pay Signal money, they provide 45 days of backup for free.

If you want to self-host your own backups (at your own cost), that's easy to do.

https://imgur.com/a/EIfaIee

You can literally set up SyncThing to stream your on-device backups to your NAS, cloud storage, or whatever.

> I want to not depend on a shady crypto company to send a message.

Shady crypto company?

Are you referring to MobileCoin? That feature isn't in the pipeline for sending messages.

I checked! https://soatok.blog/2025/02/18/reviewing-the-cryptography-us...

[goldsteinq]

> You don't have to use it like "encrypted SMS"! You're free.

Using it as something more than encrypted SMS requires persistent message history between devices.

> metric fuckton of messages

“More than 45 days” is a metric fuckton? Seriously?

> If you want Signal to host the encrypted storage, that costs money. If you don't want to pay Signal money, they provide 45 days of backup for free.

I don’t want Signal to store my messages. I want Signal to not lock in my messages on their servers, so I can sync them between my devices and back them up into my own backups.

> If you want to self-host your own backups (at your own cost), that's easy to do.

Except there’s no way to move it between platforms. I have more than one device.

> Are you referring to MobileCoin? That feature isn't in the pipeline for sending messages.

I don’t want shady crypto company to hold my data hostage, and there’s no way to store it on my hardware and then move it between platforms. That’s my problem with signal.

> A Synchronized Start for Linked Devices

It only properly transfers 45 days. You can’t have more than one phone. Phones are special “primary devices” and AFAIK you can’t restore your messages if you lose your phone even if you have logged-in Signal Desktop.

[some_furry]

I literally included a screenshot that shows you can setup backups in a directory on your device and then use your own backup solution.

Signal is not holding you hostage.

[goldsteinq]

Yes, if your only device is a single Android phone you can do that. You can’t, however, use that backup to populate your message history on other platforms.

I’ve already lost message history consistency because one of my devices was offline for too long. The messages are there on my other device, but Signal refuses to let me copy my data from one of my devices to another. Signal is, quite literally, worse at syncing message history than IRC — at least with IRC I can set up a bouncer and have a consistent view of history on all of my devices, but there’re no Signal bouncers.

[tptacek]

Look, if defending "message history consistency" is a reason you're choosing some other secure messenger rather than Signal, then I don't think this argument is very productive; use some other secure messenger then. But if "message history consistency" is a reason you're endorsing encrypted email over Signal, you're committing malpractice.

The point is that whatever secure messenger you use, it must plausibly be secure. Email cannot plausibly be made secure. Whatever other benefits you might get from using it --- federation, open source, UX improvements, universality --- come at the cost of grave security flaws.

Most people who use encrypted email are doing so in part because it does not matter if any of their messages are decrypted. They simply aren't interesting or valuable. But in endorsing a secure messenger of any sort, you're influencing the decisions of people whose messages are extremely sensitive, even life-or-death sensitive. For those people, federation or cross-platform support can't trump security, and as practitioners we are obligated to be clear about that.

[jhgb]

Nobody decided that it's a crime, and it's unlikely to happen. Question is, what do you do with mandatory snooping of centralized proprietary services that renders them functionally useless aside from "just live with it". I was hoping for actual advice rather than a snarky non-response, yet here we are.

[Fnoord]

> Nobody decided that it's a crime, and it's unlikely to happen.

Which jurisdiction are you on about? [1] Pick your poison.

For example, UK has a law forcing suspects to cooperate. This law has been used to convict suspects who weren't cooperating.

NL does not, but police can use force to have a suspect unlock a device using finger or face.

[1] https://en.wikipedia.org/wiki/Key_disclosure_law

[closewith]

You're asking for a technical solution to a political problem.

The answer is not to live with it, but become politically active to try to support your principles. No software can save you from an authoritarian government - you can let that fantasy die.

[akerl_]

I gave you the answer that exists: I'm not aware of any existing or likely-to-exist secure messaging solution that would be a viable recommendation.

The available open-source options come nowhere close to the messaging security that Signal/Whatsapp provide. So you're left with either "find a way to access Signal after they pull out of whatever region has criminalized them operating with a backdoor on comms" or "pick any option that doesn't actually have strong messaging security".

[johnisgood]

> messaging security

> WhatsApp

Eh?

There are alternatives, try Ricochet (Refresh) or Cwtch.

[akerl_]

I stand by what I said.

[johnisgood]

I mean... why?

[closewith]

Not the GP, but most of us want to communicate with other people, which means SMS or WhatsApp. No point have perfect one-time-pad encryption and no one to share pads with.

[signed-log]

Most countries will throw you in jail for years if you refuse to give the password to encrypted devices they want. [1]

And that's even if you are innocent on the underlying charge or search.

Encryption in this political climate, is a pick your poison.

- Either you go to jail for years but you know your gov and other actors has no access to your data.

- or you store on remote/proprietary apps, stay free, but your gov or other actors may or may not have access to it.

[1]: https://en.wikipedia.org/wiki/Key_disclosure_law

[anonym29]

Could you please link the source code for the WhatsApp client, so that we can see the cryptographic keys aren't being stored and later uploaded to Meta's servers, completely defeating the entire point of Signal's E2EE implementation and ratchet protocol?

[akerl_]

This may shock you, but plenty of cutting-edge application security analysis doesn't start with source code.

There are many reasons, but one of them is that for the overwhelming majority of humans on the planet, their apps aren't being compiled from source on their device. So since you have to account for the fact that the app in the App Store may not be what's in some git repo, you may as well just start with the compiled/distributed app.

[anonym29]

Whether or not other people build from source code has zero relevance to a discussion about the trustworthiness of security promises coming from former PRISM data providers about the closed-source software they distribute. Source availability isn't theater, even when most people never read it, let alone build from it. The existence of surreptitious backdoors and dynamic analysis isn't a knock against source availability.

Signal and WhatsApp do not belong in the same sentence together. One's open source software developed and distributed by a nonprofit foundation with a lengthy history of preserving and advancing accessible, trustworthy, verifiable encrypted calling and messaging going back to TextSecure and RedPhone, the other's a piece of proprietary software developed and distributed by a for-profit corporation whose entire business model is bulk harvesting of user data, with a lengthy history of misleading and manipulating their own users and distributing user data (including message contents) to shady data brokers and intelligence agencies.

To imply these two offer even a semblance of equivalent privacy expectations is misguided, to put it generously.

[tptacek]

These are words, but I don't understand how they respond to the preceding comment, which observes that binary legibility is an operational requirement for real security given that almost nobody uses reproducible builds. In reality, people meaningfully depend on work done at the binary level to ensure lack of backdoors, not on work done at the source level.

The preceding comment is saying that source security is insufficient, not that transparency is irrelevant.

[anonym29]

Source availability is what makes a chain of trust possible that simply isn't meaningfully possible with closed source software, even with dynamic analysis, decompilation, reverse engineering, runtime network analysis with TLS decryption, etc.

Both you and the preceding commenter are correct that just running binaries signed and distributed by Alphabet (Google) and/or Apple presents room for additional risks beyond those observable in the source code, but the solution to this problem isn't to say "and therefore source availability doesn't matter at all for anyone", it's to choose to build from source or to obtain and install APKs built and signed by the developers, such as via Accrescent or Obtanium (pulls directly from github, gitlab, etc releases).

There's a known-good path. Most people do not take the known-good path. Their choice to do so does not invalidate or eliminate the desirable properties of known-good path (verifiability, trustworthiness).

I genuinely do not understand the argument you and the other user are making. It reads to me like an argument that goes "Yes, there's a known, accurate, and publicly documented recipe to produce a cure for cancer, but it requires prerequisite knowledge to understand that most people lack, and it's burdensome to follow the recipe, so most people just buy their vials from the untrustworthy CancerCureCorporation, who has the ability to give customers a modified formula that keeps them sick rather than giving them the actual cure, and almost nobody makes the cure themselves without going through this untrustworthy but ultimately optional intermediary, so the public documentation of the cure doesn't matter at all, and there's no discernable difference between having the cure recipe and not having the cure recipe."

[tptacek]

No, you're completely off the rails from the first sentence. It is absolutely possible --- in some ways more possible[†] --- to make a chain of trust without source availability. Your premise is that "reverse engineering" is somehow incomplete or lossy with respect to uncovering software behavior, and that simply isn't true.

[†] Source is always good to have, but it's insufficient.

[akerl_]

> but the solution to this problem isn't to say "and therefore source availability doesn't matter at all for anyone"

Thankfully, I didn’t say that.