Signal

Hello. I plan to make a page about Signal safe usage and opsec practices on lainzine.org . Is there anything you think it should include? As we know, Signal is not the best choice for digital security and there's plenty of nice alternatives like matrix, etc. However this doesn't change most security professionals from suggesting it to laypeople, and is now probably what most rely on for secure communications. Currently it will have: >Trust On First Use the "x changed security number" thing is really ambiguous and most users are going to ignore it. That could be more or less of a problem depending on your relationship is, but could especially be a problem if you're in a large, encrypted group chat and one person gets compromised. (from https://keybase.io/blog/chat-apps-softer-than-tofu ) >must have a phone number there's a certain level of trust it takes to even exchange this information in the first place, & of course your number will be shared with every group chat you join. There's a workaround we found where you can use the desktop app to register a number with a burner phone or google voice number, IIRC. >Gboard smartphones just have a keylogger in them, by default, for predictive text. I'm unsure if Signal prompts you to at least use incognito mode (as if you could trust that) at first. >encryption not default becoming compromised can mean as little as having your cellphone seized by a cop if the phone isn't fully encrypted or the signal message store isn't encrypted. Is it better to encrypt Signal messages, the whole phone, or both? Another, related problem to that is how if you use the desktop app, that's another folder you'll have to encrypt. more advanced/targeted attacks: >Metadata a lot of information goes through GSM, which could be selectively disabled but thats definitely one of the more difficult things to do with >the google maps sidechannel attack thing where code could be selectively loaded into your app without notifying you, apparently (last 3 things are from: https://blogs.fsfe.org/larma/2017/signal-backdoors/ ) I'm not sure how organizational politics it should get (such as Moxie Marlinspike endorsing WhatsApp because it uses the Signal protocol), because most laypeople probably won't know or care about how the Signal foundation is run and by who. & I feel the thing about their fed donors doesn't make them less reliable than the tor project in that respect. >Alternatives Matrix would appeal to more people if it was a little more user-friendly. Keybase just got bought by Zoom and that doesn't really build confidence. XMPP+OTR is also not the most user-friendly, for instance it lacks a popular cross-platform client. Wickr is closed source and has a bad track record. Don't even get me started on Telegram. Is Briar any good? Ricochet?

>>11163 Despite recommendations from many security professionals I trust and respect (including Snowden), all it took for me to unequivocally reject Signal was a look at the *huge* list of intrusive and potentially dangerous permissions it wants on my Android phone. I have never installed it and never will. Anyone who gets control of Signal owns your phone.

>>11163 Signal uses Google Play Services by default. But they switch to websockets when Google Play Services can't be found. Using Lineage or something similar without Google Play Services solves that problem, I'm not sure how easy it would be on a stock device. >encrypt Signal messages, the whole phone, or both? Newer Android versions encrypt the whole device by default (with your pin) but I don't know how secure it is.

>As we know, Signal is not the best choice for digital security and there's plenty of nice alternatives like matrix, etc. However this doesn't change most security professionals from suggesting it to laypeople, and is now probably what most rely on for secure communications. The problem is that people who browse lainchan and read lainzine aren't laypeople, at least not when it comes to technology.

>>11167 we're not, but we still have friends who are and might turn to us as security people, or we might wind up in groups where signal is used. having a reference to send people on best practices would be helpful, i think

Signal is like kicking dead whales down the beach, self hosted XMPP with OMEMO will provide virtually same security with less bullshit.

from https://www.slant.co/versus/1989/4568/~signal_vs_telegram

>>11169 XMPP introduces more bullshit. You have to create an account, and people don't like that. Not only that, you have to select from a variety of different servers, many of which don't support the XEPs that are required for secure communication. Then there's the whole mess with selecting a good app (because most people use iOS/Android, and don't care about Pidgin or Gajim), and those don't really exist. I tried getting my family on XMPP+OMEMO for a year. It was next to impossible. With Signal I can just tell them "download this and follow the instructions" and they're in. Signal is better than SMS, and that's all I'm aiming for with it. If I demanded perfect security, the cellphone's already in the river.

What's next, Facebook messenger usage article on lainzine?

>>11171 Stop spreading FUD, agent. Conversations is the most popular and recently developed app for pocket tracking devices, it's all you technologically illiterate idiots need: has OMEMO with QR codes, has list of servers built in, can be rented at Google Spyware Market, you don't need a cattle tracking ID (SIM card) to register at any of the servers, unlike Signal, most just present captcha, application has working Tor proxy. On personal computers there's Gajim, Pidgin and Dino. Anything is better than SMS, nobody uses SMS in current year though.

This is a good idea for an article, and I'm glad to hear lainzine is still active. My overall recommendation would be to *not* frame the article as "signal is pwned don't use it" and instead just focus on how best to use signal effectively, perhaps also pointing out situations where signal is and isn't appropriate. We all know XMPP+OTR/OMEMO is better, but signal is too useful a tool to ignore entirely. My feeling here is that most people, including lainons, are going to be using some kind of SMS-like service to talk to people who have their phone number. Signal is perfect for this use case, but is really not appropriate for situations where either (a) you don't know/trust the person on the other end of the call, or (b) if law enforcement getting access to an endpoint would be a problem for you (e.g. selling drugs. If one of your customers' phones gets searched they have your number. I'm not optimistic if courts will be able to understand the subtleties of deniable encryption, and LE will have your phone number anyway so even if it isn't admissible it makes you a target). You can of course give your article a bit of an anti-signal bias to counterbalance the unqualified praise it gets in mainstream tech news, but I would be careful about being too FUD-y. >the "x changed security number" thing is really ambiguous and most users are going to ignore it. Certainly an explanation on what this security number actually is and what it means is in order (although if your target audience is lainchan most people probably already know). To be fair, signal does a pretty good job explaining what it means and the "untrusted connection" notification is rather conspicuous, so you'd have to be willfully ignoring it. Maybe the most useful thing to talk about here is what you're actually supposed to do to verify the number. My suggestion would be call the person and (assuming you can recognize their voice) verify the fingerprint that way. >I'm unsure if Signal prompts you to at least use incognito mode (as if you could trust that) at first. IIRC it doesn't prompt you, but there is a setting for it under "privacy". You should probably recommend installing a third party keyboard from fdroid. >Is it better to encrypt Signal messages, the whole phone, or both? Both, of course. FDE will keep the cops from getting on your phone without a warrant (or a rootkit exploit). Encrypted signal messages will keep you safe even if that fuarrrks up (cop snatches unlocked phone from your hand, you have fingerprint or face unlock... like a dumbass), assuming you've added a PIN to the signal app. Perhaps also mention encrypted backups. Some basic opsec recommendations might be appropriate (deleting messages, etc.) but I wouldn't go too deep into that if you want the article to be focused on signal specifically. >because most laypeople probably won't know or care about how the Signal foundation is run and by who I agree, keep it concise and focused on the software itself. Although I'll admit the axolotl ratchet is probably the most important new crypto tool since onion routing, I still hate Moxie for a number of reasons. I think the iron grip he tries to keep over his software is totally counter to his stated goals (and I don't buy his justifications at all). However, that's the kind of conversation you have with people already in-the-know. Not terribly useful for e.g. the various activist organizations that are looking for a safe communication tool right now. If you want to add some kind of disclaimer, I would say something like "Note that in general Signal should not be thought of as an anonymity tool. It secures message contents and some metadata with reasonably secure end-to-end encryption. As a matter of general policy, OWS considers your phone manufacturer, large internet service corporations like Google, and (importantly) your contacts on the app to be reasonably trustworthy. You will need to carefully consider the implications that this policy has within your threat model". People don't realize how important anonymity is compared to "security". They think if "nobody can read your messages" then they're all good. It would be beneficial to give some argument for why anonymity is important in certain contexts. >alternatives I'd say recommend XMPP as the main alternative. Probably worth plugging conversations.im specifically since it's no harder to set up than signal on android, and on an iphone you just need to create an account through a browser and then plug the details into the chatsecure app. The rabbit hole is deep and interested parties will seek out more experimental alternatives, but XMPP is the closest match for signal's feature set (although notably doesn't do voice/video calling, but then again those features are more useful for the kind of person that you'd be giving your phone number to anyway). You probably also want to mention matrix, since it allows proper multimedia chat in ways that XMPP doesn't. You'll definitely want to go into exactly what is encrypted with matrix and how to tell if your server/client/chat is setup to be encrypted (or save these details for a second supplementary article). The only other option that IMO might be worth mentioning is GNU Jami. There aren't a ton of clients for it, just the official electron-based ones, but it's fully peer-to-peer, has some (from my understanding fairly weak) anonymous anonymous routing features (with proper onion routing planned for the future), and overall is more of a skype replacement than a discord replacement, which could be useful if secure audio/video calling is a non-negotiable feature.

