What are the reasons to use Signal over Telegram

[logging_strict@lemmy.ml]

The real world, with non-tech people needs solutions that are easy, fast and as close to foolproof as possible.

Nope. Grandma gets a smartphone

Meaning they are hopeless and it's impossible for them to emulate a techie.

It's a fools errand.

Just stop trying to pretend Grandma is something more than completely unimportant and forgettable and hopeless and more likely than not merely a pest.

I'm so tired of entertaining Grandmas.

[logging_strict@lemmy.ml]

I was sold on threats and coersion. Lets do more of that

[bazoogle@lemmy.world]

Hopefully you aren't driving any buses while you're this high.

It's not never ending red flags. In fact, I see lots of green flags from signal. Telegram, though, that's a different story.

[logging_strict@lemmy.ml]

Then talk about coding. Non-techies curl up into a ball and die slightly inside as they run for the exits.

Highest form of encryption possible.

Try it

[logging_strict@lemmy.ml]

You are right but

we like doing the wrong thing over and over again. And being surprised, each and every time, when it turns out to be wrong. Never picking up onto the repeating simple pattern.

1111111111111 what's the next number ... errrr Signal! That's it you got it. Good job.

Embrace the idiocracy!

This is why Telegram is awesome.

Eventually you will come around and realize how hopeless humanity is and embrace that it is well beyond hope.

And then you will have a larger network and enjoy each and every one of them.

[anarchistartificer@lemmy.world]

That's a neat trick, thanks for sharing

[hedgehog@ttrpg.network]

Also read that the keys are stored locally but also somehow stored in the cloud (??),

Which keys? Are they always stored or are they only stored under certain conditions? Are they encrypted as well? End to end encrypted?

which makes it all completely worthless if it is true.

It doesn’t, because what you described above could be fine or could have huge security ramifications. As it is, my guess is that you’re talking about how Signal supports secure value recovery. In that case:

1. The key is used to encrypt your contacts, profile name, group avatars, social graph, etc., but not your messages.
2. Your key is only uploaded to the cloud if you have a recovery PIN or passphrase
3. Your key is encrypted using your PIN or passphrase using techniques (key-stretching, storing in server secure enclaves) that make it more difficult to brute force

The main criticism of this is that you can’t opt out of it without opting out of the Registration Lock, that it necessarily uses the same PIN or passphrase, and that, particularly because it isn’t clear that your PIN/passphrase is used for encryption, users are less likely to use more secure pass phrases here.

But even without the extra steps that we can’t 100% confirm, like the use of the Secure Enclave on servers and so on, this is e2ee, able to be opted out by the user, not able to be used to recover past messages, and not able to be used to decrypt future messages.

[hedgehog@ttrpg.network]

Message history won’t be fully fixed. It can’t be without storing message backups in some cloud somewhere (whether it’s to iCloud, Google Drive, Dropbox, or Signal’s servers) and Signal omits its message history from system backups on iOS and Android.

iOS users are completely incapable of backing up their message history in the event of their phone being lost, stolen, or broken. This omission isn’t justified in any way, as far as I’m aware; I don’t know of any technical reason why following the exact same process as on Android wouldn’t work.

Android users are able to back up locally via Signal, but that isn’t on by default, can’t be automated, needs to be backed up separately, requires you to record a 30 digit code to decrypt it, and has limitations on when it can be used for a restore (can’t restore on iOS, for example). See https://support.signal.org/hc/en-us/articles/360007059752-Backup-and-Restore-Messages for more details.

Message history on linked devices - meaning iPads and desktop computers - is being improved, but it still won’t mean that a user who loses or trades in their phone as they get a new phone will be able to simply restore their phone from a system backup and restore their Signal message history. And even that isn’t anywhere near as easy as on Telegram, where a user can just log in with their password and restore their message history, no backup needed.

It’s great that they’re improving the experience for linked devices, but right now that doesn’t actually help if you lose, break, or trade in your phone. Maybe they’ll later allow users to restore to a phone from a linked device or support backups on iPhones, but right now the situation with message history isn’t just an unfriendly UX, but one that is explicitly and intentionally unreliable for a huge portion of Signal’s user-base.

[logging_strict@lemmy.ml]

Your welcome. Use it in good health. And please excuse my colorful prose.

There is many many comments on Telegram bleeding the phone number. And only one comment saying that doesn't have to be the case.

[logging_strict@lemmy.ml]

i'm a milk tea addict. Carry around cinnamon and nutmeg. And hang out on github.

These are horrible vices. But no excuse for having divergent opinions.

Telegram is fine.

Signal will be gone tomorrow and you'll lose your network. Moving networks from one platform to another is impossible. So we end up creating new networks.

Currently i'm making a network of Python coders i've collaborated with. The communication medium is not consistent nor ideal.

Hate email with a passion. So of course most the communication is going over plain text email. Tried pushing for communication on plain text mastodon.

[aria@lemmygrad.ml]

Okay. But this method doesn't address that the service doesn't need the message to include the sender to know who the sender is. The sender ('s unique device) can with 100% accuracy be appended to the message by the server after it's received. Even if we trust them on the parts that require trust, the setup as described by the blog doesn't do anything to prevent social graphs from being derived, since the sender is identified at the start of every conversation.

If we trust them not to store any logs (unverifiable), then this method means they can't precisely know how long a conversation was or how many messages were exchanged. But you can still know precisely when and how many messages both participants received, there's just a chance that they're talking to multiple people. Though if we're trusting them not to store logs (unverifiable), then there shouldn't be any data to cross reference to begin with. So if we can't trust them, then why are we trusting them not to take note of the sender?

The upside is that if the message is leaked to a third-party, there's less info in it now. I'm ignoring the Github link, not because I don't appreciate you finding it, but because I take the blog-post to be the mission statement for the code, and the blog doesn't promise a system that comprehensively hides the sender's identity. I trust their code to do what is described.