this post was submitted on 29 Jan 2025
115 points (97.5% liked)
Asklemmy
44661 readers
763 users here now
A loosely moderated place to ask open-ended questions
If your post meets the following criteria, it's welcome here!
- Open-ended question
- Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
- Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
- Not ad nauseam inducing: please make sure it is a question that would be new to most members
- An actual topic of discussion
Looking for support?
Looking for a community?
- Lemmyverse: community search
- sub.rehab: maps old subreddits to fediverse options, marks official as such
- !lemmy411@lemmy.ca: a community for finding communities
~Icon~ ~by~ ~@Double_A@discuss.tchncs.de~
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Your data is routed through Signal servers to establish connections. Signal absolutely can does provide social graphs, message frequency, message times, message size. There's also nothing stopping them from pushing a snooping build to one user when that user is targeted by the NSA. The specific user would need to check all updates against verified hashes. And if they're on iOS then that's not even an option, since the official iOS build hash already doesn't match the repo.
Do you have anything to back this up?
They have to. They can't route your messages otherwise.
They have to know who the message needs to go to, granted. But they don't have to know who the message comes from, hence why the sealed sender technique works. The recipient verifies the message via the keys that are exchanged if they have been communicating with that correspondent before or else it is a new message request.
So I don't see how they can build social graphs if they don't know who the sender if all messages are, they can only plot recipients which is not enough.
Anyone who's worked with centralized databases can tell you that even if they did add something like that, with message timestamps, it'd be trivial to find the real sender of a message. You have no proof that they even use that, because the server is centralized, and closed source. Again, if their response is "just trust us", then its not secure.
From what I understand, sealed sender is implemented on the client side. And that's what's in the github repo.
How does that work? I wasn't able to find this. Can you find documentation or code that explains how the client can obscure where it came from?
https://signal.org/blog/sealed-sender/ explains the feature.
https://github.com/signalapp/Signal-Android/issues/13842 has some links into the code base showing where sealed sender is implemented.
Okay. But this method doesn't address that the service doesn't need the message to include the sender to know who the sender is. The sender ('s unique device) can with 100% accuracy be appended to the message by the server after it's received. Even if we trust them on the parts that require trust, the setup as described by the blog doesn't do anything to prevent social graphs from being derived, since the sender is identified at the start of every conversation.
If we trust them not to store any logs (unverifiable), then this method means they can't precisely know how long a conversation was or how many messages were exchanged. But you can still know precisely when and how many messages both participants received, there's just a chance that they're talking to multiple people. Though if we're trusting them not to store logs (unverifiable), then there shouldn't be any data to cross reference to begin with. So if we can't trust them, then why are we trusting them not to take note of the sender?
The upside is that if the message is leaked to a third-party, there's less info in it now. I'm ignoring the Github link, not because I don't appreciate you finding it, but because I take the blog-post to be the mission statement for the code, and the blog doesn't promise a system that comprehensively hides the sender's identity. I trust their code to do what is described.
How?
If I share an IP with 100 million other Signal users and I send a sealed sender message, how does Signal distinguish between me and the other 100 million users? My sender certificate is encrypted and only able to be decrypted by the recipient.
If I’m the only user with my IP address, then sure, Signal could identify me. I can use a VPN or similar technology if I’m concerned about this, of course. Signal doesn’t consider obscuring IPs to be in scope for their mission - there was a recent Cloudflare vulnerability that impacted Signal where they mentioned this. From https://www.404media.co/cloudflare-issue-can-leak-chat-app-users-broad-location/
…
I saw a post about this recently on Lemmy (and Reddit), so there’s probably more discussion there.
What do you mean when you say “conversation” here? Do you mean when you first access a user’s profile key, which is required to send a sealed sender message to them if they haven’t enabled “Allow From Anyone” in their settings? If so, then yes, the sender’s identity when requesting the contact would necessarily be exposed. If the recipient has that option enabled, that’s not necessarily true, but I don’t know for sure.
Even if we trust Signal, with Sealed Sender, without any sort of random delay in message delivery, a nation-state level adversary could observe inbound and outbound network activity and derive high confidence information about who’s contacting whom.
All of that said, my understanding is that contact discovery is a bigger vulnerability than Sealed Sender if we don’t trust Signal’s servers. Here’s the blog post from 2017 where Moxie describe their approach. (See also this blog post where they talk about improvements to “Oblivious RAM,” though it doesn’t have more information on SGX.) He basically said “This solution isn’t great if you don’t trust that the servers are running verified code.”
He then continued on to describe their use of SGX and remote attestation over a network, which was touched on in the Sealed Sender post. Specifically:
Later in that blog post, Moxie says “The enclave code builds reproducibly, so anyone can verify that the published source code corresponds to the MRENCLAVE value of the remote enclave.” But how do we actually perform this remote attestation? And is it as secure and reliable as Signal attests?
In the docs for the “auditee” application, the Examples page provides some additional information and describes how to use their tool to verify the MRENCLAVE value. Note that they also say that the tool is a work in progress and shouldn’t be trusted. The Intel SGX documentation likely has information as well, but most of the links that I found were dead, so I didn’t investigate further.
A blog post titled Enhancing trust for SGX enclaves raised some concerns with SGX’s current implementation, specifically mentioning Signal’s usage, and suggested (and implemented) some improvements.
I haven’t personally verified the MRENCLAVE values for any of Signal’s services and I’m not aware of anyone who has (successfully, at least), but I also haven’t seen any security experts stating that the technology is unsound or doesn’t actually do what’s claimed.
Finally, I recommend you check out https://community.signalusers.org/t/overview-of-third-party-security-audits/13243 - some of the issues noted there involve the social graph and at least one involves Sealed Sender specifically (though the link is dead; I didn’t check to see if the Internet Archive has a backup).
Your link lists all the things they don't share. The only reasonable reading is that anything not explicitly mentioned is shared. It's information they have, and they're legally required to share what they have, also mentioned in your link in the documents underneath their comment.
If you open the latest instance, from August 2024, you will find a California government request, for a number of phone numbers.
The second paragraph of that very page says:
They respond to the request with the following information:
The redacted values are the phone numbers.
That is the full extent of their reply. No other information is provided, to the government request.
We can't verify that. They have a vested interest in lying, and occasionally are barred from disclosing government requests. However, using this as evidence, as I suggested in my previous comment, we can use it to make informed guesses as to what data they can share. They can't share the content of the message or calls -- This is believable and assumed. But they don't mention anything surrounding the message, such as whom they sent it to (and it is them who receives and sends the messages), when, how big it was, etc. They say they don't have access to your contact book -- This is also very likely true. But that isn't the same as not being able to provide a social graph, since they know everyone you've spoken to, even if they don't know what you've saved about those people on your device. They also don't mention anything about the connection they might collect that isn't directly relevant to providing the service, like device info.
Think about the feasibility of interacting with feds in the manner they imply. No extra communication to explain that they can't provide info they don't have? Even though they feel the need to communicate that to their customers. Of course this isn't the extent of the communication, or they'd be in jail. But they're comfortable spinning narratives. Consider their whole business is dependant on how they react to these requests. Do you think it's likely their communication of how they handled it is half-truths?
California does not issue NSLs, the US federal government does. And those come with gag orders that means you will go to federal prison if you tell anyone that you've been asked to spy on your users.
Are you implying that Signal is withholding information from the Californian Government? And only providing the full extent of their data to the government?
This comes back to the earlier point that there is no proof Signal even has more data than they have shared.
If you don't know what an NSL is, then you definitely shouldn't be speaking about privacy.
It's unfortunate that you react like this. I don't claim to be an expert, never have. I've only been asking for evidence, but all we get to are assumptions and they all seem to stem from the fact that allegedly the CIA has indirectly funded Signal (I'm not disputing nor validating it).
The concern is valid, and it has caused a lot of distrust in many companies due to the Snowden leaks, but that distrust is founded in the leaks. But so far there is no evidence that Signal is part of any of it. And given the continued endorsement by security experts, I'm inclined in trusting them.
Snowden explicitly endorsed Signal, too - and as far as I know he’s never walked that endorsement back.
I think Dessalines most recent comment is fair even if it's harsh. You should understand the nature of a "national security letter" to have the context. The vast majority of (USA) government requests are NSLs because they require the least red tape. When you receive one, it's illegal to disclose that you have, and not to comply. It requires you to share all metadata you have, but they routinely ask for more.
Here's an article that details the CIA connection https://www.kitklarenberg.com/p/signal-facing-collapse-after-cia
The concern doesn't stem from the CIA funding. It's inherit to all services operating in or hosted in the USA. They should be assumed compromised by default, since the laws of that country require them to be. Therefore, any app you trust has to be completely unable to spy on you. Signal understands this, and uses it in their marketing. But it isn't true, they've made decisions that allow them to spy on you, and ask that you trust them not to. Matrix, XMPP and SimpleX cannot spy on you by design. (It's possible those apps were made wrong, and therefore allow spying, but that's a different argument).