>>11178 >has some (from my understanding fairly weak) anonymous anonymous routing features Sorry, I was thinking of GNUnet. Jami is almost entirely decentralized (requiring bootstrap nodes and in some cases TURN servers but that's it) but I'm not sure how well it handles anonymity. There's definitely less metadata passing through central servers though, so it already has a leg up on Signal.

>>11171 >the whole mess with selecting a good app Android: conversations.im Iphone: conversations account with chatsecure client Android to android is just as easy if not easier than Signal, android to iphone is a little trickier but still basically on par with Signal, but yeah the nature of XMPP means if you're using different clients there are some caveats (although this isn't really a point in signal's favor since they just straight up don't have a proper PC client). >Signal is better than SMS, and that's all I'm aiming for with it. Yes, I would agree. I have signal installed for cases where the only other alternative is SMS. >If I demanded perfect security, the cellphone's already in the river. I'm not sure why wanting better security/privacy than signal automatically means you need "perfect security", as if such a thing exists. You don't have to get everyone to use XMPP for it to be useful, you just need to have at least one other person (or, more pragmatically 3-4 other people) who is willing to use it for it to be worthwhile to maintain an account. Maybe nobody you know can be convinced to use XMPP, and that's fine, but you shouldn't get complacent using signal. It's a step in the right direction but if you care about privacy you should always be striving to do better. It's not about purity it's about neverending struggle towards improvement.

Also worth to address is the issue with the new PINs + secure value recovery, i.e. mandatory cloud backup of contacts & other info. It's unclear on the website, & also on the forum which is full of fans and an upvote system which leaves little room for discussion. https://community.signalusers.org/t/dont-want-pin-dont-want-anything-stored-in-cloud/14057

>>11185 idk why they do soykaf like this. like fine i'll let them have that maybe it makes sense to have encrypted cloud sync as an option, hell maybe even enabling it by default makes sense. after all, the signal foundation seems to think their userbase is retarded and who am i to contradict them. but why not just create a toggle? bury it as deep in the settings as you want, just let me turn it off. the silver lining here is the devs seem to view this as a step towards alias/usernames as an alternative to phone numbers (assuming this isn't just the same carrot they've been dangling for years) so hopefully that will actually happen. if it does then their monopoly over client software gets cracked wide open, since you will no longer need to rely on signal servers to send you the initial auth code and they'll have to come up with an alternative to whatever they use now for push notifications in order for phone-less accounts to work. i have to assume they know this and that's why they're dragging their feet. idk.. watching the soykafty dismissive treatment one of the UBports devs got for having the audacity to suggest that a linux based phone OS was worth supporting has really turned me against signal (not even in any official capacity mind you.. just accepting a pull request that lets their app talk to signal's push notification server). for context, this was around the time the ubports pinephone was shipping hundreds of units, probably with thousands more to come. if you all haven't been following this: linux phones are getting actually serious now and could be an appreciable force within a year or two if enough people rally behind them. doesn't it seem like, given their stated goals, the signal foundation should be doing everything in their power to make sure ubports, postmarketos, etc. are a success? i just don't understand what their ultimate goal is. why do they care so much about market share as a non-profit and do they not see that they're alienating their core userbase... you know, the people who would actually go out there and wage slave for them? anyway sorry for the rant, but maybe there's something in there that could help with the article.

>>11188 btw this is the thread i was talking about https://community.signalusers.org/t/public-client-api-and-push-notifications/13179

>>11178 Thank you so much for all of this. a lot of it will definitely be incorporated. I was thinking about the courts thing too. I've heard that courts tend to treat messages from seized devices like a private journal, even if OTR was technically designed for plausible deniability. It will need a link or something on this, though. Some groups are looking at Jitsi as an alternative to Zoom, but the E2EE is really not there yet. >>11181 Do conversations.im & chatsecure do encrypted group chats? GCs are inherently less secure for stated reasons, but it seems an important feature for this use case. >>11185 noted, thank you. kinda messed up they don't immediately tell you what the pin is for in the app

>>11190 seems I fuarrrked up my tripcode for the OP. can confirm i made that post, verify this one with with my trip in lainzine thread

>>11190 >Do conversations.im & chatsecure do encrypted group chats? I'd have to check if its implemented in the apps but XMPP supports it. Essentially you just do a handshake between parties in the chat the regular way then you encrypt a symmetric key and send it to everyone (all hidden from the user of course). This is also how multi-party messages with PGP work. I'll try to remember to check it out and get back to you. >It will need a link or something on this, though. Yeah, I'm not sure if it's actually been tested, which could be a testament to the fact that cops don't need to get into arcane cryptographics in order to lock people up. Really once they have your phone number and know who you are it's a lot easier for them to collect other evidence. >Some groups are looking at Jitsi as an alternative to Zoom, but the E2EE is really not there yet. Agreed.

>>11192 oops didnt mean to sage

Apropos practicality: when I was arrested in an EU country my Asus Zenfone which had password lock and some built in disk encryption was sent to Germany for cryptanalysis, but eventually none of its contents were presented to me in interrogations although during the return of the phone documents indicated that it had its data copied but this doesn't mean that it was unlocked or decrypted. The lock password was a simple 5 alphabet letter password so it wouldn't have been too hard to unlock I'd assume, I didn't keep anything of much interest saved on it so it could be it was unlocked but nothing found. What was presented to me in interrogations: a screenshot of a Whatsapp conversation found on a co-defendant's phone of two co-defendant's talking about something incriminating. Also presumably Google's data on my phone locations and whether it was turned on or off. Also data subpoena'd via some EU law from an EU company. Other stuff: after the fact I was given documents indicating tele-surveillance being used against me to collect metadata from my SIM provider, no content only metadata.

>>11195 I can't imagine what the glowies would think about me if somehow I went under scrutiny. I say so much depressing soykaf on the internet that the surveillance agent might kill himself before I do. For the use I make of technology I'd benefit so much from all the botnet services or not using it at all, I just hurt and isolate myself for nothing but a meaningless political statement that nobody even gets to hear. Yeah sure if you have nothing to hide doesn't mean etc. etc. but if you DO have something to hide you actually benefit from this convoluted privacy soykaf in some way. I feel sometimes like this is all a big push to isolate people who are dissatisfied with the system. I feel like there's a draw toward this stuff if you're mentally ill or an outcast, it feels like you want to take some independence back. Maybe it's me, I hope I'm not the only one who's this stupid.

>>11178 >Probably worth plugging conversations.im What about Tox, is that still a thing?

>>11197 The glowies don't really care about you in that way, they're just working a job in a complex bureaucracy. Once they have a charge they'll look for things that support that charge or add other charges and nothing else. (spoilers: they're also often not the sharpest and are very behind on technology but on the other hand you have to respect the fact that they work the job every day and have adapted to it over a long time) Of course it also depends on what kind of glowies, I've only had problems with local and national level glowies, the local ones usually care extremely little and have no resources but might act like thugs on the street. I was surprised that even a national organization that is internationally renowned relied on foreign organization for cryptanalysis, their investigative work wasn't very thorough or impressive either but at least they did it, what they were good at however was the paperwork and being current with laws and international cooperation. Now if one were to be targeted for national security concerns I'm not sure what that would entail, intelligence agency powers are constantly being increased and protections removed, but their focus is very narrow and defined by the policy objectives of their government so it is probably an unlikely category to fall into. I'm most worried about the criminal side of things including corrupt usage of intelligence agency powers, intelligence agencies and organized crime seem to have been mixing since Cosa Nostra helped Allied tanks land in Sicily. In Eastern Europe and Russia even just bloggers keep getting attacked. In general I try to caution against putting all of ones energies in technologically securing oneself when perhaps more beneficial would be just reading law and court documents, figuring out whats really been successfully used and where the common vulnerabilities are(spoilers: your 'friends'). My sad philosophy is that since there isn't much info about these things available it is fine to take damage when that damage then forces the opponent to show their hand and I learn something in the process, but having kind of resigned myself to this life ages ago it's an easier choice for me to make since I don't have much to lose. Perhaps this went a bit off topic... well I'll attach a speech from some mobster to lift spirits~

