Lauren WeinsteinGet a Signal account for secure communications. DO IT NOW.
Kevin Karhan 
@lauren no, because @signalapp is subject to #CloudAct (= incompatible with #GDPR & #BDSG if you ever care!) and collects #PII in the firirm of #PhoneNumbers, which are at best pseudonymous but trivial to track and at most means that people inviting others without their consent comitted an illegal disclosure if PII!
- Use real #E2EE with #SelfCustody of all the keys that isn't a #proprietary #SingleVendor & #SingleProvider solution that peddles a #shitcoin #scam!
Give #XMPP+#OMEMO a shot: @monocles / #monocles & @gajim / #gajim.
Signal's Terrible MobileCoin Betrayal
Cassandrich@kkarhan @lauren @signalapp @monocles @gajim This 👆 is pretty much all false, & bad security/privacy advice.
@dalias I sincerely disagree because none of my claims got debunked and no evidence against #XMPP+#OMEMO have come up to me as of today.
- @signalapp being a #centralized, #SingleVendor & #SingleProvider solution subject to #CloudAct by virtue of being located in the #USA WILL NOT JUST BLOW UP IN PEOPLES FACES, BUT GET PEOPLE KILLED under #Trumpism!
I hope to be proven wrong, but up until now I've always been at the position of saying #ToldYaSo!
- Whereas with @monocles you have way stricter #DataProtection (cuz there are no #DataProtevtionLaws in the #US that actually get enforced, otherwise #Musk's minions.would've been jailed of not killed for trespassing and hacking critical systems!) AND unlike #Signal, monocles doesn't demand any #PII whatsoever! https://infosec.space/@kkarhan/113999675511028742
I robot part 6 full movie.I told you so doesnt quite say it.flv
@kkarhan @signalapp @monocles @lauren Very few systems promoted as Signal alternatives match the cryptographic privacy properties (see: ratcheting, etc.) of Signal.
The claims about "located in the USA" and "Cloud Act" are all nonsense because the only threat to Signal users from this is availability (seizure and shutdown of the server infrastructure), not undetected breakage of privacy properties.
There are presently no systems with superior privacy properties to Signal *and* level of functionality on par with what general public expects. There are a lot (like the XMPP stuff, *sigh*, and Matrix) that are worse in both regards. If you're happy with reduced functionality, Cwtch (and possibly some other similar Tor-based systems) or VeilidChat are stronger, but it's gonna be a while before you convince normies to use them, and in the mean time they're still going to be on insecure shit like WhatsApp, FB Messenger, Telegram, etc...
LisPi@dalias @lauren @monocles @signalapp @kkarhan > VeilidChat are stronger, but it's gonna be a while before you convince normies to use them
sadge
sadge
@signalapp @monocles @lauren @dalias To be fair though, @kkarhan might well be right about people getting killed if availability is lost at a critical time and it is for some reason or another the unlucky winner's only relevant means of communication prior to that.
Not only that, but @signalapp being.located in #Trumpist #USA means they gotta have to follow said laws and that means if flexed upon using #FOSTA & #SESTA or god forbid made-up claims to commit #TransGenocide and prosecute #Trans minors and/or their parents and/or medical professionals, THIS WILL BLOW UP IN THEIR FACES like a grenade used as ball gag and fuse pulled!
- It's absolutely trivial to abuse #Govware #Backdoors and thus track people down. #Signal by design and architecture WILL BE COMPLICIT IN IT!
For comparison: @monocles doesn't demand #PII like a #PhoneNumber or anything at all and if you don't trust them either (which is fair - never trust anyone, neither Signal nor #monocles nor me!) you can not only choose from various providers but literally #SelfHost your own (even as an #OnionService on @torproject / #Tor) and thus have full control of all the comms.
- And I'd rather recommend @micahflee 's #OnionShare over Signal just because that's even simpler and basically "fully decentralized" and "#serverless" that it's even more flexible.https://onionshare.org
Exposing The Flaw In Our Phone System
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
@kkarhan @micahflee @torproject @monocles @signalapp @lauren The PII of phone numbers in this case is somewhat relevant since it allows for side-channel attacks with zero-interaction SMS and other such shenanigans.
Not having the information would mildly complicate gathering data on participating devices to serve as targeting data.
Not having the information would mildly complicate gathering data on participating devices to serve as targeting data.
@lispi314 @lauren Not.only.that, but with a #PhoneNumber it makes it trivial to get details from @signalapp targeting a known individual.
- And with the prevalence of #Govware and the fact that there is literally no #LegitimateInterest since #Signal abandoned #TextSecure, it's yet another design flaw that is beibg intentionally kept instead of fixing it at all!
👊🇺🇸🔥@kkarhan @lispi314 @lauren @signalapp You can register any number on Signal even a landline, as long as you can get a 2FA SMS or phone call.
Signal knows nothing about its users, nor does it attempt to. See https://signal.org/bigbrother/. All they have is the date and time you registered and the last date and time your device connected to a service. They've been subpoenaed many times but haven't been able to provide any data because they don't have it.
@Avitus @lispi314 @lauren THE REQUIREMENT FOR A #PhoneNumber BY @signalapp IS LITERALLY THE PROBLEM!
- #KYC IS THE ILLICT ACTIVITY!!!
If you gonna say "JuSt GeT aN iMpOrTeD #SIM / #eSIM!" then you obviously expect people to have way more #financial means and #TechLiteracy than is needed to get absolute N0obs setup withb#XMPP+#OMEMO and pay for @monocles / #monoclesChat!
Avitus (@[email protected])
@[email protected] @[email protected] @[email protected] @[email protected] You can register any number on Signal even a landline, ass long as you can get a 2FA SMS or phone call. Signal knows nothing about its users, nor does it attempt to. See https://signal.org/bigbrother/. All they have is the date and time you registered and the last date and time your device connected to a service. They've been subpoenaed many times but haven't been able to provide any data because they don't have it.
@Avitus @lispi314 @lauren And if you think @signalapp is gonna defy a duely submitted warrant and doesn't store or;collect any #PII like #PhoneNumbers then you propably;also believe that #LoglessVPN|s are real...
@Avitus @lispi314 @lauren And that just assumes the #Trump-#Regime is going to duely submit a warrant to @signalapp and not just blatantly hold everyone.from @Mer__edith downwards at gunpoint.
- Cuz we've seen #Musk and his #Minions basically #hack #CriticalInfrastructure by just walking in the front door and taking over systems!
WE CANNOT ASSUME THE #USA WILL FOLLOW IT'S OWN LAWS ANYMORE!
#TLDR: @signalapp HAS NO "#LegitimateInterest" TO DEMAND A #PhoneNumber (or any #PII for that matter) TO BEGIN WITH!
- #BDSG literally bans such unnecessary data collection per law!
Avitus (@[email protected])
@[email protected] @[email protected] @[email protected] @[email protected] You can register any number on Signal even a landline, ass long as you can get a 2FA SMS or phone call. Signal knows nothing about its users, nor does it attempt to. See https://signal.org/bigbrother/. All they have is the date and time you registered and the last date and time your device connected to a service. They've been subpoenaed many times but haven't been able to provide any data because they don't have it.
@kkarhan @lispi314 @lauren @signalapp KYC demands a lot more than a phone number, and you're conflating "we need your phone number for 2FA” with KYC which collects name, address etc. Take a look at https://signal.org/bigbrother/.
No, it's not a conflation and @signalapp can shove their false justifications in the trashcans, because even they must admit that this is vry much classist at best if notbkakes them useful idiots!
@kkarhan @signalapp @lauren @Avitus Given the pervasiveness of surveillance capitalism and the ease by which a phone number can be reconstructed into a usably complete profile, collecting even just the phone number is an unnecessary risk.
@lispi314 @Avitus @lauren exactly that.
Espechally given that @signalapp discontinued #TextSecure, which was #SMS-based where one could've claimed a "technical necessity" existed.
- Nowadays it's rather empowering bad actors and introducing weaknesses given #GSM and #Telephony is inherently and unfixaboy insecure by design and that noone should rely on it being reliable or accurate to begin with as technology to selectively reroute calls and SMS are as old.as the underlying teoephony network!
Exposing The Flaw In Our Phone System
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
pixelschubsi@dalias @kkarhan @signalapp @monocles @lauren
Some people like to make bold statements without verifying first.
The server *can* do malicious things (even targeted, so it maybe already is happening without anyone known) that result in exactly an "undetected breakage of privacy properties". Here's an issue about this, closed with the comment that privacy features are only best-effort with no guarantee: https://github.com/signalapp/Signal-Android/issues/13842
Signal silently falls back to "unsealed sender" messages if server returns 401 when trying to send "sealed sender" messages · Issue #13842 · signalapp/Signal-Android
Guidelines I have searched searched open and closed issues for duplicates I am submitting a bug report for existing functionality that does not work as intended This isn't a feature request or a di...
@pixelschubsi @kkarhan @signalapp @monocles @lauren That's that sealed-sender is best effort, which is roughly equivalent to saying "trying to approximate what you'd get with a Tor-based or Velid-based approach on top of open internet is best-effort". It's still way better than all the posers who say "Signal is insecure because it's centralized, try my hand-rolled crypto instead!"
@dalias @lauren @monocles @signalapp @kkarhan @pixelschubsi Not that either #Tor or #Veilid (or #I2P, for the closest similar network by design) are really all that resilient to malicious global observers with malicious nodes running timing analysis.
Batching, delays and cover traffic are varying degrees of unimplemented in all of those.
(And of course, even when implemented long-running always-available/low-latency services are subject to deanonymization by active interference and passive observation of downtime correlated with power outages & natural disasters.)
Batching, delays and cover traffic are varying degrees of unimplemented in all of those.
(And of course, even when implemented long-running always-available/low-latency services are subject to deanonymization by active interference and passive observation of downtime correlated with power outages & natural disasters.)
@lispi314 @lauren @pixelschubsi yes, but we canbagree that very #centralized servers like those of @signalapp are way more susceptible to that compared to any halfassed #OniomService because it's trivialbto hust shove some #GlimmerGlass box on the fiber between a datacenter and their #upsream(sl and just "#bullrun" the selectively captured traffic...
With @torproject / #Tor it's much cheaper to actually attack and take down a #Server / #Service.
For an organization like #Signalcthat that gets their fans to #FUD about "#Metadata" it's shocking to see they didn't do an #OnionService to this day!
Genders: ♾️, 🟪⬛🟩; Soni L.@lispi314 @dalias @kkarhan @lauren @signalapp @monocles @pixelschubsi signal with crossposting (a la https://github.com/SoniEx2/loic ) would be so good...
not sure if it'd work but if it did, you wouldn't be relying on a single server.
@SoniEx2 @lispi314 @lauren @pixelschubsi
Well, @signalapp literally can't and won't make that happen.
- Whereas you could build a #XMPP(+#OMEMO) #Bot to do #Crossposting to anything with a decent #API!
@kkarhan @lispi314 @lauren @pixelschubsi @signalapp crossposting between irc and signal when
bridges are so 2000s. 2025 is the year of crossposting.
@SoniEx2 Good luck trying to convince @signalapp to #deshittify...
@dalias @kkarhan @signalapp @monocles @lauren
People always go with "Signal has the best crypto" to argue why Signal and only Signal. However, crypto alone is not the only thing in the world.
Good crypto might be necessary for good privacy and security, but it doesn't alone solve the problem. If Signal would send a clear test backup of all messages to their servers, all this great crypto would be worth nothing.
@dalias @kkarhan @signalapp @monocles @lauren
Specifically for this context, sealed-senders is one of the few features of Signal that differentiates it from WhatsApp, which uses largely the same crypto. If the few extra privacy features of Signal are just best-effort and it's fine they only work if the server does not misbehave, Signal becomes almost the same as WhatsApp - except that the one company that controls everything has a different name.
@pixelschubsi @kkarhan @signalapp @monocles @lauren No, not being a source of metadata, location data, contacts graph, etc. harvesting for Facebook, along with having open and auditable source, are the main things distinguishing Signal from WhatsApp.
@pixelschubsi @kkarhan @signalapp @monocles @lauren The above made-up threat you scaremongered about with Signal (malicious client behavior) already exists in WhatsApp and *will escalate* as soon as they want to please the fuhrer.
@dalias @kkarhan @signalapp @monocles @lauren
How do you know that Signal company does not share their metadata and contacts graph with Facebook? You make this assumption and you are probably right, but you have no way to verify.
@dalias @kkarhan @signalapp @monocles @lauren
Contact graph is who you are sending messages to. Signal servers can always see who receives a message and they can trivially see who sent a message if sealed senders is turned off (which, as is shown, can be done by the server). So Signal in fact has access to your contact graph.
They also have access to a bunch of other metadata, like the Apple/Google push token that is known to be used to spy on people: https://www.reuters.com/technology/cybersecurity/governments-spying-apple-google-users-through-push-notifications-us-senator-2023-12-06/
@dalias @kkarhan @signalapp @monocles @lauren
And I'm not even talking about Signal directly uploading the numbers in your device's phone book (although encrypted in a way that they likely have no direct access to it, but others likely do).
@pixelschubsi @kkarhan @signalapp @monocles @lauren Obviously you don't let it read your contacts book. It works fine if you opt not to. WhatsApp is almost impossible to use without granting it access - you can't initiate chats unless you know how to construct chat invite links to marshall them in.
@dalias @kkarhan @signalapp @monocles @lauren
You can use address book / contacts scope to only grant WhatsApp access to the part of the contact book you want to reach within the app. Or you put the app in a separate profile or similar sandbox that has its own address book. I know several people using WhatsApp this way.
@pixelschubsi @kkarhan @signalapp @monocles @lauren As discussed, yes sealed sender can be blocked causing fallback, but that's a visible and non retroactive attack. It never exposes your chat history or non Signal contacts or anything else, only who you received from while the attack is in progress.
@dalias @kkarhan @signalapp @monocles @lauren
As is described in the issue, the fallback to revealing the sender when sealed sender fails is not in any way communicated to the user and happens fully automatically. In fact, it randomly happens to users every now and then and that is by design. If it were to notify users when this happens, it would be very confusing.
@pixelschubsi @kkarhan @signalapp @monocles @lauren But again, hiding essential metadata that takes hard cryptographic routing work to hide is way above the scope of the class of messengers we're comparing.
The claim is not that Signal makes it impossible to recover some of this essential metadata. The claim is that it is not purposefully scooping up as much other private data as it can for an owner whose whole business model is scooping up personal data.
@dalias @kkarhan @signalapp @monocles @lauren
If you are saying, Signal is doing a better job in ensuring that big tech doesn't get rich with the data of its users than WhatsApp, I'll happily sign that.
But to me - and also how Signal advertises itself - it's not only against big tech, but also against state actors. And then this becomes a whole different story.
@pixelschubsi @kkarhan @signalapp @monocles @lauren It gives you full protection against state actors intercepting the contents of your communications.
As advertised.
It does not protect you from compromised client devices, compromised contacts selling you out, or some possibility of state actors determining who you're making contact with. But on the latter it's still better than anything else in its class.
If you need stronger, use Cwtch or Veilid and deal with reduced functionality & drawing more attention to yourself.
@dalias @kkarhan @signalapp @monocles @lauren
As far as I know, this is turned off by default and even then only visible if people look at the details of a message (which they don't do, realistically). Remember that this only has to happen for a single message to create the link in the contact graph. So if any, this is a red herring, not a mechanism that prevents Signal servers from creating a contact graph, if e.g. forced by the crazy government of the country they are located in.
@pixelschubsi @kkarhan @signalapp @monocles @lauren What you're imagining is an organization which has no mission or profit motive in tracking its users, but existential threat from being perceived as betraying its mission, spending inordinate resources and hiring labor to implement & host this, without anyone whistleblowing. All for the sake of a very small attacker capability. This just makes utterly no sense.
@pixelschubsi @kkarhan @signalapp @monocles @lauren Signal can't do that because they do not have arbitrary code execution privileges on the client. The client is FOSS and anyone can read the source, verify that it matches what's shipped, and audit what it does. Users who lack the skills or time to do that can refrain from updating right away until updates have received scrutiny.
@dalias @kkarhan @signalapp @monocles @lauren
Users, to a large degree, download the Signal app from the Google Play Store and Apple App Store. The apps shipped through this can hardly be verified by endusers. A modified version of the app could be delivered to selected users.
The official Signal app for Android is not fully open source and in its non-free parts does have a mechanism built-in that allows the code to be changed at runtime without allowing external auditors to review it.
@dalias @kkarhan @signalapp @monocles
Here's the link to the Signal source code dependency file importing a proprietary, obfuscated library that is known to dynamically load and execute arbitrary code from a server in the context of the calling process, thereby granting it access to everything that happens inside the app: https://github.com/signalapp/Signal-Android/blob/main/gradle/libs.versions.toml#L123
@pixelschubsi @kkarhan @signalapp @monocles @lauren Gradle is a Java build system not a runtime dynamic code injection system...
@dalias @kkarhan @signalapp @monocles
Mastodon removes the line number from the shared link in the nice preview.
In the shared file, line 123 is the reference to a proprietary and obfuscated library that is included as part of the build process. This library was never audited, but it is known to, when used, dynamically load and execute code without any additional sandboxing (thus inheriting all the permissions and access to the private files of the app calling into the library).
@pixelschubsi @kkarhan @signalapp @monocles @lauren You could have cited it by name then. I can't find any details on it right off much less whether it has RCE vectors. If you believe it does, can you please either file an issue on the tracker or provide sufficient information on where to find the evidence so that someone else can?
@dalias @kkarhan @signalapp @monocles
Honestly, "RCE" is the whole purpose of the library embedded here. That's not an issue, it's a feature, Google sells this as dynamically updating your dependency. This is why Signal cannot be made available in the F-Droid store.
@pixelschubsi @kkarhan @signalapp @monocles @lauren Of course (assuming your claim) it's "not an issue" for the library provider (Google). It's absolutely an issue for Signal and reportable as such. If your claim is true I expect them to remove it.
Amber 
@dalias @pixelschubsi @kkarhan @signalapp @monocles @lauren I see the line number and I get the following
google-play-services-maps = "com.google.android.gms:play-services-maps:19.0.0"I am failing to see any sort of evidence that this is an rce@puppygirlhornypost2 @signalapp @lauren @monocles @kkarhan @pixelschubsi Yes, exactly. That's why I asked for citation.
@dalias @puppygirlhornypost2 @signalapp @monocles @kkarhan @pixelschubsi Please remove me from this thread. Thanks.
@puppygirlhornypost2 @signalapp @dalias @monocles @kkarhan
For legal reasons, I can't speak about a bunch of internals of Play Services. This page https://developers.google.com/android/guides/overview?hl=en clearly shows that Google has the power to issue automatic updates to the part that is not inside the embedded library. I leave it up to your imagination that for technical reasons, some play services features (including Google Maps) had to replace IPC with dynamic loading.
@pixelschubsi @puppygirlhornypost2 @signalapp @dalias @monocles @kkarhan AGAIN, please remove me from this thread.
@puppygirlhornypost2 @signalapp @dalias @monocles @kkarhan
As a side note, Google issued a statement of data processing that apps that embed Google Maps need to disclose on their data safety section in the play store listing.
Here's the guidelines: https://developers.google.com/maps/documentation/android-sdk/play-data-disclosure
And here's Signal's page: https://play.google.com/store/apps/datasafety?id=org.thoughtcrime.securesms&hl=en
@pixelschubsi @puppygirlhornypost2 @signalapp @monocles @kkarhan That's marketing copy that doesn't explain anything technical about what's going on or how an application might or might not be affected in the way you claim.
If it's only affected when the host OS has Play Services (i.e. if dynamic code delivery has to happen thru the system service), this is really a non issue, because you're already running a backdoored host OS that could interfere with any application regardless of what libraries it links. And of course de-Googled Android users would not be affected.
(See caveats about "compromised device" in my other toot.)
@dalias @puppygirlhornypost2 @signalapp @monocles @kkarhan
This has nothing to do with the "host OS". If you use e.g. GrapheneOS and run its sandboxed play services, you're affected just as well.
Also, what you call "compromised" is one of the suggested setups according to Signal and probably also the most popular setup among its users. Thus, when suggesting anyone to use Signal without any further instructions, you're practically suggesting to use something you consider compromised.
@pixelschubsi @dalias @puppygirlhornypost2 that doesn't change the inherent issues of @signalapp being #centralized, #SingleVendor & #SingleProvider compared to #XMPP+#OMEMO as in @monocles / #monoclesChat & @gajim / #gajim.
Or des anyone expect #Signal and it's staff to actually resist?
Kevin Karhan :verified: (@[email protected])
@[email protected] no, because @[email protected] is subject to #CloudAct (= incompatible with #GDPR & #BDSG if you ever care!) and collects #PII in the firirm of #PhoneNumbers, which are at best pseudonymous but trivial to track and at most means that people inviting others without their consent comitted an illegal disclosure if PII! - Use *real #E2EE* with #SelfCustody of all the keys that isn't [a](https://www.youtube.com/watch?v=tJoO2uWrX1M) #proprietary #SingleVendor & #SingleProvider solution that [peddles](https://www.youtube.com/watch?v=0DSGq9FQKU4) a #shitcoin #scam! Give #XMPP+#OMEMO a shot: @[email protected] / #monocles & @[email protected] / #gajim. [1](https://docs.monocles.eu/apps/chat.app/) [2](https://docs.monocles.eu/services/chat.service/) [3](https://docs.monocles.eu/account/account/) [4](https://monocles.eu/more/#account-section) [5](https://monocles.chat/login)