… and I can’t even continue the chat from my phone.
Signal is Electron (Chromium + NodeJS) + Signal app code and assets. So not suprised that it’s bigger than Chromium.
Source: https://github.com/signalapp/Signal-Desktop/blob/main/package.json#L294
For the most part, I don’t care about App Size. Storage is cheap. What I miss with the Signal Desktop App is the option to save everything in an encrypted container.
Same. I’ve seen the alternative called dependency hell too often… Yes, you can.share stuff between apps, but then, versioning is a nightmare.
Wouldn’t having full disk encryption achieve most of the benefits of that? In case of someone having access to your unlocked machine what is stopping them from launching the app and looking though it?
Yes, full disk encryption helps against intruders with device access, but not against the files being indexed by other application. My phone is encrypted, but I still use a signal client that is encrypted again.
Am encrypted container doesn’t help if the directory is mounted and accessible or if the key is in plaintext. Also doesn’t help if the process isn’t isolated. You need a bunch of extra measures like using the OS keystore set to only allow the correct program to retrieve the key, keeping secrets only in process memory, etc.
Tldr it’s a lot of work to do it right. If you do it the simple way like throwing it all in SQLite with encryption active you still leak metadata.
I have never worked on a properly hardened desktop app, so I don’t have much of a perspective on that, and can definitely see that it might not be worthwhile for the signal team.
I would appreciate some level of encryption, thinking that it might help with less targeted attacks. I’d also appreciate a Web client, like Threema’s with none permanent sessions. But all that’s, as you’d say in German, “Meckern auf hohem Niveau”, especially since I’m not currently contributing to Signal.
Hm, but wouldn’t such an application be malicious by default? Having protection against attackers on your device seems of out scope for a messaging application, at that point I would consider something like Tails. Though this may be a rare case when moving to an appimage could help matters.
Yes and no. I personally would like to be asked permission for such behaviour, but a gallery application, for example, could have legitimate reasons to index all photos on your system. I personally prefer to manually set the folders it is supposed to index, but that doesn’t seem to be a generally accepted paradigm.
In general, I see why you need to trust that a system your app runs on is uncompromised to a a certain degree, but measures to potentially limit harm in case it is still seem sensible, especially for an app with a focus on privacy and security.
We set the threshold of sensible protections provided by the app (signal) itself differently.
On desktop having a gallery app, as you say, or running an application like windirstat for example I expect the user to understand that anything stored on device can be “seen” by the app and that, if they dont trust it, having sensitive files deleted or sandboxed might be prudent. Messages are stored at least somewhat encrypted (albeit with the key in a config file) so a random (non targeted/malicious) scan would gt blobs there.
On mobile due to how opaque the os is I am thankful for the extra encyption and I would consider it a much more critical flaw. On desktop less so. Still I appreciate your point of view and a passkey to encrypt at least messages on the desktop app would be a welcome addition.
While I’m on the subject, Signal’s phone UI is not great. Most screens severely lack contrasting colors and borders. Font size and spacing is inconsistant. It is hard and unpleasant to read - that’s kind of unfortunate for an app focused on reading and writing text.
Why would you not be able to continue chat from the phone? I don’t all the time.
Unclear if unintented funny typo, or intended funny comment.
Totally a typo lol
I think OP refers to the first install/link. It is a feature that previous conversations are not shown when you do a fresh client link.
https://support.signal.org/hc/en-us/articles/360007320551-Linked-Devices
Debian Linux installation ISO is only 336 MB, FFS. And that’s a whole operating system with user land!
No, that’s a tarball of a kernel, basic command line tools, apt and a network stack that lets you download most of the operating system.
Um, no? The 336 megabyte usb installation media contains everything you need to install base Debian. Most people will want a desktop environment and other packages, they can connect to the network to download those additional packages.
Even the how-to says the network is optional.
https://www.debian.org/releases/stable/amd64/ch02s04.en.html#idm368
ignoring the fact that it’s absolutely horrid.
An install of ICUE on windows takes up multiple gigabytes. Why? Uhm, good question.
they just went dd if=/dev/urandom count=1 bs=1G of=./ICUEAppData
three times over, no less.
Yeah, I’ve been having a lot of issues with Electron which is basically a browser emulator. It has gotten huge, so applications using it have gotten out of control in size. I get that it’s a quick way to build a cross platform application, but there really needs to either be a better way to distribute it that is more modular, or people need to start building on better cross platform front-end systems.
and it also runs like shit too.
i am doing a full system upgrade and something wants to build chromium from source. i let it run in the background and cloning the repository alone has downloaded 33GB wtf 😭
Yeah, I had to move away from Arch Linux because lots of apps you have to build and Electron was one of the biggest culprits for using tons of disk space and time because it builds Chromium in its entirety from source. Electron is a great way to shift the cost of cross platform development from you to your customers.
The unability to continue chat from phone is a feature.
What does this mean? I use my phone and computer, and they sync up in real-time without any issues.
Okay, but can’t it be an optional feature? I’d like it if a new device could download message history from an old device by having both online at the same time.
Optional how so? It’s a rotating key. Unless you have all of those keys to export into your computer, then you’ll be stuck with the current synced key.
You can still push old message history from your main device to your other devices, you can re-encrypt
No shit. I’ll need to look into this. Thanks for learning me up.
I don’t see why the current key can’t encrypt old messages and send those. I admit I might be missing something obvious though. Maybe something like not wanting to accidentally leak old messages? As in it’s less attack surface or something?
New messages will show on all your devices, but yes, it is intentional that old messages are not available to new devices.
This is because they don’t retain your (encrypted) messages on their servers right? Is this for storage reasons, or more just security philosophy of not being able to access past chats when you login from elsewhere?
This is not entirely correct. Messages are stored on their servers temporarily (last I saw, for up to 30 days), so that even if your device is offline for a while, you still get all your messages.
In theory, you could have messages waiting in your queue for device A, when you add device B, but device B will still not get the messages, even though the encrypted message is still on their servers.
This is because messages are encrypted per device, rather than per user. So if you have a friend who uses a phone and computer, and you also use a phone and computer, the client sending the message encrypts it three times, and sends each encrypted copy to the server. Each client then pulls its copy, and decrypts it. If a device does not exist when the message is encrypted and sent, it is never encrypted for that device, so that new device cannot pull the message down and decrypt it.
For more details: https://signal.org/docs/specifications/sesame/
That’s for your insightful comment. I’m now going down the rabbit hole of the signal spec :)
Correct
But if I reply on the phone will it populate the desktop chat and vice versa?
Yes, as long as you set up the desktop client before sending the message.
Messages sent with Signal are encrypted per device, not per user, so if your desktop client doesn’t exist when the message is sent, it is never encrypted and sent for that device.
When you set up a new client, you will only see new messages.
See https://signal.org/docs/specifications/sesame/ for details.
Cool, could I recover a backup to te desktop to have access to the historical ones?
Signal Desktop does not support transferring message history to or from any device.
Yes
The chat continues on all linked devices from the point in time that they are linked.
Imagine two people having a face-to-face conversation, then a third person walks up and joins in. The third person doesn’t know what was said before they joined the conversation, but all three continue the conversation from that point on.
Linked devices are like the above example, if two of those people were married and tell each other every conversation they’ve had since their wedding.
There is no sharing of messages between linked devices - that would break forward secrecy, which prevents a successful attacker from getting historical messages. See the first bullet of: https://support.signal.org/hc/en-us/articles/360007320551-Linked-Devices
Messages are encrypted per device, not per user (https://signal.org/docs/specifications/sesame/), and forward secrecy is preserved (https://en.m.wikipedia.org/wiki/Forward_secrecy, for the concept in general, and https://signal.org/docs/specifications/doubleratchet/ for Signal’s specific approach).
Message logs doesn’t break forward secrecy in a cryptographic sense, retaining original asymmetric decryption keys (or method to recreate them) does. Making history editable would help against that too.
What Signal actually intends is to limit privacy leaks, it only allows history transfer when you transfer the entire account to another device and “deactivate” the account on the first one, so you can’t silently get access to all of somebody’s history
You’re describing something very different - you already have the messages, and you already have them decrypted. You can transfer them without the keys. If someone gets your device, they have them, too.
Whether Signal keeps the encrypted the messages or not, a new device has no way of getting the old messages from the server.
I run a cryptography forum, I know the exact definition of these terms. Message logs in plaintext is very distinct from forward secrecy. What forward secrecy means in particular is that captured network traffic can’t be decrypted later even if you at a later point can steal the user’s keys (because the session used session keys that were later deleted). Retrieving local logs with no means of verifying authenticity is nothing more than a classical security breach.
You can transfer messages as a part of an account transfer on Signal (at least on Android). This deactivates the app on the old device (so you can’t do it silently to somebody’s device)
There is no reason why the message sync that works from phone to phone could not be implemented on the desktop client as well.
Does it work phone to phone? I was under the impression that a backup restore was needed if you wanted previous messages. It’s really an unnecessary security risk to have previous message sync. Someone gets your phone in their hand for 20 seconds, links your device and they get every message you have ever sent? No bueno.
You can sync messages from phone to phone. https://support.signal.org/hc/en-us/articles/360007059752-Backup-and-Restore-Messages#android_transfer
Inability.
Thanks
Unabilifiedness
After they dropped SMS support and called that a feature, now I can’t wait for their hottest new bug!
the solution could be deduplication, not sure if microsoft store has it, or windows supports it, this help with the size, bot not ram usage
Windows doesn’t support deduplication itself (though ntfs does support hardlinks if someone wanted to do it). It actually won’t help here because every electron app bundles different versions in practice.
Back in the day Signal was a Qt app, did that change?
Maybe you are thinking of Telegram?
I’m not sure of its past, this repo goes back 4 years, but Signal is electron https://github.com/signalapp/Signal-Desktop/tree/main
Well dooh, you installed Chrome with it. Add to that their application and there you have it.
even the phone app is larger than telegram and whatsapp
Such is the state of Electron.
I’m slowly stopping to care about web apps, however the amount of shit Electron causes is through the roof. Discord, Element, Signal, even Steam is full of it, so you just end up having 8 different “programs” running with every single one using at least around 400MB of RAM.
Can’t wait to see something using Rust and Tauri. Graphite wink winkI don’t know how other Linux distros do it, but Manjaro (and seemingly Arch) seem to carry
#packages separately from apps like Signal. Unfortunately, Element requires electron29 and Bitwarden electron28 so I still have two copies of Electron. BTRFS’ deduplication helps reduce the real world size a bit, but it’s still unfortunate, especially since electron31 is already out.Signal runs some security code natively so you can’t run it in the browser, even though most of the UI is done through a copy of Chrome. At least the reusable packages make it so that only one copy of Chrome will be loaded for all Electron applications!
RE: the RAM: a lot of that is space allocated for JIT. Most of it is filled with zeroes, so if you run a modern OS (recent Linux, Windows, macOS) that RAM will end up being compressed+CoW’d to the point of barely making a dent.
Plenty of optimisations to be done, but it’s not as bad as task manager may make it seem. I’ve personally replaced a bunch of web apps with Element by bridging everything through Matrix (Matrix alternatives such as XMPP can also do that with an even smaller footprint).
I use a whole bunch of Linux distros at work (CentOS, alpine, ubuntu, debian, opensuse) and a bunch on my devices at home (mint, fedora, nobara, and manjaro), and so far the only distro I’ve seen ship decoupled shared electron libs like you described is Manjaro (and presumably Arch).
Can’t wait to see something using Rust and Tauri.
What about sciter?
Steam is close but actually not electron, they use CEF - Chromium Embedded Framework which is something Electron uses too under the hood (afair)
Electron doesn’t use CEF, they directly bundle Chromium.
Thanks for the correction, appreciate it. Not sure it changes much though.
Steam used an embedded browser long before it was cool.
Of the apps you mentioned, I can use Discord and Element in my browser. WhatsApp even installs as a PWA. And Steam games can be launched through Lutris afaik?
There is no such option with Signal though.
Using an E2E chat app in your browser necessarily makes the keys and decrypted messages available to your browser. They would have the ability to read messages, impersonate users, alter messages, etc. It would defeat the purpose of a secure messaging platform.
I don’t get it. Who is “they”? Why can’t you fetch the encrypted message from the server and then decrypt it client side?
“They” is the browser/browser maker. The browser, acting as the client, would have access to the keys and data. The browser maker could do whatever they want with it.
To be clear, I’m not saying they would, only that it defeats the purpose of an E2E chat, where your goal is to minimize/eliminate the possibility of snooping.
You realize that your kernel which loads keys into memory can also access all this right? So can anything which shares memory space on the platform.
The bigger risk is browser exploits, not just who develops it. There’s more attack surface and more ways to exfiltrate data
I think the encrypted messages are not saved in the server. You probably have to backup from phone and restore it on pc. “They” is the other programs running on browser
With Discord in browser, you lose Krisp, RPC ipc socket support (aRPC might work, no clue), and from what I remember screensharing only worked with browser tab capture.
Element will eat your RAM no matter where it’s running. You could add it as a Nextcloud app to triple your RAM usage! Woo
And you can’t run Steam games without the Steam client running. That’s how their DRM works. (Unless you use the goldberg steam emulator, which is a whole another thing to talk about)
I really want to see the zygote approach worked out for electron. It’s working really well for android but with electron there are just too many different versions used by the different programs for that to make sense.
I wouldn’t mind so much if they all just used the same bundle of stuff, and you could install that once, and then the apps were all like 2MB each.
But no, big fucking bundle of shit, every single time.
Eh, that’s not the joy you think it is.
That’s how software used to be distributed and that’s where the terms DLL / Dependency Hell come from and why programs used to not uninstall cleanly and break other programs, etc.
It’s more efficient, but it’s also brittler and a lot more complex to manage. Conversely, bundling everything together with all its dependencies is a lot easier to manage, and a lot more robust overall, but comes at the expense of storage capacity and network bandwidth.
Signal’s desktop app is as horrendously unusably bad as the project as a whole is good, tbh.
It’s no wonder people prefer stuff like Telegram. It has native apps and all. Or can be used in a browser. Meanwhile Signal is only used in a browser, but you have to download it and it fucks up font scaling and it shits the bed on font antialiasing and it can’t even get UI design consistent with the OS it’s running on and it won’t even use the OS emoji font.
Let’s not even mention how you still cannot use Signal on a tablet.
Signal’s desktop app is as horrendously unusably bad
I think this is a bit dramatic. I’ve been using it for years, no problems.
And anytime you clicked on a link or image in the chat, you’ll have to click into the message field again (or press Ctrl+t) to be able to type a reply. I don’t understand how this absolutely infuriating thing hasn’t been fixed in years. Is nobody bothered by this? I want to be able to alt+tab into signal and just start typing ffs.
Yeah, I was going to say that I’ve used Signal on my Linux laptop and it’s janky af
Care to elaborate?
I use the app from the AUR and I don’t think I’ve had a single problem in 3 years.
telegram has an “advantage” of not having e2e encryption by default, which makes stuff like sync much easier as chats are fully stored on the server (encrypted with your user password).
and if you enable encryption (aka start a secret chat), the chat will only exist on the device you started it on and stop getting synced
The best version of the Signal app was back when it was available as an actual web app.
Given that they have a native, non-Electron iOS version, it’s a shame that they haven’t built a desktop macOS version using mostly the same code. (To make it look like a proper Mac app, they’d need different UI code, though even without that, they could build a version that looks like the iPad version with no changes, and it would look no worse than the Electron web-app UI and run an order of magnitude more efficiently.)
They don’t even need to built a separate app if they have an iPad app. they just need to not „not allow“ the execution on macOS.
On my phone is only 171mb.
And that’s also a lot for an app that doesn’t have that many binary assets like images or videos. I do wonder what makes up most of these sizes. I see other apps that are arguably more complicated - like AntennaPod - using under 40MB; So I guess it has to do with actual native apps vs cross platform ones.
“Only”
Your phone has bigger problems if it cannot take 170mb apps, this isn’t the 1990s
That’s a very bad way to look at things. Just because I have gigabytes of memory doesn’t mean I want to use unoptimized software.
And your way to look at things that “all apps must be 20 mb or less otherwise they are unoptimised” is better because?
Because optimized software is better for industry, people, and environment. Also seeing that some menu or window is not an html page but a native element makes my headache go away because I value my CPU cycles (seeing a cursor doesn’t lag when some complex page is displayed should not be considered a weird fetish) and like it when things don’t do stupid unnecessary stuff both visually and under the hood.
And it could be even less than that depending on specifics.
If developers optimized their apps, we could have phones that are 10x faster than 10 yeara ago. Instead they are the same speed and the same amount of apps fit in the bigger storage, because developers are lazy and use heavy, unoptimized technologies that use 10x the resources
They’re talking about the desktop application.