>>11205 Tox by their own admission is not ready to be used as a security tool, and may never be (there's a big disclaimer on their github).

>>11205 >>11213 Tox is currently in the middle of a full rewrite of the toxcore libraries. It is under active and dedicated development, but there probably won't be any security audits commissioned until the rewrite is more complete. In the mean time new features are being rolled out and tested pretty consistently. There is an active community of 2 Chinese rooms, 1 Russian room, a bunch of furry groupbots. The biggest room I'm aware of is Club Cyberia with the lainbot which has 15-30 people and active chats most days. Club Cyberia often has the devs in there, and some people are helping do testing on a few of the features. The tox client for android is mostly a dead project right now though, most of the focus is on the library rewrite. Umm that is a summary of where it is at right now. It is getting there, and we welcome people to take an active interest in development. The reason for the rewrite is because the devs actually listened to the community and determined ways to make the protocol spec more robust given the critiques that came out of the first audits. There was no smoking gun found in the first audit but there was enough that people wanted to do some serious restructuring of the protocol implementation.

I think Signal has some major issues from the POV of the technological community such as another centralised walled garden and the maintainers' opposition to alternative clients. However, cryptographically Siganl is at the top of its game and has proven in court that it holds minimal amounts of data. If you read the blog, you'll see how every new feature Signal adds has a priority on having no knowledge of data or metadata. But the most impressive thing is just how many regular people have gotten onto it which is way more than any other app. Currently, Signal has a strong focus on privacy. Security is interesting because it has an assumption that if someone gets your phone they get everything anyway. And it's useless for anonymity because of the phone numbers. The terrifying thing is to try to comprehend how WhatsApp has 2 BILLION users on it and is basically aiming to become the WeChat of the world.

>>11246 Yeah I think continuing the discussion on what means of communication to use between "enthusiasts" for stuff that truly needs to be private has some merit to it. If Signal continues to go down this relatively OK path they've been going down, though, we need to thank our lucky stars that something like it is gaining traction like it has been. It's probably the best we're going to get in a long time when it comes to reaching normal people and that's a fact we're going to have to live with imo.

>>11257 >>11246 Agreed. >>11214 >Tox is currently in the middle of a full rewrite of the toxcore libraries This is good news! I've always liked tox conceptually but have been wary of the code quality. I really hope it can someday become a reliable signal/whatsapp replacement because it does a lot of things right.

>>11214 Also, how can I get added to tox chats? Is there a web portal somewhere to make the bot invite me, or do I just need to talk to someone?

>>11246 >The terrifying thing is to try to comprehend how WhatsApp has 2 BILLION users "Because everyone else has it!" Unless the app is literally harmful in the sense that it physically wounds you when you use it, nobody gives a fuarrrk about their data, privacy, censorship, freedom, etc. etc. until it directly impacts their well being. People are perfectly aware that they're being cyberhumped by Facebook but for normal people that's not as important as being in with what everyone else does and being normal like everyone else.

>>11267 >that's not as important as being in with what everyone else does This point becomes very clear when they complain about having to install another app when you ask them to add you on signal or whatever. It's like... motherfucker I know for a fact you installed some chinese gachapon adware garbage just because your friends started playing it. You can put up with one more messaging app on your phone to talk to me.

>>11269 Recently I left a more obscure service and asked this person I was chatting with if he wanted to keep in touch on a couple other places. He was like "ok I'll look into it". Then when I left the service a while later he didn't ask for a handle or anything. I said ok then cya later, left. I assume people who do this didn't want to talk to me in the first place but why? If I don't want to talk to someone I avoid them, I don't have conversations.

How I am supposed to use signal if I don't have a tracking device?

>>11271 You don't, that's the main problem with it. Did you read the thread?

>>11185 >>11188 >mandatory cloud backup of contacts & other info >the devs seem to view this as a step towards alias/usernames as an alternative to phone numbers It's just an excuse. How would such a backup be necessary in order to have usernames instead of phone numbers?

You should always use burner phone, with anonymous SIM-card bought with cash and "stored" for enough time, so it's truly anonymous. No surveillance video of purchase or so.

>>11282 When group is rotating phones, discard all phones, and start using new ones. Without any connections between the old and new circle.

>>11283 so a new group and a "group 'signing' party" like a "key signing party"?

>>11282 Cash is not "truly anonymous" to begin with so your concept of true anonymity is definitely flawed.

>>11293 "Bought with cash" is 2020 euphemism for "stolen".

>>11299 Only burgers are forced into credit cards for social score pardon credit score. Cash is very much alive outside of it. If you're in the South of Europe on vacation you can go to a mom&pop shop and get a sim for under 4€. Cant load up for home though, they stop working past the border.

>>11303 >If you're in the South of Europe on vacation you can go to a mom&pop shop and get a sim for under 4€. They want an ID for it

>>11352 depends, in Romania for example mandatory SIM registration has been declared unconstitutional multiple times by now. I would say this is definitely an outlier case though, because in many other european countries people have grown complacent enough not to care about this type of thing.

>>11352 been in spain on multiple visit and never got asked for id. As if grandma even knows what the current laws are.

>>11352 Just buy the burner with cash, and stash it for suitable period like one year. Meaning that potential surveillance footage of the purchase isn't probably available anymore. I never show id, newer pay with card, and if feeling paranoid, I'll ask a friend to bring me burner from somewhere so even the purchase location is meaningless.

>>11292 Yes, with no links to past nor any links out side the circle. Any links outside or to past, will make the operation more or less useless.

Anyone else having trouble with Signal today? Seems like the servers have been down for a few hours or something but I can't find anything about it.

>>11163 I don't like signal because the reasons you said in the opening opst and because the soykaf needs the G**gle play services to work. And signal-desktop is made in electron. And I hate electron (And anything that abuses JS (Electron for example)) I think XMPP rocks. And it rocks very well. It supports easy as soykaf to setup encryption (OMEMO just works, but you can also use pgp/gpg if you're whacked out paranoid like me) The problem? All XMPP clients are garbage. And the less bad (https://dino.im) is only available for GNU/Linux (And probably BSD systems) For Android, the less bas XMPP client is conversations (https://conversations.im) I personally use Dino and Conversations. But some clients like Gajim are ok. Pidgin is like kicking dead whales down the beach for xmpp though

>>11453 It doesn't need Google Play Services, what are you talking about? I run it fine on LineageOS without Google Play Services. Hell, it isn't even the usual situation where an app says it requires them because it relies on them for notifications (the ProtonMail app comes to mind for this - also works fine for me but I just don't get push notifications), I've never had an issue. >signal-desktop This is a valid complaint. I have to re-sync to my computer everytime I want to use it, and in doing so message history gets lost (which is to be expected but can still be a pain in the ass).

>>11458 >Doesn't require Google Play Services Really? It used to require them last time I tried Signal (6 months or so) Very nice to hear that.

>>11460 This has been the case for years. I've also been running lineage with no google apps.

>>11460 do notifications work without google play services?

>>11469 You have to enable "always on in the background" which signal tells you to do when you set it up. And then you have a constant notification that signal is running which is a little annoying. Supposedly it drains battery faster but it is negligible. Signal at least autoupdates itself (or tells you it wants to) which is okay.

Matrix is terrible wrt metadata, and you have to set up or depend on some random server, no? Which is a benefit for some people, but not so much for large businesses. I am about to recommend my organization use Signal. We used to use Keybase but are searching alternatives after the Zoom acquisition. I guess change my mind? Plz ty

>>11473 Organizations used to run their own email and xmpp servers in past, the good ones still do. Centralizing your communications around single point of failure locked-in service in some foreign 5 eyes country (US) with no legal obligations of your data safety (do local backups, manage logs, etc) is below room temperature (Celsius) IQ. >We used to use Keybase but are searching alternatives after the Zoom acquisition Tell them to stop being attentionwhoring hype animals for a moment and think logically. It literally changed nothing in terms of software quality, you used one third party locked in infrastructure service, and decided to change for another because... reasons. This "acquisition" is similar to Signal team doing software development for Facebook's WhatsApp, a simple marketing stunt for bigger crapware company to promote it's service to "privacy-conscious" idiots, it does not incidentally prove the original service and software becoming less trustworthy that scares another batch of more paranoid "privacy-conscious" idiots.

What is the bad track record of Wickr? Aside of being closed source, I never really saw anything bad about it.

>>11473 signal is designed more as an sms replacement than an enterprise chat service. everyone has to be cool with giving out their phone numbers to their coworkers and anyone who might have access to their coworkers' phones. also, the desktop client is totally gimped so you pretty much have to use your phone, which people like me hate doing. self-hosting is the way. you can get a pretty slick enterprise chat system with well-configured xmpp (jingle for misc peer to peer signalling, video chat with jitsi meet, sip integration, dns config so xmpp addresses double as emails). it just takes some know-how. if you can't do that, just use matrix. there's also rocket.chat but i can't personally recommend it because i've never used it, but i've heard it's supposed to be fairly idiot-proof.

>>11163 >I'm not sure how organizational politics it should get (such as Moxie Marlinspike endorsing WhatsApp because it uses the Signal protocol), because most laypeople probably won't know or care about how the Signal foundation is run and by who. & I feel the thing about their fed donors doesn't make them less reliable than the tor project in that respect. I'm very interested in this, could you elaborate? >also check out antox in F-Droid and q/uTox for gnu+linux

bump

>>11473 Signal requires google basically >matrix not much better

>>11566 Also

>>11567 Is this the real botnet?

>>Trust On First Use Obviously, this is a huge problem. Specifically, I don't want to trust anything. Trust is something that is outside the scope of cryptography. The only thing that's assured is that whatever data is sent to that identity is accessible only through the decryption key of that identity, and whatever data is sent from that identity passed through the signing key of that identity. By default, the only thing that's assured is that the data passed through those keys in that way. By default, you don't know anything about what is beyond those keys. It could be your friend who gave you the encryption or verification key. It could be a group of persons that have some agreements about how to use those keys. It could be a threeletter agency. The fact is, you don't know. And you don't have to know. What you can do is fulfill your due diligence of examining the history of that cryptographic identity before making any significant decision involving that cryptographic identity. (Or you can outsource much of the work to someone else who prepares a report---with all the proof---about the history of that cryptographic identity. That would be cheaper, so that the work is done once, for each person who want's to examine that cryptographic identity. Some work might need to be done by each person, such as checking a shared secret that is unique to the two of them.) Then, after understanding the history of that cryptographic identity, one might decide what sorts of interactions to have with that cryptographic identity. There's no need for something as dangerous as trust. There are only actions, and consequences. The consequences of an action, of course, are a probability distribution. What you decide to do with that cryptographic identity might have some danger, some risk, but it would be a risk that you understand, and that you properly compensate for. Probably, having seen the possibilities, and their probabilities and values, you choose the action that has the greatest expectation. There's no need for trust---an understanding of the possibilities, and their probabilities and values, suffices. >>must have a phone number >there's a certain level of trust it takes to even exchange this information in the first place, & of course your number will be shared with every group chat you join. There's a workaround we found where you can use the desktop app to register a number with a burner phone or google voice number, IIRC. The problem is that telephone addresses are not inherent to cryptographic authenticity or privacy. Wouldn't it be better to adjust the signal libraries to allow any arbitrary identifier? For example, a PGP fingerprint. It's possible to use all of Signal's features, except for calling or texting a traditional telephone number, without any telephone connectivity. Sure, you might not get the warm-fuzzy feeling that you know with whom you're talking, but that warm-fuzzy feeling is dangerous. Feeling safe is dangerous. Being safe is what's important. Instead, if you really want, you can have someone person tell you the encryption/verification keys of a cryptographic identity whose decryption/signing keys he exclusively controls. Naturally, you'll never know whether he exclusively controls those decryption/signing keys, but you can put some social pressure on him to do everything he can do increase the probability that he exclusively controls those decryption/signing keys. What that means, is that there are still some thing that you'd only discuss with a person directly---in the flesh, each whispering into the other's ear, in a soundproofed room filled with noise to mask the whisper. Likewise, there are some things that you would only discuss via a cryptographic identity that is in no way associated with any other identity. >The problem is that people who browse lainchan and read lainzine aren't laypeople, at least not when it comes to technology. The problem is that many a person who isn't a layperson (about whatever, but we're talking about informatic techniques) doesn't demand the ability to be layperson when not working on the thing about which he's a nonlayperson. I might know a thing or two about informatic techniques. I also know that I'd rather be not bothered by implementation details. That means having a clean, simple interface, that does exactly what I think it does. That means, in the example of encrypted messaging, having a single command: send, that asks the user only what to send, and whither to send: send <<recipient>> <<message>>. That command would know (based on prior configuration, obviously---unless your computer hacked into your mind) that, the recipient is this, then sign the message data with this key, then encrypt the signed message with that key, then transfer the encrypted signed message by this transfer method (e.g. from this email address to that email address, or by posting it to that internet forum, or by hiding it in a photograph and uploading that photograph to that photograph host then sending it's resource indicator to the recipient,, the list goes on as long as we are creative with our possible ways to transfer some data from one place to another), after which point it's up to the recipient to get that data from where it was sent. For receiving messages, a background process would check (at random times, via TOR,, some what that makes it difficult to associate with my identity) wherever there might be a message to me, downloading all that data, finding whatever might be a message to me (trying to decrypt it if it looks like it might be an encrypted message to me), running it through my decryption/verification procedures, storing everything that is a message to me in an incoming messages folder. Later, at my leisure, I check this folder for new data (new messages), and reply, if I so choose, or otherwise become informed by, the messages, again: at my leisure. On the whole, this is among the simplest interface for interpersonal messaging, because the only thing I ever have to do is run the command <<send <<recipient>> <<message>> >>, or configure what security/transfer methods to use for which correspondents. The only thing that might be difficult for a layperson is that I use the commandline, whereas they might want a pretty graphical messaging application, but that's a matter of wrapping it up. I might like a graphical interface if I want to do it from a pocket-computer, but I'd have to have a less dangerous pocket-computer for that. The graphical interface could be equivalent to whatever popular messaging ``app,'' but as an interface to whatever method to send a message to a person. I'm surprised that such a neat interface hasn't been made in a way that many a layperson could easily use, but not only that, but also that many a layperson would be convinced they would be able to use without a fuss. For starters, one might make an interface that's just like Signal, but with modular message sending/receiving methods (each of which may be themselves made of modular parts e.g. for different cryptographical authenticity/privacy methods, different transfer methods). In fact, such a ``meta'' messaging app doesn't even need to have encrypted messaging. To some, the fact that most of his friends are on this or that restricted messaging app, he's going to use it, too, and not see a reason to use another messaging app, because he'd have to get his friends over to it for it to be worth it. With a ``meta'' messaging app, that wouldn't be as much of a problem, because he can continue messaging with them from the ``meta'' messaging app, but also, with the benefit that, if he has another friend that's using a different messaging app, you'd be able to message him, too, all from one app. This makes the ``problem'' of one security-conscious person insisting on using this or that secure messaging method, not a problem, but a good reason for all his friends to switch to such a ``meta'' messaging app. The fact that all it's parts are modular would mean that making messages with this or that person as easy as exchanging keys. The key is to make it so that it has a clean interface.

>>11570 >Instead, if you really want, you can have someone person tell you the encryption/verification keys of a cryptographic identity whose decryption/signing keys he exclusively controls. Signal supports this. It's called "verifying someone's key"

>>11570 SSH uses TOFU. You're taking the name far too literally. In Signal as in SSH, it is upon YOU to verify the key. They're also working on allowing you to use Signal without an associated phone number. You spend a lot of time and effort describing mixnet messaging. Your entire post feels like the pinnacle of Dunning-Kruger "I am very smart" ranting.

>>11453 ChatSecure for iOS, supports OMEMO, OTR and can connect through Tor.

>>11566 >>11567 >>11568 Matrix is just a really soykafty protocol / client made by yet another lazy venture meme organization that is trying to make yet another "free, decentralized" thing they'll sell out in toto when the petabytes of porn people exchange on their central server makes it collapse. Such is the fate of every free messaging server. These companies use Google/Electron because it's the cheapest way to make their thing just werk. They know it won't last. P2P is probably the only way E2E encrypted messaging can be viable, because you only have to work on the client. For everything else there's IRC, IRC will probably still be alive 10 years from now, I doubt any of these services will be.

>>11653 >P2P is probably the only way E2E encrypted messaging can be viable Fwiw matrix is working on an update to the new dendrite server that will enable p2p. Idk all the details, I think the idea is that the "server" is light enough to be run locally or embedded in clients, but if you're curious I think they had a blog post about it recently.

>>11570 Gen Z invents Pidgin: the post.

>>11163 >Gboard >smartphones just have a keylogger in them, by default, for predictive text. I'm unsure if Signal prompts you to at least use incognito mode (as if you could trust that) at first. What can we do about this?

>>11765 Easy: https://f-droid.org/en/packages/com.menny.android.anysoftkeyboard/ https://f-droid.org/en/packages/org.pocketworkstation.pckeyboard/ There are other options too but these are the two I have used.

>>11766 Now make every person on the other end install this "virus". I dare you.

>>11766 I will look into these. Thank you.

>>11776 I guess I should have noted the context here. Of course if you're talking to another person their keyboard is a concern. Still, you gotta use a foss keyboard that doesn't log. Its a baseline precaution.

Earlier this year, I finally took the time to revisit the state of instant messaging services. My requirements: - open source - cross-platform (linux, mac, windows, ios, android) - group chats - end-to-end encryption - well-understood crypto ciphers & protocols - mature enough for a reasonable expectation of security & privacy - easy enough for most computer users - some way to protect metadata (e.g. self-hosting) - signup without real-world ID - offline message delivery I ended up choosing the Matrix network. The reference client is called Element[1] (formerly Riot). There are things I dislike about the client, but they're pretty minor compared to the benefits of the underlying protocol, and lots of alternative clients are in development[2][3]. On top of meeting my requirements, all signs indicate that development is both active and moving in the right directions. Reading the team's weekly reports and issue tracker convinced me that they are making very sound decisions. [1]: https://element.io/ [2]: https://matrix.org/clients-matrix/ [3]: https://matrix.org/clients/ Here's what I didn't like about the others: Briar: Lacked cross-platform support and (iirc) offline messaging. Tor brings baggage that not everyone is ready to accept. Cwtch: Not mature yet. Jami: Very fragile code base in my experience, which was also true when was called Ring, and when it was called SFLphone. Only about 25% of the builds I've tried over the years actually worked. I was unable to determine whether it had offline messaging. Keybase: Now owned by Zoom, which is a privacy nightmare. Ricochet: Same problems as Briar. RocketChat: Crypto is not mature yet. Session: Not mature yet. Small limit on number of group chat participants. Signal: Required phone number for signup. Required Google Play Services (aka spyware) for quite a long time. Weak cross-platform support. Some of that is finally changing, but Moxie will surely make more intolerable design decisions, and refuse to fix them for years, again. Telegram: Homebrew crypto. XMPP: Most clients are hard to use (or to teach others to use). Good servers are hard to find. Protocol standards are a mess. I couldn't find a real-world e2ee group chat implementation. Everything else: Failed to meet my requirements even before I looked closely, mostly due to closed code and/or problematic corporate interests. (For example, I will not use an app from Facebook or any of its subsidiaries.)

>>11784 I will say some of the complications of xmpp are alleviated if you run your own server. This is easily done on a super low end budget vps. If you run the server you can ensure it has all the features you want, and "here I'll give you an account on my server" is an easier sell than "just go make an account on conversations.im or whatever... they seem trustworthy I guess". Also the e2ee group chat thing is annoying to get working for sure, but thats less of an issue if you run the server (still a problem though, I won't deny it). Clients may or may not be an issue. There are nice idiot-proof options for android and iOS, and presumably anyone who is going to want a desktop client is probably with it enough to weigh the many options and decide which one they want to use. However if you get someone who really wants a windows client they're going to be kind of a second class citizen because windows doesn't have any really good options. You probably made the right choice with matrix though, especially if you self host. I'm planning to try it out myself once dendrite is a bit more complete.

>>11784 >I couldn't find a real-world e2ee group chat implementation. What do you mean by this? I assume you know about OMEMO.

>>11791 What's wrong with megolm?

>>11784 About XMPP Your research is soykaf. I wrote and I'll write again: You have OMEMO for encryption, is well-understood and works on groups. It's crossplatform, maybe scattered, but it's ok. Android: conversation.im iOS: chatsecure.org Linux / MacOS (Gui): dimo.im Linux / MacOS (TUI): profanity-im.github.io Windows/MacOS/Linux: Pidgin Servers: If you don't trust any server either look for someone you trust that can host it or host it your own. - prosody.im (what I'm using and I'm happy with it) - Tigase - ejabberd.im - ... Also, protocol standard are not a mess, just RTFM. Otherwise, fallback on IRC + Email.

>>11852 >>11784 dino.im sorry

>>11853 conversations.im *

>>11838 https://matrix.org/docs/guides/end-to-end-encryption-implementation-guide

>>11163 Backups are encrypted by default now AFAIK. Also someone else mentioned that Android is now encrypted by default - this encryption is pretty bulletproof from what I've heard. >>11165 Just don't allow it permissions you don't want. Your OS should support this - if it doesn't then it's time to upgrade. It only ever asks for them when it needs them. (E.g. when you share location it'll prompt you to access location - it's never asked me or used that permission otherwise).

>>11185 >>11188 >>11274 is this now finally optional? ive been checking and couldnt understand https://www.vice.com/en_us/article/pkyzek/signal-new-pin-feature-worries-cybersecurity-experts https://community.signalusers.org/t/dont-want-pin-dont-want-anything-stored-in-cloud/14057?page=13

>>11950 Yes and no. https://mobile.twitter.com/moxie/status/1281649696507715589?p=v

ok so google play is no longer necessary and this pin/backup thing is being sold as the first step towards usernames.. but are they actually working on not asking for phone numbers?

>>12086 >but are they actually working on not asking for phone numbers? Mathematically unlikely

>>12086 >ok so google play is no longer necessary Really? Where does one get the app then?

>"Download for Linux" >click >doesn't work >enable 3rd party JS >doesn't work >allow the getclicky stuff that gets filtered in the logger >doesn't work >disable umatrix globally >doesn't work >disable all extensions >doesn't work >try to inspect the page to see if I can get the plaintext instructions with the PPA or whatever it is >nope Same on Fennec. This is not preventing me from installing, but why you do you want me to click on a crappy javascript button that doesn't even work on a browser other than Chromium? I refuse.

>>12091 You can get the app from https://signal.org/android/apk/ but you have to allow js on browser for signal.org (website also tries to connect to getclicky.com but its not necessary)

>>12093 >pacaur -S signal-desktop >it just werks

>>12093 The download button on https://signal.org/download/ shows this for debian-based os: curl -s https://updates.signal.org/desktop/apt/keys.asc | sudo apt-key add - echo "deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main" | sudo tee -a /etc/apt/sources.list.d/signal-xenial.list sudo apt update && sudo apt install signal-desktop

>>12093 Works for me on Firefox 79 with uMatrix. Sounds like a "you" problem, not a "them" problem. I usually keep a separate profile around that doesn't have any extensions so I can determine if the problem is with the site not liking non-Chromium browsers or if it's an issue with some setting/add-on I have in my daily driver profile. Might be worth it to you to try out.

>>12096 >>12095 >>12094 I know, but my point wasn't that I couldn't get to the download.

>>12098 >Works for me on Firefox 79 Yeah of course it does.

>>12100 Did you try typing all that nerd text into your teletype maniframe console, big brain?

>>12130 I am not him, but it doesnt work.

>>12130 have you actually read the posts?

>>12132 Yeah, it started with some lain bitching about it not working on non-Chromium browsers, to which it was shown that it does indeed work on non-Chromium browsers. Just because it doesn't work with their vulnerable, outdated version of Firefox? The fuarrrk outta here. >>12093 >>12098 >>12101 What was the point? This just seems like a COINTELPRO nitpick psyop, complaining about soykaf that is a literal non-issue to sow discord (pardon the double entendre). Stirring up contention and consensus breaking is literally their playbook. https://cryptome.org/2012/07/gent-forum-spies.htm

Anyone know about this? >VoiceCall Exploit >geolocation based on the voip server it uses https://mobile.twitter.com/spyphone2010/status/1297933829999661056?p=v

>>12662 Some random tweet that doesn't cite any sources?

> As we know, Signal is not the best choice for digital security > No federation o rly Instead of solving the fragmentation problem in the market, you make it bigger.

>>12889 I use Signal. It's basically WhatsApp which means it's feasible to convince people to use it. Signal's tight control over the project means it is basically a given that it will get taken over by a for profit company eventually.

>>12889 Certain threat models favor centralized service over federation, given the predicted behavior of client software: in most cases this also means higher anonymity set: a global observer sees many people connecting to one Signal server regardless of their intents versus small federation of XMPP servers with unknown security practices of individual hobbyist admins who might be susceptible to give up logs, blocked or something else. Sending all comms over Tor regardless of their destination is the best practice, but not all people are savvy enough to do this properly and do tech support for others, but there is a protest to attend tomorrow.

Any thoughts about Wickr RAM?

>>13114 All the things about how its NSA and DoD approved pretty much confirm that its almost certainly backdoored and not actually secure. The marketing looks like its aimed at LARPers who think they're some super special militia too. Avoid.

>>13114 hahaha I don't want to spread FUD because idk soykaf about whatever that is but >Built for the warfighter if that isn't an FBI/ATF honeypot idk what is. Also, I didn't know the DoD was in the business of "validating" cell phone apps. Are they saying they're a customer, or is that just like how "military grade encryption" is marketing-speak for "RSA"?

>>13114 Never heard of this, also it says FOUO/PII which literally just means it is rated for some forms of information like peoples names, and unclassified but somewhat controlled information. This sounds too much like larping. Most business tools are just isolated networks or if it isn't classified it uses commercial security. DoD uses encrypted IRC for actual chatting https://www.wwt.com/case-study/tactical-chat-solution-navy/

>>13114 my immediate thought is that they're trying to market to LARPers and mercenaries. It's probably about as secure as Signal. >>13124 >Are they saying they're a customer, or is that just like how "military grade encryption" is marketing-speak for "RSA"? almost certainly the latter.

Adding Encrypted Group Calls to Signal https://signal.org/blog/group-calls/

>>12662 > VoiceCall exploit Patched the same day it was reported and fix was in place before it was ever publicly disclosed. Yawn. > geolocation based on the voip server it uses Voice/video calls are done peer to peer (unless it's a group call), or you can set it to use a Signal server as a relay to avoid IP exposure. If your threat model doesn't include a global passive adversary then this should be plenty sufficient. If your threat model DOES include a global adversary, then you shouldn't be using realtime communication protocols, period. > still register with phone number Phone numbers will no longer be a requirement soon, they've been working on refactoring everything to make that a reality. > Code your own, as I do. Right. That'll end well.

>>12904 > Signal's tight control over the project means it is basically a given that it will get taken over by a for profit company eventually. No, being a non-profit means that they don't have any incentive to sell out their userbase. $50M goes a long way when you run a pretty lean operation like they do.

>>13114 To me this screams honeypot for right-wing militias.

>>13114 There's a few ways to look at it: Like this: >>13601 Or as a honeypot for clueless foreign militias (like ISIS type idiots) Or as pure marketing speak for LARPers (which doesn't imply a lack of security, but should make you doubt it) Or as a government tool that they somehow made available to the public (a generous interpretation. An easy test of this possibility is to see what kind of export restrictions are on it) Or as a gimped government tool for the clueless masses (not necessarily backdoored, but not government-quality security. Also, check the export restrictions since it'll give you a sense of how trustworthy it COULD be, not how much it is) I'm placing my bets on the marketing for LARPers and/or honeypot. I'm not interested enough to look at the export restrictions, but I expect you'll find it is "internationally available", which means it's soykaf-tier.

>>13599 >Phone numbers will no longer be a requirement soon Idk if I even believe this any more. They've been saying this for several years now and instead of focusing on it they've been doing soykaf like cloud backups and integration with facebook's stupid gif repository thing. Maybe that stuff is more important? Certainly isn't to me, but what do I know.

https://web.archive.org/web/20201210150311/https://www.cellebrite.com/en/blog/cellebrites-new-solution-for-decrypting-the-signal-app/

>>13608 Of course you can decrypt messages and attachments on a device on which the key is stored when you have full access to that device.

>>13606 The people that are implementing GIF search are not the same people creating an entire framework for secure value recovery. They've been completely retooling the infrastructure to make this happen, and they publicly announced all the work they had already put in place a year ago. https://signal.org/blog/secure-value-recovery/ I guess it doesn't matter if they are pushing the state of the art for secure messengers, if it's not 100% perfect from day one people will still throw a fit. >>13608 https://twitter.com/moxie/status/1337434126186553345 Pure FUD marketing bullshit pushed by Cellebrite. Way to take the bait.

>>13613 This is some top tier larping. Thanks for sharing the tweet I was starting to worry.

>>13608 >>13613 >>13612 Usual moxie things to say "everything is fine" on a dead non-libre project https://signal.org/blog/cellebrite-and-clickbait/

>>13654 ??? it's probably the only time him being real since it's such a nonissue

https://twitter.com/qwertyoruiopz/status/1342061545006788608

WhatsApp failed? They're combining data with Facebook. If you still got WA installed, it's time to uninstall.

>>13807 >They're combining data with Facebook Someone just got thawed from cryosleep.

>>13661 Whatever they were referencing got deleted, and I can't seem to find any info on what they were talking about.

Just wondering what kind of thoughts you guys have about the fact that Signal is owned by Twitter. Do they share any data with Twitter or? OR what are the actual ramifications? Is this the true reason they're so hard after phone numbers?

>>13840 Whisper Systems was the company aquired by Twitter in 2011. Moxie left and started Open Whisper Systems in 2013, then with Brian Acton in 2018 he founded the Signal Foundation, which is not part of Twitter.

>>12091 Aurora Store I guess

>>11653 >P2P is probably the only way E2E encrypted messaging can be viable, because you only have to work on the client. This is why I use Tox. It's just a protocol and a series of clients. It can't be bought out or backdoored. If the dev team dies, the network continues to exist uninterrupted. No deplatforming bullshit to worry about. But having a pure p2p app has a lot of downsides too. There are some features that are basically impossible to implement, or hard enough that you need people working on it full time.

>>13864 I'd like to compare it with https://cwtch.im/

>>13864 A lot of the connectivity downsides can be worked around by relying on a secondary networking layer, like some meshnets or darknets. That has the implicit tradeoff that you're now dependent on an external project.

>safe usage >phone number ok

>>11163 >Gboard >smartphones just have a keylogger in them, by default, for predictive text. I'm unsure if Signal prompts you to at least use incognito mode (as if you could trust that) at first. Chinese dissidents using Signal have gotten busted in the past, likely due to their keyboard/IME leaking data. Some Chinese people who get past the firewall have been pestering Moxie to do something about it, either put a soft keyboard in the app itself (like banking apps do) or show a disclaimer or at least acknowledge that this is a risk. For some reason, the Signal PR absolutely refuses to engage in any bit of this conversation. Naomi Wu, who has 150k followers has been trying forever to get this side-channel attack into the limelight and Signal keeps pretending it doesn't exist. https://twitter.com/RealSexyCyborg/status/1349959023940886529

>>14032 Interesting project. Here are some differences. Cwtch: >metadata resistant >detailed threat model >actual security researchers >text only >Go Tox: >"Tox makes no attempt to cloak your IP address" >"TODO(iphydf): Define one." >unknowns who changed multiple times >audio and video >C Both claim to have E2EE and forward secrecy. Neither have security audits, but Cwtch's website doesn't imply that it's usable yet. And finally there's this https://github.com/TokTok/c-toxcore/issues/426 >We have a largely undocumented, untested, and not well-understood code base of about 19 ksloc (C). >Tox provides some strong security guarantees. We haven't got to the point where we can enumerate them properly, given the general lack of understanding of the code and specification.

>>13864 >P2P Personally I think that worst part of P2P is the maintenance and up-keeping cost of the network and storage. It's not a problem with servers, but it's a huge problem with mobile devices. Basically anything can be implemented on top of P2P, but it's just not going to be as power efficient as it's with client server model, where the server handles all the heavy lifting.

>>14122 I'm not sure I buy that. Kademlia DHT, for instance, is pretty lightweight.

>>14122 Maybe in some instances, but imo reliably connecting to a device which is behind a nat is a bigger problem. It always entails some kind of persistent connection to the network. P2P could be a lot less chatty if your device could always be assumed to be reacheable as long as it is powered on and connected to a network. I actually like the approach some p2p chat software is taking where it's just a regular chat app that happens to be designed to run as a tor hidden service. That way you automatically get NAT piercing, anonymity, and encryption.

>>14125 That's exactly why Briar got options to keep it connected only when phone is connected to charger and or WiFi. Of course networks like that could have layered system of "super nodes" and "leaf nodes". Where computers can run the super nodes, and mobile devices could just choose a super node to use as a relay. - Just as Matrix does... I could run "Briar mailbox", but it seems the project is more or less dead. Briar mailbox is a relay service, which can store messages between user A and B, if they aren't online simultaneously.

https://github.com/signalapp/Signal-Android/blob/7e64d57ba8fc8ac295c7c35279fba2bf6400655b/app/build.gradle#L111-L119 /!\ Signal routes their traffic through cloudflare, amazon microsoft and google /!\

>>14218

>>14218 It does not matter, that's the point of E2EE

>>14226 it means 1) all of those companies could randomly decide that Signal is not allowed 2) all of them can get metadata info easily

>>14044 They're starting to address it. There's a PR that was last updated 7 hours ago as of this writing. Here's the thread discussing it: https://community.signalusers.org/t/signal-should-warn-users-who-are-likely-using-insecure-ime-apps/10272/190

>>14230 1) they're not going to run their own servers, so whoever is doing that for them could kill them anyway. On top of that, their domain provider could do that too. Or law enforcement. Or their ISP. 2) the origin user of a signal message is E2EE, as well as lots of other data such as sending time. Very little information is leaked

