A fresh install of Signal takes up 410MB, blowing both Firefox and Chromium out of the water

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:
  
  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.
  
  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:
  
  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.
  
  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:
  
  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.
  
  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
  
  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.
  
  Any new client doesn't get old messages. Phone only allows the possibility of transferring a backup, which desktop doesn't have.
- 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.
- 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?
- 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

Inability.

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!