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...
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!"
LisPi@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...