26 ms·
When a reaches Signal's servers, all Signal knows is the destination and a timestamp. It even hides the sender via a process called sealed sender if you want to
by input_sh 5y ago
When a reaches Signal's servers, all Signal knows is the destination and a timestamp. It even hides the sender via a process called sealed sender if you want to look it up.
So all they have is your phone number, date when you've registered, and last time you've used it. If someone took over their servers, all they'd see are encrypted blobs and their destination. They have no reason to keep those blobs after they've been delivered.
This is exactly all the info they've previously reported to the courts. Example: https://signal.org/bigbrother/cd-california-grand-jury/ https://signal.org/bigbrother/cd-california-grand-jury/
Last connection date: 1634169600000 (unix millis)
Account created: 1606866784432 (unix millis)
- 0xy 5y agoYou imply metadata like encrypted blobs and destinations isn't valuable to governments and law enforcement. This is very far from the truth. People are killed over metadata. An encrypted blob also isn't nothing. Encryption is not a silver bullet. With a stream of encrypted blobs, you can ascertain: - Connections - Frequency of communication - Volume of communication (length of the blobs) - IP addresses - Receipt time on the target number Etc.
- Arnt 5y agoNote that Signal's architecture makes this difficult. You can observe metadata going to the Signal server and going from either the Signal server or from Google's blobs-to-apps service. Assuming that my phone uses the Google service (it can also use websockets directly from Signal), then you can see thee things: 1. You can see that my wife sends someone a message via Signal. 2. You can see a stream of data from Signal to Google. 3. You can see that an app on my phone receives a small amount of data from Google. You can still pick out something, but the architecture tilts the statistics and widens the error bars on your results.