... and I can't even continue the chat from my phone.
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 wink
Steam is close but actually not electron, they use CEF - Chromium Embedded Framework which is something Electron uses too under the hood (afair)
Thanks for the correction, appreciate it. Not sure it changes much though.
Steam used an embedded browser long before it was cool.
Electron doesn’t use CEF, they directly bundle Chromium.
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.
Would be kind of cool to allow people to choose an install method. As someone who has experienced low bandwidth in rural homes, it would be nice to avoid the waste at the cost of possibly managing chromium versions myself.
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.
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.
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)
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
Hey now, the three React Native for Windows apps would be very offended if they were stable enough to read text input.
It's because it's an electron app. So in addition to the chat app itself, it also includes a full Chromium runtime. Worse still, the Electron architecture doesn't really lend itself towards reusing electron itself; this means you might have several copies of the same version of electron on your machine for various apps.
People complain about the sizes of things like flatpaks and snaps, but tbh the whole architecture of applications is like this these days. Ironically, flatpaks and snaps could help with this because their formats can work decently with filesystem level deduplication.
wait till you meet Line 😶
The inability to continue chat from phone is a feature.
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.
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.
Signal Desktop does not support transferring message history to or from any device.
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.
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)
I would argue that it is not limited to network traffic, it is the general concept that historical information is not compromised, even if current (including long-term) secrets are compromised.
From my comment earlier:
There is no sharing of messages between linked devices - that would break forward secrecy
This describes devices linked to an account, where each is retrieving messages from the server - not a point-to-point transfer, which is how data is transferred from one Android device to another. If a new device could retrieve and decrypt old messages on the server, that would be a breach of the forward security concept.
Once again reminding you that I run a cryptography forum (I've done so for one 10 years, I keep up to date on the field) and it's a term defined by professional cryptographers.
Literally all definitions speak of network traffic and leaked / extracted encryption keys. PFS is about using short term keys that you delete so that they can not leak later.
Backup and sync via a separate mechanism is not a PFS violation. In particular because they're independent of that same encrypted session. It's entirely a data retention security issue.
Matrix.org supports message log backup via the server, and does so by uploading encrypted message logs and syncing the keys between clients. You can delete the logs later, or delete your keys, or even push fake logs if you want. It's still happening outside of the original encrypted session and the adversary can't confirm what actually was said in the original session.
I don't know why you think that PFS is broken if a local client has to be breached to recover encrypted data from a cloud backup, but PFS is not broken if a local client has to be breached to recover the same data from the client itself. Literally the only difference is where the data is stored, so either chat logs available to the client break PFS or they do not
You are conflating the concept and the implementation. PFS is a feature of network protocols, and they are a frequently cited example, but they are not part of the definition. From your second link, the definition is:
Perfect forward secrecy (PFS for short) refers to the property of key-exchange protocols (Key Exchange) by which the exposure of long-term keying material, used in the protocol to authenticate and negotiate session keys, does not compromise the secrecy of session keys established before the exposure.
And your third link:
Forward secrecy (FS): a key management scheme ensures forward secrecy if an adversary that corrupts (by a node compromise) a set of keys at some generations j and prior to generation i, where 1 ≤ j < i, is not able to use these keys to compute a usable key at a generation k where k ≥ i.
Neither of these mention networks, only protocols/schemes, which are concepts. Cryptography exists outside networks, and outside computer science (even if that is where it finds the most use).
Funnily enough, these two definitions (which I'll remind you, come from the links you provided) are directly contradictory. The first describes protecting information "before the exposure" (i.e. past messages), while the second says a compromise at j cannot be used to compromise k, where k is strictly greater than j (i.e. a future message). So much for the hard and fast definition from "professional cryptographers."
Now, what you've described with matrix sounds like it is having a client send old messages to the server, which are then sent to another client. The fact the content is old is irrelevant - the content is sent in new messages, using new sessions, with new keys. This is different from what I described, about a new client downloading old messages (encrypted with the original key) from the server. In any case, both of these scenarios create an attack vector through which an adversary can get all of your old messages, which, whether you believe violates PFS by your chosen definition or not, does defeat its purpose (perhaps you prefer this phrasing to "break" or "breach").
This seems to align with what you said in your first response, that Signal's goal is to "limit privacy leaks," which I agree with. I'm not sure why we've gotten so hung up on semantics.
I wasn't going to address this, but since you brought it up twice, running a forum is not much of a credential. Anyone can start a forum. There are forums for vaxxers and forums for antivaxxers, forums for atheists and forums for believers, forums for vegans and forums for carnivores. Not everyone running these forums is an expert, and necessarily, not all of them are "right." This isn't to say you don't have any knowledge of the subject matter, only that running a forum isn't proof you do.
If you'd like to reply, you may have the last word.
Neither of these mention networks, only protocols/schemes, which are concepts. Cryptography exists outside networks, and outside computer science (even if that is where it finds the most use).
This is ridiculous rules lawyering and isn't even done well. Such schemes inherently assume multiple communicating parties. Sure you might not need to have a network but you still have to have distinct devices and a communication link of some sort (because if you have a direct trusted channel you don't need cryptography)
You're also wrong about your interpretation.
Here's how to read it:
At point A both parties create their long term identity keys.
At point B they initiate a connection, and create session encryption keys with a key exchange algorithm (first half of PFS)
At point C they exchange information over the encrypted channel.
At point D the session keys are automatically deleted (second half of PFS)
At point E the long term key of one party is leaked. The contents from B and C can not be recovered because the session key is independent of the long term key and now deleted. This is forward secrecy. The adversary can't compromise it after the fact without breaking the whole algorithm, they have to attack the clients as the session is ongoing.
This is motivated for example by how SSL3.0 usually was used with a single fixed RSA keypair per server, letting user clients generate and submit session encryption keys - allowing a total break of all communications with the server of that key is comprised. Long term DH secrets were also often later used when they should be single use. Then we moved on to ECDH where generating new session secrets is fast and everybody adopted real PFS.
Yes compromising the key means you often get stuff like the database too, etc. Not the point! If you keep deleting sensitive data locally when you should then PFS guarantees it's actually gone, NSA can't store the traffic in their big data warehouse and hope to steal the key later to decrypt what you thought you deleted. It's actually gone.
And both of the above definitions you quoted means the same as the above.
In any case, both of these scenarios create an attack vector through which an adversary can get all of your old messages, which, whether you believe violates PFS by your chosen definition or not, does defeat its purpose (perhaps you prefer this phrasing to "break" or "breach").
Playing loose with definitions is how half of all broken cryptographic schemes ended up insecure and broken. Being precise with attack definitions allows for better analysis and better defenses.
Like how better analysis of common attacks on long running chats with PFS lead to "self healing" properties being developed to counter point-in-time leaks of session keys by repeatedly performing key exchanges, better protecting long term keys by for example making sure software like Signal make use of the OS provided hardware backed keystore for it, etc. All of this is modeled carefully and described with precise terms.
Edit: given modern sandbox techniques in phones, most malware and exploits doesn't survive a reboot. If malware can compromise your phone at a specific time but can't break the TPM then once you reboot and your app rekeys then the adversary no longer have access, and this can be demonstrated with mathematical proofs. That's self healing PFS.
Anyone can start a forum.
Fair point, but my cryptography forum (reddit.com/r/crypto) has regulars that include people writing the TLS specifications and other well known experts. They're hanging around because the forum is high quality, and I'm able to keep quality high because I can tell who's talking bullshit and who knows their stuff.
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.
Any new client doesn't get old messages. Phone only allows the possibility of transferring a backup, which desktop doesn't have.
I haven't actually synced a new phone to Signal, does everything just carry over? I assumed you needed to transfer your account from phone to phone, not just link a new device.
Yes
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.
Matrix does it this way
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?
Inability.
Unabilifiedness
Thanks
What does this mean? I use my phone and computer, and they sync up in real-time without any issues.
It means that if you have chats on one device and install Signal on another one, the chats don't transfer to it. After you link new device, new chats do sync perfectly fine.
After they dropped SMS support and called that a feature, now I can't wait for their hottest new bug!
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.
The best version of the Signal app was back when it was available as an actual web app.
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
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.
I've recently had an issue where it wasn't let me paste anything that I had copied from outside the app
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.
it won’t even use the OS emoji font.
im still amused by the fact that discord mobile uses two yes, you read that correctly, TWO emojis sets, it uses one in app, and the selector, and then uses another for the text input line, because.
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.
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.
That's why I am so happy that I switched to Matrix - selfhosted with Signal and WhatsApp Bridges(amongst others) and now I only need to keep one App on our mobiles, Notebooks,desktop,etc. but I can still communicate with everyone.
(we have have a few mixed groups now)
Is Matrix another one of those apps that when you click on a download link it takes you to a page full of tech jargon shit like "nightly signed beta configs here, just unjibble the .trag file and recombobulate with a python scrab to mambo directory: AAATGFHHOLLLM56888NGAAA.tar.gz" ?
Or is it like an app normal people can use?
Of course not,
with the new encapsulator all you need is to reconfigure your turbomutator to allow electrostabilizer executable to directly read instructions from your self-hosted AI model.
Who even uses python to scrab anymore? Install podman dude.
Podman breaks the retroencabulation.
If you want to deal with the perpendicular crosstalk caused by the coaxial flutter...
I don't have the time nor the crayons to explain that to you.
as a big proponent of FOSS I see where you're coming from - but the reality will always be that apps which have a significant learning curve to even install are obviously hugely off-putting to the majority of users. While the rest of us might be comfortable cloning a repository and building from a tar file, expecting the average person who wants to talk with friends and family to jump through those kind of hoops is exactly what has held back wider adoption of better standards.
Things like flatpacks and snaps have gone a long way to making this less daunting, but when matrix isn't a 'self-hosted decentralised chat', it's a *'version of whatsapp that isn't always online, and i don't know where to download it and have to learn what the terminal is to even get it on my laptop' * - we can't be surprised people stick with the less secure, private, easy options.
That's why I'm a big advocate of signal - it's not perfect and part of me wishes it was matrix or threema or one of the other standards, but getting people comfortable with the idea of free and open source software, while making it as simple for them to install on their phone or computer as anything meta makes is a really good first step - in the meantime, it's up to us in the wider community to make the other solutions more intuitive, simple, secure, and trust that if a good enough job is done of that - they will come.
I managed to get my parents on signal because it's functionally a WhatsApp clone
as a big proponent of FOSS I see where you’re coming from - but the reality will always be that apps which have a significant learning curve to even install are obviously hugely off-putting to the majority of users.
i think part of the problem is that stuff like matrix is built for a very specific interface. Where as we could build something like matrix, in a different design meta, more akin to something like mumble, which not only greatly simplifies the construction of it, but also greatly simplifies administration of it. The protocol itself shouldn't innately require an obtuse arbitrary system that makes it a nightmare.
Anything that is remotely related to "web apps" or web in general, seems to be an utter fucking nightmare these days. I think we need a healthy dose of dedicated native applications.
Sorry,but have you at least read the wikipedia article before writing this post?
Matrix is a standard. Not an App. Just like Lemmy is.
There are dozens of clients (Element, Schildichat, Fuzzychat, Beeper) available to download for basically every system imaginable and in all major Appstores.
You can easily join an existing instance - and with beeper there is even one existing that handles all the bridges for you.
Only when you self-host it gets more tricky-just like it does with Lemmy(as a matter of fact Matrix is far easier to selfhost than Lemmy). And again there are various distributions available.
They aren't as easy as the clients and not as easy as flatpacks, but someone who has done their due diligence can absolutely handle them easily. (And self-hosting should absolutely not be "as easy as flatpacks/snaps" - the risk for both the admin and the net itself is too high).
But again: The average user has little incentive to selfhost. Just like you don't selfhost your Lemmy instance.
The Matrix environment is as easy to use as Signal, Threema, WhatsApp for ages now. In some points I would even argue that it's more user friendly than Signal,btw.
It's website seems to have had a graphic designer look over it. It seems to do the best of both worlds where you can download the default user friendly client or choose to go down the jargon route if you want to.
it's as easy to get into as lemmy/masto/fedi
It's not quite that bad but it was trickier than Lemmy.
I think you mean lazy illiterate people. just pay Google/amazon and be done with it
Don't be an elitist bung hole, dude.
elitist because I said they don't want to read? lol ok ... you weirdos get so butthurt over a simple statement
Not everyone has the ability or spare time to become skilled in every field. Calling them lazy and illiterate for not learning a complicated thing (when they may already be learning some other complex subject) is kinda the definition of elitism.
Tech bros are so fucking bad about this shit. Doctors too. I'm not an idiot, I fix big industrial machinery for a living, I can rewire your whole house up to code, but I don't work in tech so I don't know what the fuck a flapjack api is or whatever.
tech bro? wtf does that even mean. maybe stop crying that cOmpUteRs ArE hArD and use your brain
being able to read and follow instructions = elitism
please get your head out of your rear end
Your post encouraged me to self host Matrix ^^ That'll be a nice project for the next rainy day
I self-hosted it few months ago, and it's actually surprisingly easy! Someone has made an Ansible script for Matrix with Element and some bridges, that (at least a month ago, IaaC tends to be pretty fragile) worked out of the box on a first try. I just set up some config values (mostly about enabling bridges I want) based on their amazing documentation, and then ran it once and everything is working so far. I even updated it several times already, and every time it was smooth, and it was basically just running a single ansible command. Their documentation is pretty well written, and with my basic cloud, IT and Linux knowledge I had no issues with following it. All you need to know is how to set up cloud VM, get a domain and set DNS, and set up SSH keys to access the server.
In total it took me about two hours in total, from when I decided "I'm setting up Matrix tonight" without any prior knowledge, looking up my options and finding the ansible script, setting up cloud and getting Matrix up and running.
I'm renting a VM on Hetzner for like 6$ per month, and it worked without issues so far. I use it for Discord and Messenger, although the Meta bridge does have some problems, for example I didn't figure out how to message someone with whom I haven't had a conversation since I set up the bridge, since only then it creates the room for it. But that can be solved by keeping the Messenger app or usign the browser to send a first message, and it immediately shows in your Matrix bridge (and stays there forever).
Thank you for sharing your setup, this kind of information is always extremely valuable <3
Thanks,welcome to the club!
It can be a bit "tricky" at times (and I use a container manager,cloudron, meanwhile as I got too deep into the rabbit hole and now host too many things to maintain them myself) but once you get it set up it's rock solid.
And I am really optimistic for Element X/Matrix 2.0.
It's a great standard.
Gonna repeat what I said to Mikina - Thank you for sharing your setup, this kind of information is always extremely valuable <3
I can switch to Matrix and talk to the two other users on this platform! Can't wait!
Yeah, 115 Million users atm.
And as I said - you can easily bridge it to other services so you only use Matrix but communicate with others.
I'll give you a little anecdote. I joined a casual server on Matrix recently. Two minutes into the conversation, it turns out the person I was talking to is installing some Linux stuff and watching an episode of classic Doctor Who. That's two of my biggest interests right there that we immediately connected over. If there are only two users on Matrix, they're the only two I need.
I think the vast majority of people are more interested in talking to people they know in real life.
Like I know native apps are always better, but why doesn't electron ship an installable runtime so we don't have to have a shitload of inert chromium installs on one machine?
May be, but I don't think apps use it. Afaik Teams, Discord and such are all epectron apps, yet they have not much in term of dependencies and large install sizes, so they must ship with their own versions.
You don't understand. This way if some app crashes it will not cause others to crash too.
This is how google introduced the "multiprocess architecture" of Chrome.
You can still have separate processes and everything else with a shared runtime, you just save having all this wasted storage with every application bringing its own bundled runtime.
.net or Java applications work in a similar way, one Java app crashing won't take out another just because they're sharing the same runtime
I'd rather not have frameworks based on web browsers. Programming is not that difficult.
For most uses of electron I'd agree, but if some engineers are going to use it anyway, I'd prefer the approach I've described.
Programming is not that difficult.
Learning how to do something in a new language and framework isn't that tough, I agree, but no one is going to become an expert in something overnight. I don't reckon many desktop native engineers are choosing electron unless they actually need it, so if you imagine the case of an expert web engineer building a desktop UI, they're going to do a much better job with their main skillset than something they have just learned.
but no one is going to become an expert in something overnight
It's not like they need to become experts. But also that's actually possible (at least the effects of that), especially with all the AI around.
It's not like they need to become experts
I mean if they would produce a better UI by using their expertise, how would not becoming an expert in the new thing be better? The reality is that the people paying the engineer are going to want the better UX over the benefits of not using electron in most cases.
But also that's actually possible
Respectfully, no it's not, not with software engineering unless you're talking about learning a simple library or something.
If someone can genuinely master something in a day it wasn't much of a skill to begin with.
I've been in this industry for about 20 years now, I would find it very hard to believe an engineer who says they've gone from no knowledge to expert in a new framework/language in any short period of time. I would either assume they're trying to pull a fast one or more charitably just in the "naively confident" phase of learning:
especially with all the AI around.
AI can assist you if you more-or-less know what you're doing, but a novice replacing proper learning with ChatGPT pairing is going to write some shitty code. I use AI in my role semi-regularly, and in my experience, no model has consistently produced me anything (non-boilerplate) longer than a couple of lines that didn't need some kind of refactor for it to actually be up to our code quality standards. Sometimes you see them spit out some ancient way of doing things that have been outright replaced by a more modern approach, if you don't have the experience, you'll not know any better.
I mean if they would produce a better UI by using their expertise, how would not becoming an expert in the new thing be better?
I failed to understand the meaning of this sentence. It doesn't make sense to me. Producing a better ui is not even on the table when we are talking ui frameworks and native programming - you use what's available, and if you are a graphics designer then maybe you should've sticked to that instead. Becoming expert in native ui is super cool but I wouldn't expect such miracles from everyone. Just producing a valid low level code is enough to meet my standards of performance. That's because those standards were heavily affected by web frameworks existence.
The reality is that the people paying the engineer are going to want the better UX
And I hoped it would be customers who would pay for a software or a service who would send valid feedback.
AI can assist you if you more-or-less know what you're doing
Assuming web devs creating apps don't know what they're doing?
but a novice replacing proper learning with ChatGPT pairing is going to write some shitty code.
Chances are that code would be much more optimized than anything electron/CEF wrapped.
to actually be up to our code quality standards
Quality standards are great. But seeing companies shipping fixes to simple CSS issues that were breaking some of main app functions made me realize most of them don't care about quality standards. If that's how it is and if there will still be a lot of broken stuff across app updates - might as well just go all the way to proper low level languages.
Well obviously it is, or we wouldn't have electron in the first place.
We have it only because some devs are lazy.
Signal package has Electron (which is built on top of Chromium and NodeJS) + Signal app code and assets. So not surprised that it's bigger than Chromium.
Debian Linux installation ISO is only 336 MB, FFS. And that’s a whole operating system with user land!
Haha, WeChat is even more outrageous than this. All your forwarded files will be automatically stored again. Your chat records will always be stored on the disk, but WeChat will tell you that the chat records have expired. In addition, it has recently been discovered that every Once you log in to WeChat, your avatar will be saved more than ten times
You can actually delete the data for good in both the android and windows software through the interface, and it works. But yeah the amount of data is staggering.
I've got a reminder in my calendar to delete the data on the first day of a new quarter, so this here is accumulated since April 1st:
"android is good" mfers when they have to manually set a calendar task to notify themselves to manually delete the bloated information for an app that they have installed.
no shade to you specifically, but it pisses me off how much android users circle jerk over it being better than IOS, even though it's like, moderately less annoying.
Calm down children, they both suck. Now put the rulers away.
they both suck.
this is literally just what i said, but ok.
I can automatically clean up space, or restrict space used, but then I don't get to choose who's data to keep or.
gotta love when they implement half of the functionality, instead of just implementing all of the functionality, because it would take like, ten more seconds.
iphone mfs when they have to read the word android
insert weird rambling about superiority while feeling superior themselves
while true, i am not an iphone user, and IOS is still rather funny.
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.
They're talking about the desktop application.
"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
That sounds like a problem with YOUR phone. Every phone I've bought has been faster than the last. Maybe you have too much bloatware?
I use open source Android only, will not use a phone with stock android. Bloatware is a non-issue on AOSP unless you do that to your own phone.
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.
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.
even the phone app is larger than telegram and whatsapp
Is it possible to run the android app on Linux somehow? Hmm...
Waydroid! No idea if Signal works with it though, worth to try it
Sadly, it's the only way I can contact someone to buy a decent quantity of weed in this state. I get less even if I go to a state where it's legal and I pay more.
What's so sad about it? You have the ability to securely send E2EE messages for free. I'm very pleased with Signal after using it for years.
If you mean it's sad about the weed being hard to get / illegal... yeah, I concur. Hopefully Schedule III happens soon and nationwide Medical will be legal.
Well dooh, you installed Chrome with it. Add to that their application and there you have it.
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?
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.
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.
and it also runs like shit too.
Harddrives start at 16€/TB, so 500MB would be 0.008€. SSDs start at 50€/TB, so it would be 0.025€ or two-and-a-half cents
I don't think people are worried about storing hundreds of Signal instances, this isn't a photo backup.
The concerns are bloat, optimisation, and memory usage.
Also, HDDs can go from $7.5/TB
That's the point. The storage is a bad metric. While it might indicate poor performance, it's not a direct indication of poor performance. The bloat and optimization comes from the usage of Electron. And people use Electron because it's far easier to make cross-platform deployments for Web and desktop using a framework like Electron. Show me the QT/JavaFX app that mimics Signal and we can compare the cost to develop it. Electron isn't the best choice for memory usage and reducing bloat, but it's the best choice for quick development (in my opinion but also proven out by the market share it has)
Me putting a 4 TB 3.5" HDD in my phone
Why are you installing Signal Desktop on your phone?
You got me there
yes but think about how much money writing 500MB worth of code would cost.
I realize it's not all code, and some of it is already written, but please, muse me, and do the math for it.
Writing less code costs more money. The programm is large because they slapped some existing stuff together instead of writing everything from scratch
there is an inevitable cost to written code though, it simply cannot be computed away. In this case the cost is just a shitty application with an even shittier user experience.
This is why I moved to Telegram. Idk if it's actually native, but often feels much more so, and less phone-centric than Signal which requires weird auth rituals involving the phone.
Personally, I'm a big fan of XMPP, due to the inherent resiliency in being decentralized/federated, and due to the security provided by OMEMO (based on signal's algorithm). Don't have to worry about third-parties messing with my data if it stays on my server that's in my house.
People want a chat app. If your secure chat app sucks as a chat app, it doesn't matter how secure it is. It failed the primary use case it was meant to be developed for.
But keep in mind, Signal's nature is no excuse to have shitty app implementations. In particular to have desktop apps as second-class citizens (and tablets as exterminated not-citizens). You can be a secure chat app. Signal got the secure part done, they're just struggling with the chat app part.
Signal is not an alternative to telegram and vice versa. Telegram has too many public communication features that people often use. The nature of signal will prevent it from having similar features.
its a QT+Webview project. So C++ and JS together. Cpp doing heavy tasks while JS doing cute animatons.
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 wink
Steam is close but actually not electron, they use CEF - Chromium Embedded Framework which is something Electron uses too under the hood (afair)
Thanks for the correction, appreciate it. Not sure it changes much though.
Steam used an embedded browser long before it was cool.
Electron doesn’t use CEF, they directly bundle Chromium.
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.
Would be kind of cool to allow people to choose an install method. As someone who has experienced low bandwidth in rural homes, it would be nice to avoid the waste at the cost of possibly managing chromium versions myself.
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.
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.
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)
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
What about sciter?
410mb for chat app seems very unoptimized
Hey now, the three React Native for Windows apps would be very offended if they were stable enough to read text input.
It's because it's an electron app. So in addition to the chat app itself, it also includes a full Chromium runtime. Worse still, the Electron architecture doesn't really lend itself towards reusing electron itself; this means you might have several copies of the same version of electron on your machine for various apps.
People complain about the sizes of things like flatpaks and snaps, but tbh the whole architecture of applications is like this these days. Ironically, flatpaks and snaps could help with this because their formats can work decently with filesystem level deduplication.
wait till you meet Line 😶
The inability to continue chat from phone is a feature.
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?
From http://support.signal.org/hc/en-us/articles/360007059752-Backup-and-Restore-Messages#desktop_restore:
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)
I would argue that it is not limited to network traffic, it is the general concept that historical information is not compromised, even if current (including long-term) secrets are compromised.
From my comment earlier:
This describes devices linked to an account, where each is retrieving messages from the server - not a point-to-point transfer, which is how data is transferred from one Android device to another. If a new device could retrieve and decrypt old messages on the server, that would be a breach of the forward security concept.
Once again reminding you that I run a cryptography forum (I've done so for one 10 years, I keep up to date on the field) and it's a term defined by professional cryptographers.
https://www.sectigo.com/resource-library/perfect-forward-secrecy
https://link.springer.com/referenceworkentry/10.1007/978-1-4419-5906-5_90
https://www.sciencedirect.com/topics/computer-science/forward-secrecy
Literally all definitions speak of network traffic and leaked / extracted encryption keys. PFS is about using short term keys that you delete so that they can not leak later.
Backup and sync via a separate mechanism is not a PFS violation. In particular because they're independent of that same encrypted session. It's entirely a data retention security issue.
Matrix.org supports message log backup via the server, and does so by uploading encrypted message logs and syncing the keys between clients. You can delete the logs later, or delete your keys, or even push fake logs if you want. It's still happening outside of the original encrypted session and the adversary can't confirm what actually was said in the original session.
I don't know why you think that PFS is broken if a local client has to be breached to recover encrypted data from a cloud backup, but PFS is not broken if a local client has to be breached to recover the same data from the client itself. Literally the only difference is where the data is stored, so either chat logs available to the client break PFS or they do not
You are conflating the concept and the implementation. PFS is a feature of network protocols, and they are a frequently cited example, but they are not part of the definition. From your second link, the definition is:
And your third link:
Neither of these mention networks, only protocols/schemes, which are concepts. Cryptography exists outside networks, and outside computer science (even if that is where it finds the most use).
Funnily enough, these two definitions (which I'll remind you, come from the links you provided) are directly contradictory. The first describes protecting information "before the exposure" (i.e. past messages), while the second says a compromise at
jcannot be used to compromisek, wherekis strictly greater thanj(i.e. a future message). So much for the hard and fast definition from "professional cryptographers."Now, what you've described with matrix sounds like it is having a client send old messages to the server, which are then sent to another client. The fact the content is old is irrelevant - the content is sent in new messages, using new sessions, with new keys. This is different from what I described, about a new client downloading old messages (encrypted with the original key) from the server. In any case, both of these scenarios create an attack vector through which an adversary can get all of your old messages, which, whether you believe violates PFS by your chosen definition or not, does defeat its purpose (perhaps you prefer this phrasing to "break" or "breach").
This seems to align with what you said in your first response, that Signal's goal is to "limit privacy leaks," which I agree with. I'm not sure why we've gotten so hung up on semantics.
I wasn't going to address this, but since you brought it up twice, running a forum is not much of a credential. Anyone can start a forum. There are forums for vaxxers and forums for antivaxxers, forums for atheists and forums for believers, forums for vegans and forums for carnivores. Not everyone running these forums is an expert, and necessarily, not all of them are "right." This isn't to say you don't have any knowledge of the subject matter, only that running a forum isn't proof you do.
If you'd like to reply, you may have the last word.
This is ridiculous rules lawyering and isn't even done well. Such schemes inherently assume multiple communicating parties. Sure you might not need to have a network but you still have to have distinct devices and a communication link of some sort (because if you have a direct trusted channel you don't need cryptography)
You're also wrong about your interpretation.
Here's how to read it:
At point A both parties create their long term identity keys.
At point B they initiate a connection, and create session encryption keys with a key exchange algorithm (first half of PFS)
At point C they exchange information over the encrypted channel.
At point D the session keys are automatically deleted (second half of PFS)
At point E the long term key of one party is leaked. The contents from B and C can not be recovered because the session key is independent of the long term key and now deleted. This is forward secrecy. The adversary can't compromise it after the fact without breaking the whole algorithm, they have to attack the clients as the session is ongoing.
This is motivated for example by how SSL3.0 usually was used with a single fixed RSA keypair per server, letting user clients generate and submit session encryption keys - allowing a total break of all communications with the server of that key is comprised. Long term DH secrets were also often later used when they should be single use. Then we moved on to ECDH where generating new session secrets is fast and everybody adopted real PFS.
Yes compromising the key means you often get stuff like the database too, etc. Not the point! If you keep deleting sensitive data locally when you should then PFS guarantees it's actually gone, NSA can't store the traffic in their big data warehouse and hope to steal the key later to decrypt what you thought you deleted. It's actually gone.
And both of the above definitions you quoted means the same as the above.
Playing loose with definitions is how half of all broken cryptographic schemes ended up insecure and broken. Being precise with attack definitions allows for better analysis and better defenses.
Like how better analysis of common attacks on long running chats with PFS lead to "self healing" properties being developed to counter point-in-time leaks of session keys by repeatedly performing key exchanges, better protecting long term keys by for example making sure software like Signal make use of the OS provided hardware backed keystore for it, etc. All of this is modeled carefully and described with precise terms.
Edit: given modern sandbox techniques in phones, most malware and exploits doesn't survive a reboot. If malware can compromise your phone at a specific time but can't break the TPM then once you reboot and your app rekeys then the adversary no longer have access, and this can be demonstrated with mathematical proofs. That's self healing PFS.
Fair point, but my cryptography forum (reddit.com/r/crypto) has regulars that include people writing the TLS specifications and other well known experts. They're hanging around because the forum is high quality, and I'm able to keep quality high because I can tell who's talking bullshit and who knows their stuff.
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
Any new client doesn't get old messages. Phone only allows the possibility of transferring a backup, which desktop doesn't have.
I haven't actually synced a new phone to Signal, does everything just carry over? I assumed you needed to transfer your account from phone to phone, not just link a new device.
Yes
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.
Matrix does it this way
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?
Inability.
Unabilifiedness
Thanks
What does this mean? I use my phone and computer, and they sync up in real-time without any issues.
It means that if you have chats on one device and install Signal on another one, the chats don't transfer to it. After you link new device, new chats do sync perfectly fine.
After they dropped SMS support and called that a feature, now I can't wait for their hottest new bug!
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.
I think this is a bit dramatic. I've been using it for years, no problems.
The best version of the Signal app was back when it was available as an actual web app.
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
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.
I've recently had an issue where it wasn't let me paste anything that I had copied from outside the app
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.
im still amused by the fact that discord mobile uses two yes, you read that correctly, TWO emojis sets, it uses one in app, and the selector, and then uses another for the text input line, because.
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.
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.
Same. I've seen the alternative called dependency hell too often... Yes, you can.share stuff between apps, but then, versioning is a nightmare.
That's why I am so happy that I switched to Matrix - selfhosted with Signal and WhatsApp Bridges(amongst others) and now I only need to keep one App on our mobiles, Notebooks,desktop,etc. but I can still communicate with everyone. (we have have a few mixed groups now)
Is Matrix another one of those apps that when you click on a download link it takes you to a page full of tech jargon shit like "nightly signed beta configs here, just unjibble the .trag file and recombobulate with a python scrab to mambo directory: AAATGFHHOLLLM56888NGAAA.tar.gz" ?
Or is it like an app normal people can use?
Of course not,
with the new encapsulator all you need is to reconfigure your turbomutator to allow electrostabilizer executable to directly read instructions from your self-hosted AI model.
Who even uses python to scrab anymore? Install podman dude.
Podman breaks the retroencabulation.
If you want to deal with the perpendicular crosstalk caused by the coaxial flutter...
I don't have the time nor the crayons to explain that to you.
as a big proponent of FOSS I see where you're coming from - but the reality will always be that apps which have a significant learning curve to even install are obviously hugely off-putting to the majority of users. While the rest of us might be comfortable cloning a repository and building from a tar file, expecting the average person who wants to talk with friends and family to jump through those kind of hoops is exactly what has held back wider adoption of better standards.
Things like flatpacks and snaps have gone a long way to making this less daunting, but when matrix isn't a 'self-hosted decentralised chat', it's a *'version of whatsapp that isn't always online, and i don't know where to download it and have to learn what the terminal is to even get it on my laptop' * - we can't be surprised people stick with the less secure, private, easy options. That's why I'm a big advocate of signal - it's not perfect and part of me wishes it was matrix or threema or one of the other standards, but getting people comfortable with the idea of free and open source software, while making it as simple for them to install on their phone or computer as anything meta makes is a really good first step - in the meantime, it's up to us in the wider community to make the other solutions more intuitive, simple, secure, and trust that if a good enough job is done of that - they will come.
I managed to get my parents on signal because it's functionally a WhatsApp clone
i think part of the problem is that stuff like matrix is built for a very specific interface. Where as we could build something like matrix, in a different design meta, more akin to something like mumble, which not only greatly simplifies the construction of it, but also greatly simplifies administration of it. The protocol itself shouldn't innately require an obtuse arbitrary system that makes it a nightmare.
Anything that is remotely related to "web apps" or web in general, seems to be an utter fucking nightmare these days. I think we need a healthy dose of dedicated native applications.
Sorry,but have you at least read the wikipedia article before writing this post?
Matrix is a standard. Not an App. Just like Lemmy is.
There are dozens of clients (Element, Schildichat, Fuzzychat, Beeper) available to download for basically every system imaginable and in all major Appstores.
You can easily join an existing instance - and with beeper there is even one existing that handles all the bridges for you.
Only when you self-host it gets more tricky-just like it does with Lemmy(as a matter of fact Matrix is far easier to selfhost than Lemmy). And again there are various distributions available. They aren't as easy as the clients and not as easy as flatpacks, but someone who has done their due diligence can absolutely handle them easily. (And self-hosting should absolutely not be "as easy as flatpacks/snaps" - the risk for both the admin and the net itself is too high). But again: The average user has little incentive to selfhost. Just like you don't selfhost your Lemmy instance.
The Matrix environment is as easy to use as Signal, Threema, WhatsApp for ages now. In some points I would even argue that it's more user friendly than Signal,btw.
It's website seems to have had a graphic designer look over it. It seems to do the best of both worlds where you can download the default user friendly client or choose to go down the jargon route if you want to.
it's as easy to get into as lemmy/masto/fedi
It's not quite that bad but it was trickier than Lemmy.
I think you mean lazy illiterate people. just pay Google/amazon and be done with it
Don't be an elitist bung hole, dude.
elitist because I said they don't want to read? lol ok ... you weirdos get so butthurt over a simple statement
Not everyone has the ability or spare time to become skilled in every field. Calling them lazy and illiterate for not learning a complicated thing (when they may already be learning some other complex subject) is kinda the definition of elitism.
Tech bros are so fucking bad about this shit. Doctors too. I'm not an idiot, I fix big industrial machinery for a living, I can rewire your whole house up to code, but I don't work in tech so I don't know what the fuck a flapjack api is or whatever.
tech bro? wtf does that even mean. maybe stop crying that cOmpUteRs ArE hArD and use your brain
being able to read and follow instructions = elitism
please get your head out of your rear end
Your post encouraged me to self host Matrix ^^ That'll be a nice project for the next rainy day
I self-hosted it few months ago, and it's actually surprisingly easy! Someone has made an Ansible script for Matrix with Element and some bridges, that (at least a month ago, IaaC tends to be pretty fragile) worked out of the box on a first try. I just set up some config values (mostly about enabling bridges I want) based on their amazing documentation, and then ran it once and everything is working so far. I even updated it several times already, and every time it was smooth, and it was basically just running a single ansible command. Their documentation is pretty well written, and with my basic cloud, IT and Linux knowledge I had no issues with following it. All you need to know is how to set up cloud VM, get a domain and set DNS, and set up SSH keys to access the server.
In total it took me about two hours in total, from when I decided "I'm setting up Matrix tonight" without any prior knowledge, looking up my options and finding the ansible script, setting up cloud and getting Matrix up and running.
I'm renting a VM on Hetzner for like 6$ per month, and it worked without issues so far. I use it for Discord and Messenger, although the Meta bridge does have some problems, for example I didn't figure out how to message someone with whom I haven't had a conversation since I set up the bridge, since only then it creates the room for it. But that can be solved by keeping the Messenger app or usign the browser to send a first message, and it immediately shows in your Matrix bridge (and stays there forever).
Thank you for sharing your setup, this kind of information is always extremely valuable <3
Thanks,welcome to the club! It can be a bit "tricky" at times (and I use a container manager,cloudron, meanwhile as I got too deep into the rabbit hole and now host too many things to maintain them myself) but once you get it set up it's rock solid.
And I am really optimistic for Element X/Matrix 2.0.
It's a great standard.
Gonna repeat what I said to Mikina - Thank you for sharing your setup, this kind of information is always extremely valuable <3
I can switch to Matrix and talk to the two other users on this platform! Can't wait!
Yeah, 115 Million users atm. And as I said - you can easily bridge it to other services so you only use Matrix but communicate with others.
I'll give you a little anecdote. I joined a casual server on Matrix recently. Two minutes into the conversation, it turns out the person I was talking to is installing some Linux stuff and watching an episode of classic Doctor Who. That's two of my biggest interests right there that we immediately connected over. If there are only two users on Matrix, they're the only two I need.
I think the vast majority of people are more interested in talking to people they know in real life.
Like I know native apps are always better, but why doesn't electron ship an installable runtime so we don't have to have a shitload of inert chromium installs on one machine?
May be, but I don't think apps use it. Afaik Teams, Discord and such are all epectron apps, yet they have not much in term of dependencies and large install sizes, so they must ship with their own versions.
You don't understand. This way if some app crashes it will not cause others to crash too.
This is how google introduced the "multiprocess architecture" of Chrome.
You can still have separate processes and everything else with a shared runtime, you just save having all this wasted storage with every application bringing its own bundled runtime.
.net or Java applications work in a similar way, one Java app crashing won't take out another just because they're sharing the same runtime
I'd rather not have frameworks based on web browsers. Programming is not that difficult.
For most uses of electron I'd agree, but if some engineers are going to use it anyway, I'd prefer the approach I've described.
Learning how to do something in a new language and framework isn't that tough, I agree, but no one is going to become an expert in something overnight. I don't reckon many desktop native engineers are choosing electron unless they actually need it, so if you imagine the case of an expert web engineer building a desktop UI, they're going to do a much better job with their main skillset than something they have just learned.
It's not like they need to become experts. But also that's actually possible (at least the effects of that), especially with all the AI around.
I mean if they would produce a better UI by using their expertise, how would not becoming an expert in the new thing be better? The reality is that the people paying the engineer are going to want the better UX over the benefits of not using electron in most cases.
Respectfully, no it's not, not with software engineering unless you're talking about learning a simple library or something.
If someone can genuinely master something in a day it wasn't much of a skill to begin with.
I've been in this industry for about 20 years now, I would find it very hard to believe an engineer who says they've gone from no knowledge to expert in a new framework/language in any short period of time. I would either assume they're trying to pull a fast one or more charitably just in the "naively confident" phase of learning:
AI can assist you if you more-or-less know what you're doing, but a novice replacing proper learning with ChatGPT pairing is going to write some shitty code. I use AI in my role semi-regularly, and in my experience, no model has consistently produced me anything (non-boilerplate) longer than a couple of lines that didn't need some kind of refactor for it to actually be up to our code quality standards. Sometimes you see them spit out some ancient way of doing things that have been outright replaced by a more modern approach, if you don't have the experience, you'll not know any better.
I failed to understand the meaning of this sentence. It doesn't make sense to me. Producing a better ui is not even on the table when we are talking ui frameworks and native programming - you use what's available, and if you are a graphics designer then maybe you should've sticked to that instead. Becoming expert in native ui is super cool but I wouldn't expect such miracles from everyone. Just producing a valid low level code is enough to meet my standards of performance. That's because those standards were heavily affected by web frameworks existence.
And I hoped it would be customers who would pay for a software or a service who would send valid feedback.
Assuming web devs creating apps don't know what they're doing?
Chances are that code would be much more optimized than anything electron/CEF wrapped.
Quality standards are great. But seeing companies shipping fixes to simple CSS issues that were breaking some of main app functions made me realize most of them don't care about quality standards. If that's how it is and if there will still be a lot of broken stuff across app updates - might as well just go all the way to proper low level languages.
Well obviously it is, or we wouldn't have electron in the first place.
We have it only because some devs are lazy.
Signal package has Electron (which is built on top of Chromium and NodeJS) + Signal app code and assets. So not surprised that it's bigger than Chromium.
Debian Linux installation ISO is only 336 MB, FFS. And that’s a whole operating system with user land!
Haha, WeChat is even more outrageous than this. All your forwarded files will be automatically stored again. Your chat records will always be stored on the disk, but WeChat will tell you that the chat records have expired. In addition, it has recently been discovered that every Once you log in to WeChat, your avatar will be saved more than ten times
You can actually delete the data for good in both the android and windows software through the interface, and it works. But yeah the amount of data is staggering.
I've got a reminder in my calendar to delete the data on the first day of a new quarter, so this here is accumulated since April 1st:
"android is good" mfers when they have to manually set a calendar task to notify themselves to manually delete the bloated information for an app that they have installed.
no shade to you specifically, but it pisses me off how much android users circle jerk over it being better than IOS, even though it's like, moderately less annoying.
Calm down children, they both suck. Now put the rulers away.
this is literally just what i said, but ok.
I can automatically clean up space, or restrict space used, but then I don't get to choose who's data to keep or.
gotta love when they implement half of the functionality, instead of just implementing all of the functionality, because it would take like, ten more seconds.
iphone mfs when they have to read the word android
insert weird rambling about superiority while feeling superior themselves
while true, i am not an iphone user, and IOS is still rather funny.
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.
They're talking about the desktop application.
"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
That sounds like a problem with YOUR phone. Every phone I've bought has been faster than the last. Maybe you have too much bloatware?
I use open source Android only, will not use a phone with stock android. Bloatware is a non-issue on AOSP unless you do that to your own phone.
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.
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.
even the phone app is larger than telegram and whatsapp
Is it possible to run the android app on Linux somehow? Hmm...
Waydroid! No idea if Signal works with it though, worth to try it
Sadly, it's the only way I can contact someone to buy a decent quantity of weed in this state. I get less even if I go to a state where it's legal and I pay more.
What's so sad about it? You have the ability to securely send E2EE messages for free. I'm very pleased with Signal after using it for years.
If you mean it's sad about the weed being hard to get / illegal... yeah, I concur. Hopefully Schedule III happens soon and nationwide Medical will be legal.
Well dooh, you installed Chrome with it. Add to that their application and there you have it.
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
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.
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.
and it also runs like shit too.
Harddrives start at 16€/TB, so 500MB would be 0.008€. SSDs start at 50€/TB, so it would be 0.025€ or two-and-a-half cents
I don't think people are worried about storing hundreds of Signal instances, this isn't a photo backup.
The concerns are bloat, optimisation, and memory usage.
Also, HDDs can go from $7.5/TB
That's the point. The storage is a bad metric. While it might indicate poor performance, it's not a direct indication of poor performance. The bloat and optimization comes from the usage of Electron. And people use Electron because it's far easier to make cross-platform deployments for Web and desktop using a framework like Electron. Show me the QT/JavaFX app that mimics Signal and we can compare the cost to develop it. Electron isn't the best choice for memory usage and reducing bloat, but it's the best choice for quick development (in my opinion but also proven out by the market share it has)
Why are you installing Signal Desktop on your phone?
You got me there
yes but think about how much money writing 500MB worth of code would cost.
I realize it's not all code, and some of it is already written, but please, muse me, and do the math for it.
Writing less code costs more money. The programm is large because they slapped some existing stuff together instead of writing everything from scratch
there is an inevitable cost to written code though, it simply cannot be computed away. In this case the cost is just a shitty application with an even shittier user experience.
This is why I moved to Telegram. Idk if it's actually native, but often feels much more so, and less phone-centric than Signal which requires weird auth rituals involving the phone.
friendly reminder
https://www.tomsguide.com/news/signal-vs-telegram
If you care about security, stop using telegram.
Personally, I'm a big fan of XMPP, due to the inherent resiliency in being decentralized/federated, and due to the security provided by OMEMO (based on signal's algorithm). Don't have to worry about third-parties messing with my data if it stays on my server that's in my house.
People want a chat app. If your secure chat app sucks as a chat app, it doesn't matter how secure it is. It failed the primary use case it was meant to be developed for.
But keep in mind, Signal's nature is no excuse to have shitty app implementations. In particular to have desktop apps as second-class citizens (and tablets as exterminated not-citizens). You can be a secure chat app. Signal got the secure part done, they're just struggling with the chat app part.
Signal is not an alternative to telegram and vice versa. Telegram has too many public communication features that people often use. The nature of signal will prevent it from having similar features.
its a QT+Webview project. So C++ and JS together. Cpp doing heavy tasks while JS doing cute animatons.
The telegram desktop app is wonderful