As evidence, the lawsuit cites unnamed “courageous whistleblowers” who allege that WhatsApp and Meta employees can request to view a user’s messages through a simple process, thus bypassing the app’s end-to-end encryption. “A worker need only send a ‘task’ (i.e., request via Meta’s internal system) to a Meta engineer with an explanation that they need access to WhatsApp messages for their job,” the lawsuit claims. “The Meta engineering team will then grant access – often without any scrutiny at all – and the worker’s workstation will then have a new window or widget available that can pull up any WhatsApp user’s messages based on the user’s User ID number, which is unique to a user but identical across all Meta products.”
“Once the Meta worker has this access, they can read users’ messages by opening the widget; no separate decryption step is required,” the 51-page complaint adds. “The WhatsApp messages appear in widgets commingled with widgets containing messages from unencrypted sources. Messages appear almost as soon as they are communicated – essentially, in real-time. Moreover, access is unlimited in temporal scope, with Meta workers able to access messages from the time users first activated their accounts, including those messages users believe they have deleted.” The lawsuit does not provide any technical details to back up the rather sensational claims.
Is the same not true of any app depending on centralized servers, e.g including signal?
And also Google & Apple can backdoor any app on any mobile device.
You’ve already gotten a lot of responses about the first claim.
But to answer the second one:
Why would they mess with a specific app if they already control the OS? They could read everything they ever wanted from memory without anyone noticing.
It’s a lot easier to ship 1 app with a backdoor than reconstruct messages by scanning memory.
No. Signal encrypts every message on the device itself before sending to Signal servers. You can even confirm this yourself by looking at their github.
Whats app claims they do this but its impossible to confirm. Its extrenemly likely that either they dont encrypt at all or they have the decryption keys.
In The method described, it doesn’t matter if Signal encrypt the message before it leaves your phone, the plaintext is still in the app and gets sent to Meta while also being encrypted with Meta’s keys.
It’s basically impossible to know this isn’t happening based on reading source code, because the code to load widgets doesn’t have to be remotely close to the messaging code, you’d have to read the entire signal code based.
There is way to know that the code you read on GitHub is the code Google/Apple install on your phone.
🤣🤣🤣😂
Bruv, before Signal launched they posted an entire whitepaper detailing their protocol, the working mechanisms of the system, and source code. So to reply to your 3 points:
If you don’t understand how any of this works, it’s just best not to comment.
Why would any message be plaintext?
Fair you could have just said they have reproducible builds or linked to the docs: https://github.com/signalapp/Signal-Android/blob/main/reproducible-builds/README.md
Again you are missing the point of the attack
Back at you, even if you are right that signal is secure, the attack is not what you think it is.
What in the world are you talking about here, bud? Your comments are making zero sense.
Look, seriously, if my comment is being upvoted, it’s because I responded to yours, and people understand what I am saying in response.
You, unfortunately, clearly do not understand what I’m saying because you do not grasp how any of this works.
Lmao, sure buddy pat yourself on the back because you got upvotes.
You’re talking about E2E encryption as if it prevents
side-channelclient side attacks, but sure morons will upvotes because they also don’t understand real world security.The only useful thing you’ve pointed out in your deluge of spam, is that Signal builds are reproducible which does protect against the attack described (as long as there isn’t a backdoor in the published code)
That’s literally what E2E encryption does. In order to attack it from outside you would have to break the encryption itself, and modern encryption is so robust that it would require quantum computing to break, and that capability hasn’t been developed yet.
The only reason the other commenter’s words sound like spam to you is because you don’t understand it, which you plainly reveal when you say "(as long as there isn’t a backdoor in the published [audited] code)
E2E encryption doesn’t prevent client side attacks, I misspoke when I called it a side channel attack, and ultimately Signal code is audited, so Signal is more secure, but people are mistaking a client-side exploit (sent from Meta’s servers to the WhatsApp client) with breaking E2E encryption of whatsapp, which is not what is described in the article.
Do you know what size channel attacks are? Because nothing you’ve even tried to bring up describes one at all, or how it applies to your original comments.
Yeah a size channel attack is when a poster can’t let go of how small their dick is so talks about how great Signal is all day.
about the 3rd, is the end apk file downloaded by a useer on the playstore reproducible? could google add stuff to the apk before the user downloading it? do users ever bother checking if the apk hash matches the one from the reproducible build?
For most: yes, there is a risk that the vendor has included a backdoor. There is also the risk that they are straight-up lying about how their service operates.
For Signal in particular: You can verify that their claims are true because you can audit the source code.
The Signal client is open-source, so any interested parties can verify that it is A) not sending the user’s private keys to any server, and B) not transmitting any messages that are not encrypted with those keys.
Even if you choose to obtain Signal from the Google Play Store (which comes with its own set of problems), you can verify its integrity because Signal uses reproducible builds. That means it is possible for you to download the public source code, compile it yourself, and verify that the published binary is identical. See: https://github.com/signalapp/Signal-Android/tree/main/reproducible-builds
You might not have the skills or patience to do that yourself, but Signal has undergone professional audits if anyone ever discovers a backdoor, it will be major news.
You are more likely to be compromised at the OS level (e.g. screen recorders, key loggers, Microsoft Recall, etc.) than from Signal itself.
Signal could still (at least for a short period of time) read everything. Whisper System just has to push a Signal Update that no longer encrypts. It would probably be noticed pretty soon. And no not because of the source code. The source code is what they claim to ise to build the applications but they could easily apply patches before they build. You’d have to reverse engineer the compiled applications ro see if there is code that’s probably not in the source.
This kind of problem is typically way smaller in projects that actively encourage building the clients from source yourself - which Whister System/Signal does not.
Theres so many ways to check for that that don’t require decompiling the app.
You can straight compare the downloaded binary with a locally compiled binary to see if they match.
You can check the hash of app. Changing some lines of code and getting the same hash is so unlikely to be effectively impossible.
If for some reason Signal decided to do what you claim, it’d destroy thier credibility, be caught almost immediately, and only work once before the whole project gets forked, and would be true of any alternative.
This shows that you don’t understand e2e encryption. Watch a video about how comparing the keys can verify that no man in the middle attack is happening.
Article states that the is no technical proof. There are other ways to read messages or meta data without breaking encryption.
This shows you don’t understand the exploit being used.
Go hang out with Alice & Bob all you want, they aren’t breaking encryption.
I guess c/technology is the same as r/technology, full Smug fools that don’t read articles or understand real world security, but think they are 1337 hax0rm3n
Sorry but you’ll need to hold the L on this one. If I encrypt a message with public key material for which the only private key material that can decrypt the message is in only my possession, it doesn’t matter if the message passes centralized servers.
I’m not trying to be rude, that’s just how it works.
People not understanding how security threats actually work is why everything is so broken these days.
If you do it by hand sure.
If you put the message into an app then the app is trusted to not leak the message. What is described in the article is that Whatsapp can instruct clients to send a copies of the message from the app to their server.
There is nothing stopping any messaging app doing this, having decentralized servers and 3rd party clients wouldn’t stop this but it would make it much easier to protect yourself from the attack.
Your threat model seems to be an app whose published source code doesn’t match the published app, and whose published version uses a side channel not in the source code to leak messages in plaintext to a server. If that’s what we’re worried about then decentralization of the app’s main messaging channel makes no difference. The sneaky side channel could still be there in any app, centralised or decentralized.
That’s a theoretical worry to be mitigated through integrity checks on published open-source apps. The worry with Meta and WhatsApp is much more immediate: a known bad actor with a closed-source app, many domains they could use to leak keys or unencrypted messages, and a fawning relationship with the fascist and surveillance-hungry US Government. I’d still put significantly more trust in Signal even though it is centralised.
You’re right decentralization would help because you could isolate yourself from the corporate server sending the instructions for you to leak the messages.
But ultimately you’re right integrity checks of apps are a better way to address this and fortunately it seems Signal do produce reproducible builds. https://github.com/signalapp/Signal-Android/blob/main/reproducible-builds/README.md so is secure from this kind of attack (unless there is a backdoor in the published code)
I’m not following. In the WhatsApp case, yes, because we can’t see how those keys are managed. In the Signal case, we can. So the centralized server has zero impact on the privacy of the message. If we trust the keys are possessed only by the generating device, then how does the encrypted message become compromised?
I’m not talking about anonymity, only message privacy. No different than any of the other proxies or routers along the way. If they don’t have the key, the message is not readable.
Now I’m curious: how does the person you’re messaging get the same key to decrypt the message you send?
I’m genuinely curious.
They share it with you. Their public key is generated by them. You encrypt a message to them with their public key. They use their private key to decrypt it.
I want to add before I get completely roasted here, that this is intentionally reductive. Signal actually uses a much more interesting multikey sharing algorithm, double ratchet. This uses onetime keypairs, and really is worth reading about.
Is that vulnerable to an attack if a hacker gets their public key and intercepts the data traffic? Or can it only be used to encrypt but not decrypt?
Or are the added layers of complexity designed specifically to prevent that from happening?
This is why I like open-source, because people who know more about it than I do can check everything over and say whether it’s good.
deleted by creator
The centralized server is only important because it sends you the message to get around the encryption (either adding a new client to your list of trusted clients or in some other way getting your client to send your messages to Meta).
Because the client is capable of adding the backdoor, it isn’t comprosing the encryption. When you add a desktop client to your Signal account it doesn’t break E2E encryption either but your messages are visible in more places. That (or something like it) is what is being described, Meta aren’t decrypting your messages as they go through their E2E network, they are tapping them client side.
Even in an “insecure” app without air-gapped systems or manual encryption, creating a backdoor to access plaintext messages is still very difficult if the app is well audited, open source, and encrypts messages with the recipient’s public key or a symmetric key before sending ciphertext to a third-party server.
If you trust the client-side implementation and the mathematics behind the symmetric and asymmetric algorithms, messages remains secure even if the centralized server is compromised. The client-side implementation can be verified by inspecting the source code if the app is open source and the device is trusted (for example, there is no ring-zero vulnerability).
The key exchange itself remains somewhat vulnerable if there is no other secure channel to verify that the correct public keys were exchanged. However, once the public keys have been correctly exchanged, the communication is secure.
Well audited is key, this attack likely works by doing something like adding Meta to the list of trusted devices, then hiding itself from the list (either because of code in the client or because it the meta device is only added for a moment), so the backdoor wouldn’t be send_all_messages_to_hq(), it would be in the code to list trusted devices, either explicitly hiding some devices or some sort of refresh timer that’s known so you can avoid being there when the UI is updated).
Or it works through the some other mechanism that still preserves E2E encryption.
I assumed that not only the entire app but also the entire client device had been audited. This was a client-side attack, not Meta momentarily adding itself to the trusted-device list. I’m confident it was a client-side attack because it would be impossible to hide even a momentary change in keys from the client without modifying the client app to conceal such a change.
Does WhatsApp make it visible when you add a new trusted device? Does Signal?
But yeah Meta have full control of the client and it isn’t audited so they could do it a lot of ways.
The “exploit being used” is closed-source, proprietary code sending data where it says it doesn’t.
People have already explained to you how signal’s open-source, auditable, and reproducible code prevents the possibility of a similar exploit.
You’re the smug fool who doesn’t understand cybersecurity. How much is zuck paying you to say “signal’s just as bad as whatapp”?
Nobody is saying signal is just as bad, simply that it’s not invulnerable to this kind of attack, even with reproducible builds, especially as we don’t know how the attack works.
When is the last time you checked the linked-devices tab in signal?
Dude…your comments here clearly display that you do not have a single clue as to how cryptography works. You should just pack it up in this thread and head on down the road.
Dude, your comments clearly display that you do not have a single clue as to how security works. You should just pack it up in this thread and head on down the road.
WhatsApp’s cryptography isn’t broken, the app is.
🤣🤣🤣
You need a juice and a nap, Ke-mo sah-bee.