Hiding relevant info behind "..." all over the post is annoying. Instead of reading through it like normal one has to read and click those little dots a dozen times. I'll save you the trouble: - Even if you choose not to back up your chats, someone you are talking to can do it, and your messages to them will be saved in their backup. - 100 MiB of message storage is free. - Last 45 days of media storage is free. - Bey…
Signal Secure Backups
441–450 of 460 posts
Re: Signal Secure Backups
#442Earlier quoted context omitted.
Signal never syncs old messages on secondary clients for security reasons.
They do. They also offer to do it when you link your desktop client, and like I said, it works on Linux but gives an error message on Windows. Also, considering that linking requires access to your existing device I don't see an issue with that. Moxie himself considered usability to be more important than tinfoil hat-level crypto because large-scale adoption is what enables security.
The limitation is that only message history from the past 45 days would be synced. If this has changed recently to allow syncing all message history, I’d be thrilled!
Re: Signal Secure Backups
#443It's a real shame they aren't implementing this on iOS in beta before the new iPhone launch. Android has had backups for a long time, just locally. iOS users have been SOL so if anything goes wrong with the transfer and sync on your new phone, you're screwed.
Signal has done a very poor job of calling out that you can optionally connect your old and new phone via cable; the transfer will be much more stable and quick. (No, this does not really help if you're one of the TouchID holdouts on an older SE)
Re: Signal Secure Backups
#444Earlier quoted context omitted.
I built a micro-journaling app back in the day and wanted it to be highly secure. Backups seemed to be one of the most vulnerable surfaces for that. I imagine their delay might have been a combination of a technological and ideological worries, as that's what I experienced.
How did you encrypt the data at rest and why was that also not good for the backup?
I suppose now i could do some combination of PIN plus passkey, and have to figure out how to make the database recoverable if people forget their PIN (or lose their passkey?) without me having to store it for them or it being easy to access.
I'm no expert on this, just think the complexity can be a lot more when taking this all into consideration.
Re: Signal Secure Backups
#445Earlier quoted context omitted.
> you are asking for a new feature I think we have vastly different definitions of what is a "new" feature. This is not about adding a new feature, but removing an old bug. > If they want to offer you a way to still enable it, someone has to do it. They can just use the iOS system settings to allow users to enable/disable backups. This would be zero code needed. Zero maintainability problems. Zero UX. Zero unexpected…
I understand that you are frustrated. And I understand that if you were to write Signal, you would do it differently. Still, those 20 lines don't look like a bug to me. And Signal does not benefit from pissing you off. I was just trying to say that maybe, just maybe, there is a valid reason behind this.
As an example, a piece of code sending authentication credentials in plain text across the internet might in isolation be considered free of bugs. But it should never do that to begin with, it should have been designed/architected quite a bit differently.
You are free to carry water for Signal while they repeatedly refuse to even explain why they consider this a valid approach to handle the users data.
Re: Signal Secure Backups
#446Earlier quoted context omitted.
I was not talking about a security flaw. I was saying that maybe , Signal did not want to push their users to trust the Apple backup by default. Signal is a nonprofit foundation, it's not like they are trying to squeeze their users with their own secure backup.
> I was saying that maybe, Signal did not want to push their users to trust the Apple backup by default. The gap in understanding here is that Signal already trusts iOS by providing an app. It trusts it even more by providing notifications (with sender and content) that go through Apple’s systems. It integrates with CallKit to work with the Phone app. Putting iCloud alone in a separate bucket doesn’t make sense. They…
Again: they could have, but it would have taken time and resources. The complaint here is not that Signal doesn't want to allow backups: they are just announcing a secure backup feature.
The complaint is that Signal did not do it earlier, and instead decided to prevent what they considered an insufficient solution.
> Putting iCloud alone in a separate bucket doesn’t make sense.
Of course it makes sense. What you say is akin to saying "end to end encryption makes no sense, because if you have to trust iOS anyway, you may as well trust the server".
Because I trust Android and run Signal there does not mean that I want it to auto-upload my messages to Google Drive. I don't see what makes it so hard to understand.
> One can only hope that the point about supporting other backup endpoints/storage gets implemented sooner rather than having to wait several more years.
Yes, I hope that too. On top of hoping, one could donate, to slightly contribute to paying the developers that work on it.
Re: Signal Secure Backups
#447Earlier quoted context omitted.
I understand that you are frustrated. And I understand that if you were to write Signal, you would do it differently. Still, those 20 lines don't look like a bug to me. And Signal does not benefit from pissing you off. I was just trying to say that maybe, just maybe, there is a valid reason behind this.
The bug is not in the detailed implementation of the code logic per se, the bug is that it causes unexpected data loss because iOS users expect all their data to be backed up when they back up all their important data. As an example, a piece of code sending authentication credentials in plain text across the internet might in isolation be considered free of bugs. But it should never do that to begin with, it should h…
> As an example, a piece of code sending authentication credentials in plain text across the internet might in isolation be considered free of bugs.
This is not a good example. It's almost certainly a security issue. Unless you have a threat model where you absolutely don't give a shit about it, but we're not in 2010 anymore. Let me try to make another one:
As an example, a messenging app sending encrypted but not end-to-end encrypted messages over a server may be considered free of bugs. Adding end-to-end encryption to it would be a new feature, and it may well be out of scope for that particular app (ever heard of Telegram?).
Because you really want it doesn't make it a bug.
Re: Signal Secure Backups
#448Earlier quoted context omitted.
I must have been living under a rock, I didn't know that. So you're saying that I can buy a cheap eSIM for just a couple weeks in a country? Don't they require to verify my identity and all that?
Identity verification depends on the country. In certain cases there may be limitations. There are many eSIM sellers, like Airalo, Jetpac, Saily, Holafly and more. You can buy the eSIM with an eSIM package (for data, mostly, but some also sell voice/SMS) for a country or region, activate it (or wait for it to activate when the phone connects to a local network at the destination) and use it. It’s so simple and conven…
Re: Signal Secure Backups
#449Earlier quoted context omitted.
The bug is not in the detailed implementation of the code logic per se, the bug is that it causes unexpected data loss because iOS users expect all their data to be backed up when they back up all their important data. As an example, a piece of code sending authentication credentials in plain text across the internet might in isolation be considered free of bugs. But it should never do that to begin with, it should h…
"I consider it a bug because I really want this feature" does not change the fact that it is a feature. > As an example, a piece of code sending authentication credentials in plain text across the internet might in isolation be considered free of bugs. This is not a good example. It's almost certainly a security issue. Unless you have a threat model where you absolutely don't give a shit about it, but we're not in 20…
It's newspeak all in the software world. A first for everything I suppose.
Re: Signal Secure Backups
#450> alongside features that let you transfer your encrypted message history between Android, iOS, and Desktop devices. That's actually the feature I've been looking forward to. As I moved vom Android to iOS, I lost _all_ message histories from all messenger apps that use E2EE (Signal, WhatsApp, Threema, etc). The only one that "just worked" was Telegram due to not being encrypted. WhatsApp had a migration app that has…
I've always been able to transfer history, from Android phone to Android phone, when I switched to iOS, I didn't bother since my wife was just going to start using Messages due to its encrypted nature. I really only used Signal with my wife, she only used it because I was using it and it allowed us to send images back and forth without losing quality.
Signal does lossy compression on images. You can change image quality from “Standard“ to “High“ in its settings but not disable it.