>>14230 If your threat model is a global passive adversary, then any kind of near real-time comms is not the tool you should be using.

>>14237 Agreed. That's the wrath of covcom. Any IM / low latency messaging directly (or indirectly) connecting you, is fail.

I've always thought that platforms which combine specific things are more or less snake oil. When data storage, delivery, encryption, encryption keys and plaintext are all handled by the same party, it's inherently insecure. I wouldn't ever connect the device to a network, which handles the plaintext / encryption keys. Always keep those separated and absolutely minimize the interaction between the systems.

>>14226 Remember that Cloudflare can decrypt the TLS :-)

>>14256 Do you not know what E2EE means then?

>>14258 Yes, but it's stupid to wage slave yourself as a "privacy respecting" app and then use cloudflare

>>14294 Go back to nanochan, schizo.

>>14302 > he posts on lainchan > calls other people schizo > thinks this is an insult > on lainchan, of all places you might want to go back to twitter or whatever hell hole you crawled out of

>>14071 >And finally there's this https://github.com/TokTok/c-toxcore/issues/426 The KCI attack is a serious issue with SSL/TLS because a server can force a vulnerable client to use an insecure handshake, which gives them access to the client's private keys, wherein they can impersonate the client and do other nasty things using said private keys. Tox generates your private keys locally/offline. The only way for this flaw to be exploited is if someone gains access to your device, or if you expose your own private key. It's an academic flaw with no real world relevance. With that said, it does look like they're working on fixing it: https://github.com/TokTok/c-toxcore/pull/1561

