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.
Well if I can’t trust Meta with my information, who CAN I trust
Me
Can confirm, chemicalprophet is the best password manager I’ve ever used.
Ah! You did your own research!
E2EE isn’t really relevant, when the “ends” have the functionality, to share data with Meta directly: as “reports”, “customer support”, “assistance” (Meta AI); where a UI element is the separation.
I thought they stole Signal’s code ( I know it’s open Source but still … Taking free code to profit from it is quite a fucktard move) to achieve e2e encryption? Who could have thought they weren’t honest in their intention!?
/S
Just assume any digital platform you’re using isn’t safe at this point.
It is end to end encrypted but they can just pull the decrypted message from the app. This has been assumed for years, since they said they could parse messages for advertising purposes.
Why am I not surprised? Whether there is no end-end encryption, they have a copy of every key, get the decrypted messages from the client, or can ask the client to surrender the key - it does not matter.
The point is that they never intended to leave users a secure environment. That would make the three latter agencies angry, and would bar themselves from rather interesting data on users.
If I am not adding my own private key to the app, like in Tox, I don’t trust their encryption.
What’s stopping the app from keeping your private key and still not encrypting anything?
I’m not trying to be difficult here, I just don’t see how anything outside of an application whose source you can check yourself can be trusted.
All applications hosted by other people require you to react positively to “just trust me bro”.
Tox also isn’t that great security wise. It’s hard to beat Signal when it comes to security messengers. And Signal is open source so, if it did anything weird with private keys, everyone would know
Well, Whatsapp uses signal. Bad timing
How?
WhatsApp is using Signals protocol for communication: https://signal.org/blog/whatsapp-complete/
I don’t fully understand what it entails, but from what I understand is that yes, WhatsApp is using the same encryption and message flow that signal uses, but you’re still using Meta’s app, and they can just read the plaintext message from there.
To my knowledge, under Signal, the encription keys are locally generated and stored, and the traffic flows between end points as a closed packet.
This does not seem to be the case here, as the keys are generated and stored outside your equipment and, thus, are viable to be used by a third party to access packets.
But I admit I speak heavily burdened by technical ignorance.
My understanding is they’re sending a request to your device that then decrypts and uploads messages, not storing the keys outside your device.
Unless proof is given, assume troll
Man, you just brought back memories. I forgot qtox was even a thing. I think I still have my profile saved in my dev folder somewhere for my account
I would not be surprised at all if they’d have a backdoor way to filch data, or the key with which to decrypt backed up data.
Assume the same for Telegram and pretty much any chat platform that controls your private keys.
Telegram doesnt even pretend to be end to end encrypted.
iOS lets you create “secret chats” but as far as I know other platforms have eliminated that functionality at the request of governments. And I would assume Apple technically controls the keys on device.
The telegram was clear as a day they announced cooperation with the Russian government and they unblocked it. That was way before the whole France fiasco, I doubt they’re actually giving up the keys to France. I’m from East and many say that Telegram now is essentially a Russian weapon. Surveillance at home, total free reign (sell drugs, spread CP, etc.) in west.
If you’re American, I believe Telegram is actually safer than Whatsapp, as long as you can ignore the dirty side of it (surface deep web?), hence why Europe wants it under control
So, is it basically treating every message as a “group” message where it sends it to some system WhatsApp account and then also to your intended receiver? This is what I’m assuming based on them supposedly being able to see deleted messages. Also would let them say it’s technically still “E2EE” since it’s indeed E2EE to your receiver, but it’s also E2EE to them as well.
Ah yes, good old E2E AWA3E.
“End to end, and we are also an end”.
I guessed you meant “end to end, as well as 3rd end” before reading on.
The E is for “Everyone”
The S is for Security.
If that is the case though, its not E2E it’s client server encryption and then server client encryption back. thats just deceptive marketing at that point.
Obviously it’s deceptive. But if you individually encrypt the messages you’re sending, the one you send to the receiver still can’t be decrypted by Meta, only the copy sent directly to Meta can, so the copy sent to your intended receiver is still “E2EE.”
I don’t agree that would fit the protocol of end to end, that’s a common misconception, E2E by design means that it’s encrypted from the sender to the intended recipient. When you send a message the intended recipient isn’t the server, it’s the user you are sending to. That type of system would be called an encrypt in transit or a server client encryption not E2E. If they are classifying it as E2E that would be incorrect.
A classic example of a server client or encrypt in transit would be HTTPS, the server acts as a middleman between the clients, meaning that it decrypts the message then re-encrypts the message to the designated choice.
With an e2e system, the message the server transmits is never decrypted, the server already knows the destination based off the public key
An e2ee group chat would need every member to have every other member’s public key. So for 5 people, your client would sign with your private key and send 4 unique messages encrypted each with 1 other person’s public key. Each of them would decrypt their copy of the message with their private key and verify the signature with your public key. So I think what arcterus was saying was that employee who requests access to a user’s messages then becomes just another member of a group chat, but the UI just doesn’t show it as such. Every message you send is then secretly encrypted, on your client, with their special public key and sent to them to be decrypted. That would still be E2EE.
ok yea, I do agree with that POV on it. A ghost key like that would be within spec, cause yea at that point it would just be another member. I wasn’t taking it as an additional group member though, since the whistleblower is stating that they can put in any user id and have access to all messages live, that would mean they would have a ghost user on all messages period regardless of if its a group chat or not.
That wouldn’t be implausible though.
I will say, not too long ago there was some question if I had setup a WhatsApp account with my number due to some emails I was receiving. Not wanting to install the app and unwittingly create an account just by checking if I had one, my wife created a group chat with just her and my number, sent a message, and then we saw it get marked as read by all. Which in an E2EE system should not have been possible without me having the app setup. so I did go ahead and wiped an old and setup the app to make sure I was in control of any account for my number, and I did then receive that group chat. But still, very sketchy.
I used to store GPG encrypted files in google drive. But then I noticed bitrot in the stored files which made them impossible to decrypt. So I started adding CRC redundancy through DVDisaster. Which worked but became a PITA. So I finally gave up.
They really want your data.
The biggest news is that Slashdot is still alive.
+5 insightful
DUH
No if this is proven it would be a real scandal and would bring a lot of users to better alternatives.
If it’s false that’s good too, since then WA has e2e encryption
People wouldnt move. They know its not secure and they dont care enough.
Mark zuckerberg eats scandals for breakfast
would bring a lot of users to better alternatives.
Most users of whatsapp don’t care about e2e. They hardly even know what it is.
No but average people understand the concept of meta reading and accessing your private message. That would be a scandal and righly so
Right. This place sometimes forget that we are tiny community of techies that hate the system. Makes me see this place as a bit of a circlejerk at times.
Yeah the venn diagram overlap of “people who understand and care about e2ee enough to drop a messaging app for not supporting it” and “people who use whatsapp” has to be a sliver
It must really be empty… Two contradictory assumptions lol
They don’t but they do know what “Any Meta employee, and every US government employees, can read all of your messages” means
Especially if they saw it now
It’s already a known risk, because WA uses centralized key management and servers, and always has regardless what Meta says. If you believe their bullshit, then I feel sad for you.
Also…you don’t think that LAWYERS willing to go up against Meta would have rock solid proof from these whistleblowers FIRST before filing a lawsuit?
C’mon now, buddy.
Also…you don’t think that LAWYERS willing to go up against Meta would have rock solid proof from these whistleblowers FIRST before filing a lawsuit?
This is not how civil court works. It’s not trial by combat. There is no standard for the quality of lawsuits filed. And despite what the ambulance chasers say on TV, Layers get paid even when they loose.
“alleged in a lawsuit…” is the same level of credibility as “they out here saying…”.
It doesn’t matter if it’s criminal or civil. The costs to bring such a case are massive, and you’re leaving yourself open to a behemoth like Meta just dragging out the case for lengthy periods of time which drastically increase those costs.
No law firm files suit against a giant company like this unless they have rock solid proof they will, at the very least, land a settlement plus recuperation of costs. Just not a thing.
What are the better alternatives? because it seems like the comment section is flooded with people (yourself included) that don’t understand that most (probably all) e2e messaging apps are vulnerable to this attack as long as they trust a centralized server.
The issue isn’t an encryption one, it’s a trust one that requires you to trust the makers of the messaging app and the servers the apps connect to (and the method by which the app is distributed to you).
Signal uses reproducible builds for its Android client, and I think for desktop as well. That means it’s possible to verify that a particular Signal package is built from the open source Signal codebase. I don’t have to trust Signal because I can check or build it myself.
If I don’t have extreme security needs, I don’t even have to check. Signal has a high enough profile that I can be confident other people have checked, likely many other people who are more skilled at auditing cryptographic code than I am.
Trusting the server isn’t necessary because the encryption is applied by the sender’s client and removed by the recipient’s client.
Signal
You’re just replacing trust in Meta with trust in Signal Inc without understanding why WhatsApp is vulnerable to this.
Is Signal Inc more trustworthy than Meta? probably
is Signal (app) safe from the attack described? absolutely not.
Theoretically, you can check the code actually running on the Signal servers is the code they publish under a free and open source licence, using the hardware-based TEE attestations the servers will return
Someone more knowledgeable than me may have managed to do so, I haven’t.
Tell me you don’t understand how Signal’s E2E mechanism works without telling me you don’t understand how Signal’s E2E mechanism works.
Tell me you don’t understand what E2E encryption is without telling me you don’t understand that the limits of E2E encryption.
See every other comment in this thread describing in great detail why you are wrong, but that you fundamentally DO NOT UNDERSTAND how any of this works whatsoever.
You fundamentally DO NOT UNDERSTAND how security works, go play with your algorithms and stop spamming my replies.
Um, security is based largely on encryption algorithms.
This is key and I don’t think Signal shies away from this. You MUST trust the code you’re running. We know there are unofficial Signal builds. You must trust them. Why? Because think of it this way. You’re running a build of Signal, you type a messages. In code that text you type then gets run through Signal’s encryption. If you’re running a non-trustworthy build, they have access to the clear text before encryption, obviously. They can encrypt it twice, once with their key and once with yours, send it to a server, decrypt theirs and send yours on to it’s destination. (for example, there’s more ways than this).
Just because it’s centralized doesn’t mean that it falls under this risk sector. Theoretically if the app was open sourced and was confirmed to not share your private key remotely on generation (or cross sign the key to allow a master key…), then the most the centralized server could know is your public key, the server wouldn’t have the ability to obtain the private key (which is what is needed to read the e2e encrypted messages)
This process would be repeated for the other party. The cool part of that system is you can still share your public keys via the centralized server, so you wouldn’t need to share the key externally. You just need to be able to confirm that the app itself doesn’t contain code to send your private key to the centralized server. Then checking integrity is as easy as messaging your friend to post what their public key is, and that public key would need to match the public key that the server is supplying as your contact.
The server can’t MiTM attack it because the server has no way of deciphering the message in the first place, so the most it could do is pass the message onto the proper party whom has the private key to be able to decrypt it.
Not that I have any other suggestions aside from signal though, there aren’t many centralized e2e chat services. Most use client to server encryption which would allow decryption server side.
Just because it’s centralized doesn’t mean that it falls under this risk sector.
The attack as described almost certainly involves the server sending a message to your client and then having the messages replicated via a side channel to Whatsapp without breaking E2E encryption (it could be adding them as a desktop client or adding them as a hidden participant in all chats, that isn’t clear in the article)
If you could run Whatsapp without connecting to Meta, you would be safe from this attack, but as you’ve pointed out a secure client is a better solution.
Fully agree that in this case if the claim is true (they have had a few of these claims), it’s likely whatsapp either making itself a companion app that’s hidden, or has some form of escrow in place to allow deciphering the messages. (Considering Messenger allows decrypting e2e chats with a 6 digit security pin, I’m leaning towards an escrow)
I was just mentioning that this isn’t a fault of it being centralized, this is a design choice by the company when implementing e2e encryption, and that a properly functioning system would never give the server the ability to decipher the messages in the first place.
With e2e you don’t need to trust the servers. You only need to trust the client that does the encryption.
The attack as described almost certainly involves the server sending a message to your client and then having the messages replicated via a side channel to Whatsapp without breaking E2E encryption.
But yes the point is you can’t trust the clients.
If you could run Whatsapp without connecting to Meta, you would be safe from this attack, but as you’ve pointed out a secure client is a better solution.
Element / matrix.
we can’t lose!
Shocked, I tell you
I’m sure the encryption was disabled post meta buyout IT JUST MAKES SENSE!
Facebook added the encryption in the first place because so many people were leaving for Signal and Threema (and Telegram but that’s another security nightmare).
Telegram is more of a honeypot now than anything else
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.
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:
- No, this is stupid and easily verified by watching network traffic from any device. Signal isn’t secretly sending plaintext messages anywhere.
- No, it’s not impossible to tell this at all. That’s what source code is. The executable code. Not only have NUMEROUS security audits been done on Signal by everyone from Academia, to for-profit security researchers and governments, you can easily verify that what you’re running on your phone is the same source code as what is published publicly because the fingerprint hashes for builds are also published. This means the same fingerprint you’d get building it yourself from source should also be the same as what is publicly published.
- See my point above, but also when two users exchange keys on Signal (or in any other cryptographic sense), these keys are constantly verified. If changed, the session becomes invalid. Verifying these keys between two users is a feature of Signal, but moreover, the basics of cryptography functioning can, and have been proven, during the independent audits of Signal. Go read any of the numerous papers dating back to 2016.
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
If you don’t understand how any of this works, it’s just best not to comment.
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.
seriously, if my comment is being upvoted, it’s because I responded to yours, and people understand what I am saying in response.
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)
You’re talking about E2E encryption as if it prevents side-channel attacks
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)
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.
-
- Why would meta have access to signal’s memory?
- That’s why code audits have been done multiple times.
- Reproducible builds. Signal has those since 2016
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?
yes, that’s why it’s called fingerprinting:
it’s a kind of mathematical function that takes the entire code as input and outputs a unique result.
the result is just some string of symbols (which really just represent a unique string of 1’s and 0’s).
this unique string of characters is, as mentioned, unique for any given input.
this string can then be compared to any arbitrary other string, and if they match, then you know it’s the same code.
so in the case of signal anybody can download the source, compile it, and verify that it matches the fingerprint of the compiled code on their own device.
that’s why it can’t be faked: you compare the already compiled code.
if even a single digit of the code is out of place, it’s not going to result in the same string, and thus immediately get flagged as a mismatch.
it’s mathematically impossible to fake.
-
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.
And what if your target is using a different app for messaging?
I agree that blindly going trough memory isn’t the best solution. To catch everything, a keylogger as part of the input-handler of the OS would probably be the way to go.
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 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,
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)
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.
creating a backdoor to access plaintext messages is still very difficult if the app is well audited
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.
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.
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).
If we trust the keys are possessed only by the generating device, then how does the encrypted message become compromised?
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.
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.