>>14306 I disagree, errors in the code could compromise secret keys while they are in use. IMO, static keys shouldn't be used for encryption at all. They should just be used to sign ephemeral keys.

>>14306 >With that said, it does look like they're working on fixing it: Kind of surprised they haven't done so already. I remember reading that issue actual years ago. I like what tox is trying to do and hope they're successful because it's perfect for talking to strangers you meet online without doxxing yourself. Somewhat related: what's the deal with session? https://getsession.org/faq/ It's been on my radar for a bit, but I never bothered trying it because there's no option to federate. At least there's no phone numbers and more things seem to be handled peer to peer. I'm not actually sure how much their servers actually do. Seemingly more than just basic bootstrapping but less than the full account management you get with other similar software.

>>14314 Looks like it's based on Loki, which is an onion router using cryptocurrency at the core. Nice idea I suppose but it inherently makes the network exploitable by anyone with a lot of money. The service nodes are part of the onion router and just store messages in exchange for Loki coins.

>>14321 >Nice idea I suppose but it inherently makes the network exploitable by anyone with a lot of money I wouldn't say "inherently" but yeah that's a worthwhile question to pursue. The biggest potential danger I see with this scheme is that you're tying the operation of nodes to market forces, which can of course be manipulated with enough money. For instance, dumping a lot of crypto on the market might reduce the number of nodes in the network because running one becomes less profitable. However, controlling a lot of crypto doesn't immediately give you the ability to do anything special with people's messages, at least not anything I can think of from my somewhat naive perspective on it. Honestly I'd rather just see good traditional peer to peer comms with traditional federated servers for things like peer discovery, signalling, NAT piercing, etc. There are ways to do all of this in a property decentralized way, with DHTs and such, but I'm not convinced the added complexity is worth the benefit of being (almost) truly serverless. Maybe a compromise would be to do something like bittorrent where anyone can host a "tracker" of sorts, which tends to be more reliable, but also provide an option for distributed peer discovery for those who would prefer to do things that way.

>>14322 >However, controlling a lot of crypto doesn't immediately give you the ability to do anything special with people's messages It wouldn't give you the ability to read their messages but it would give you the ability to de-anonymize their IP addresses. >Honestly I'd rather just see good traditional peer to peer comms with traditional federated servers for things like peer discovery, signalling, NAT piercing, etc. I'm working on one right now ;) expect a thread on lainchan in a week or so once I get the protocol nailed down.

>>14321 >Nice idea I suppose but it inherently makes the network exploitable by anyone with a lot of money. I don't understand this thinking. Every system is exploitable to people with lots of money. Cryptocurrency based incentives are just upfront about it.

>>14325 >Every system is exploitable to people with lots of money. Cryptocurrency based incentives are just upfront about it. If you do it right, they at least need to be clever too.

>>11163 Did you end up writing the page on this topic?

https://seirdy.one/2021/01/27/whatsapp-and-the-domestication-of-users.html

https://resist.berlin/goodbye_signal.txt

signal is pretty soykaf, people who are now moving to it from whatsapp will be disappointed. aside from the possible glowie soykaf, it has performance issues, and things like messages not being received until you open the app, which kind of makes it pointless, not to mention makes the app lag like hell as you suddenly receive 1000 messages while it loads them one at a time. i used it for a few months after i convinced my friends to move away from whatsapp but we all hated it and ended up moving to xmpp, it's a much better experience overall. as the other lains said it's very easy and normans-friendly to set things up, even on a phone. >>11190 >Do conversations.im & chatsecure do encrypted group chats? conversations does, but only private ones, which is what matters. no clue about the ios apps. >>11282 no such thing as "truly anonymous" >>11458 it uses google play services if it can find them, but it does work without them >>11453 pretty much this, conversations is by far the best client, it would be great to get something as good on pc, closest is dino

>>14382 > possible glowie soykaf FUD > it has performance issues, and things like messages not being received until you open the app I've never had this issue, sounds it was being prevented from running in the background (possibly due battery or data restrictions?). I've had far more success getting normal people to convert to Signal than anything XMPP based, but that's just my anecdote.

So well, matrix is kind of retarded, and it allows you to pick info of any user as long as you have its email (i.e. you can find if someone has a matrix account by just having their email, you don’t need to have a matrix account, you only have to know how to use curl) https://matrix.org/docs/spec/identity_service/r0.1.0#association-lookup So matrix has this lookup API, in which you pass the email as get parameter and it will give you info about that user in JSON so i wrote this very uggy perl script #!/usr/bin/perl my @list; open($fh,"emails"); while(<$fh>) { push @list, $_; } foreach(@list) { chomp($_); system("curl -ss 'https://vector.im/_matrix/identity/api/v1/lookup?medium=email&address=$_\'|jq .mxid"); } which basically gets email form the file “emails” and requests the matrix API to get a mxid (the matrix identifier) you can generate the emails file using this ugly as soykaf command gpg --list-keys --with-colons |awk -F: '{print $10}' | grep -o "<.*@.*" | sed "s/<//g; s/>//g" | awk '{print $1}' > emails A privacy concerned IM, as they call it :)

>>14420 Oh noes, gaynigger@hitler.rocks has a Matrix account gaynigger@matrix.org!

>>14420 As far as I'm aware, this is all opt-in. Pic related.

>>14326 >If you do it right, they at least need to be clever too. Wouldn't that be security by obscurity?

>>14475 Most adversaries have a budget. You can thwart attacks by increasing the cost to exploit beyond their budget. Even if it's just obscuring things to a point that makes it so they turn up empty-handed to their next meeting with their supervisor. You can only come back without meaningful results for so long before some manager decides to scrap it. That's not to say that you should rely on obscurity, but if you can layer it with other real security practices it becomes a valid means of mitigation.

>>14475 Security by obscurity is only bad when its a main line of defence. Its a perfectly fine when mixed in with other layers of defence. Having it so your adversary actually has to put work into finding vulnerabilities instead of being being able to scrape them from 5 minutes clicking around because "muh security through obscurity" is an improvement.

>>14421 goddamn it how did you find my account

>>11163 Just host your own server and use Matrix toka XMPP toka protocols.

>>14314 It also seems to be a clone of signal somewhat, it has a very similar app. It was originally using the signal protocol too, but seems to be switching to a custom one.

Post your session ID ITT: 0507d7207d7742f43b0b3288b9860436e82f2de6896f41f0624f6e38ee850ec10b

>>11945 Bullshit, there are dozens of baked in permissions. Look it up on a good search engine

As of 2021 I still think secure messaging is purely a hobby/gossip since nobody uses anything but [insert most popular messaging thing] and will not move to whatever you are using. I barely god someone to switch to Signal, which I hate because upon installation it sends a notification that you signed up to everyone who has your number in the contacts. Telegram also does this. So much for "privacy" if you cannot even sign up without alerting every random person who has your number.

Any lainons know what that alternative more-secure signal frontend was called? It had a git page somewhere but I can't find it? It was a frontend for signal that could be run alongside the signal mobile client of independently. It had things like password protection and an encrypted database etc.

>>15289 Do you mean Molly?

>>15295 Thx, yeah that was it!

Molly is a hardened version of Signal for Android. https://github.com/mollyim/mollyim-android

Looks like Signal finally updated their server repo. Not sure why they didn't publish anything for nearly a year. Wish they'd be more open about it.

The recent introduction of crypto shot has honestly made my faith in signal drop dramatically. I'm still using it to talk to the less technically inclined folks and I still probably will. >>15347 This is cool but is bound to be killed by moxie at some point. I guarantee it won't last long.

>>15380 >The recent introduction of crypto shot has honestly made my faith in signal drop dramatically. Oh man, you weren't kidding. Even Bruce Schneier is calling out Signal's devs on this, and he's normally an extremely diplomatic dude, and also a fan of Signal. https://www.schneier.com/blog/archives/2021/04/wtf-signal-adds-cryptocurrency-support.html

It is 2021 and Open Whisper Systems still doesn't want you to run your own Signal server. They barely update the public source code. And instead of making it a priority to move away from phone-number-as-identity, they introduce some crypto bullshit. Signal is going the way of Telegram.

>>15388 It's annoying since I've only just started finding people in real life using it. How open source is it? Forkable?

>>15389 covered under GNU Affero. So, it is indeed free software... I really don't trust Open Whisper Systems.

>>15389 >How open source is it? Forkable? Theoretically, yes. Practically, not really. Your best bet is to help with the Dendrite (https://github.com/matrix-org/dendrite) project instead. It's being designed by the Matrix people as a the new reference server replacement. It's already much easier to install than the old reference server. Still beta though. They could use help with bugtesters.

>>15388 Just a heads up, OWS doesn't exist anymore. Its "The Signal Foundation" now.

from 2019 but still relevant https://github.com/privacytools/privacytools.io/issues/779

>>15380 >This is cool but is bound to be killed by moxie at some point. I guarantee it won't last long. Yeah, nobody with common sense would voluntarily use Signal after they started doing this soykaf. >>15405 And Signal still on top place in that site. After removing contrib flags to mark software with non-free parts that website is useless for me.

>>11163 >>11170 >Google Services I do consider this an issue, and it bothers me simply on the principle. Signal needed to simply offer two different apk builds and it would have been easy. One using Google Services (that falls back to Websocket without Google Services, this is basically what the current one is), one without any Google Services period (basically what tw-hx's fork is). They've been a pain in the ass about this, and I don't know why. There is a fork that doesn't removes Google Services, that being said I'm unsure how up to date it is kept in relation to the master, also I don't know if I entirely trust it? Would anyone be able to verify it, as well as the provided apks? https://github.com/tw-hx/Signal-Android/releases >Needs phone number to work Yes, this is an issue however Signal has claimed it is for the sign up process only currently. Also they have been planning usernames for years, I guess they're just slow or it's not high priority. That being said, there are a few (soykafty) ways around this. >Needs contacts I don't believe it *needs* contacts? I could be wrong. Either way, it's not like that info is plaintext. >Unreliable notifications This used to be an issue for me in like 2014, however haven't had issues in years on different phones. Also not using Google services, was back then. I don't notice battery drain now either, despite some claiming it goes up. >Servers hosted in the US This is my biggest issue, not exactly for just that reason. I HIGHLY think we need to push Signal into supporting Federation though. Moxie has spoken against it in the past loosely, but I didn't really think the points he made was valid. I dislike the idea that when the main server has issues, it takes down Signal as a whole. This is terrible. Secondly, yes government requests can be an issue, that being said there is nothing on the servers for the governments to grab freely. There is also the concern that if Signal starts doing something on their servers we dislike, we can't just setup our own fork of the server and continue talking to our contacts on the main server. This is the biggest issue imo. Good luck getting people to move over to your server. It basically defeats the entire purpose. >SMS/MMS, other apps can't read SMS I don't see this as a major issue. >Server source code Moxie stopped pushing source for a while to hide the whole crypto thing, which I heavily disagree with. That being said, it's not like it matters because you can't verify if the released source matches up with what they're running. It's just the principle of it that bother me. >Cryptocurrency This new announcement bothers me, this is something that should be offered in a separate app. If it is ultimately pushed, it really should be something like Monero. But they're really pissing off a lot of people, and we need to speak out against this imo. Signal is beneficial for IRL contacts, at this point in time I would never suggest it for someone attempting anonymity. I think it is a valuable tool for talking with IRL people, it is easy to use, has features, highly solid encryption protocol, but just has a few concerns. My biggest being the Google Services, Centralized (Un-federated servers), and the phone number issue. The cryptocurrency thing is still a bit unknown int he direction but I'm pretty against that. I would care less if they used Monero.

>>15434 >Also they have been planning usernames for years, I guess they're just slow or it's not high priority. That why is such a glaring privacy problem a low priority (lower than fuarrrking stickers) for an app that bills itself as a privacy app for activists?

>>15435 >why is such a glaring privacy problem a low priority (lower than fuarrrking stickers) for an app that bills itself as a privacy app for activists? Phone numbers also are there for historical reasons, when Signal was more SMS based. They also are a spam prevention measurement, that being said I think that's fuarrrking stupid. The only info stored is phone number and date that number last connected to Signal servers. Also it is a bit irrelevant, since the server does not authenticate sealed sender messages There's also this worth noting, https://signal.org/bigbrother/eastern-virginia-grand-jury/ The subpoena demanded: >any and all subscriber account information and any associated accounts to include subscriber name, address, telephone numbers, email addresses, method of payment, IP registration, IP history logs and addresses, account history, toll records, upstream and downstream providers, any associated accounts acquired through cookie data, and any other contact information from the inception to the present >One of the two numbers had a Signal account. >That number created an account with signal on X date at Y time. >The last date (not time) that account connected to the Signal server was Z (that connection may have been to receive a message, send a message, update profile, check if the server is reachable, or any number of other reasons, but the reason was not logged. That being said, none of it really is an excuse for lack of introduction of usernames. I think it is something that should be high priority. It's been years. The fact that they took the time to introduce a payment system over phone numbers is frustrating. However phone numbers doesn't pose a major security issue to a large majority of users, that being said it is still a security issue that needs to be dealt with imo. Stuff does take time, feel free to help them out. As for ETA, it seems like it is expected to be rolled out sometime this year https://nitter.snopyta.org/signalapp/status/1347248608660185089 https://teddit.net/pics/w:null_bpvlbssv9z961.png Personally I have a significantly bigger issue with the centralization of the server, not explicitly from a security perspective, but from a freedom perspective(the ability to self-host an instance, and federate with others), as well as a stability perspective (single point of failure, signal already noticed issues when Elon Musk tweeted to use it, and millions of users hopped on it. Signal has admittedly done an amazing job though, and it was down for about a day. I haven't noticed any major downtime (less than minutes) in my 6 years of daily usage). Despite lack of downtime, it's still an issue that's present. That and the Google services within the app.

>>15437 >https://signal.org/bigbrother/eastern-virginia-grand-jury/ The first part of the greentext was what the subpoena demanded as I stated. The second part of the greentext was what was provided. Forgot to add that text.

>>11163 I never understood the importance of messaging apps. >Gboard That's not the real problem, it's the phone clipboard. Anything that goes into the clipboard (like cut/copied passwords/btc) is accessible by any running app. There's a lot of apps that abuse this intentional android/ios feature that has yet to have been patched. The only way to go around this is by using clipboard monitor tool for figuring the abuse and using root to block the appops either with the built in # appops command or through an app gui. >>11166 This is the dreadful giveaway. If it uses play services there's bound to be some cheat-level API to covertly exfiltrate personal data through another (system) app, or if your device has gservices in it you might as well install alexa because your sound recorder is always abused (all according to your ignorance accepting the terms of [ab]use) that you'd be able to download random recordings of you if you choose "download my google data". >Newer Android versions encrypt the whole device by default (with your pin) but I don't know how secure it is. Technically it is flimsy security. The moment you boot your phone everything is unlocked. Like say your wallpaper, fonts, everything is decrypted after boot. They give you the illusion to use fingerprint/face-id/iris-scan but the police all have special tech that can image your phone through the micro-usb in matter of minutes (now think twice before handing it over the airport/border checkpoints. if you're lucky your phone manufacturer might actually have non-standard but proper encryption or otherwise a 'compliant' and standard one).

>>15439 >Gboard >That's not the real problem, it's the phone clipboard. >Anything that goes into the clipboard (like cut/copied passwords/btc) is accessible by any running app. There's a lot of apps that abuse this intentional android/ios feature that has yet to have been patched. Since Android 10 only the app on foreground can access clipboard, they should also make clipboard get automatically cleared after pasting though.

>>15443 >>15439 Gboard is a problem in itself, as well as the clipboard. There's really no reason to not use OpenBoard, or AnySoftKeyboard.

>>15452 ASK was super frustrating to use. I couldn't get it to stop making the same stupid "corrections", and it's impossible to remove a word from the dictionary. Bug had been open forever. Can't tell you how many times I wanted to throw my phone while trying to write messages on it.

>>15455 I never use autocorrect, I disable it. The suggestions that appear on the top bar are perfectly fine and I use that.

>>11163 reCAPTCHA may pop up during registration as an antispam measure https://community.signalusers.org/t/whats-next-following-we-need-to-verify-that-youre-human/29117/2 https://community.signalusers.org/t/use-something-else-instead-of-google-recaptcha-for-registration/6289