I recently made a post talking about how im using briar but wanted ppl to recommend other apps but this article talks about some problems of those apps https://serpentsec.1337.cx/secure-messaging-choosing-a-chat-app
That article has a serious blind-spot on Signal. Sealed-sender is mostly meaningless to conceal metadata if it runs over a centralized platform (as a compromised central server can easily derive the social graph from basic timing analysis) and the apologist stance on requiring a phone number is just cringe worthy.
deleted by creator
Well, they are more concerned about growth than offering a true private solution, they can’t fathom scenarios were signing up using phone numbers will expose you to higher threats, as is demonstrated lately by government bans on signal account sms verification from Iran & china …
them only activating sealed sender by default for only contacts, is another sign to how much they are attached to harvesting user’s social graph and communications habits, + them not releasing the latest server version code adds to a lot of red flags.Having sealed sender only with contacts is an anti spam measure and they allow you to turn it on for everything. Also requiring a phone number is something that is fine if your threat model is not related to anonymity but to keeping conversations private. Moreover, at signal they are working on removing the requirement for phone numbers.
Having sealed sender only with contacts is an anti spam measure
I would rather deal with spam on my own than have a central entity monitor my communications ( as we can’t verify if the signals servers aren’t running a modified version of the open source release) + turning on sealed sender for me won’t allow my messages to reach the other end if sealed sender isn’t turned by default on the other end, should I ask every contact to turn it on before starting a chat with them ? that’s a bummer for me ! a useless feature if it isn’t turned on by default for everybody.
at signal they are working on removing the requirement for phone numbers.
It has been too years since they have announced that and till now its crickets ! and by what I gathered for forums and github It seems they are not getting rid of phone numbers for sign-up (they might still be mandatory ) but you might have the option to add contacts using their usernames (which is better but not what the community has asked for the most ).
Thanks for the info.I was thinking of using signal with a MySudo number but why would Signal require a phone number if it is supposed to be private.
why would Signal require a phone number if it is supposed to be private.
This has been discussed thousands of times: it’s just simply the easiest way to bootstrap a contact list based on your existing address book.
Noone wants to use a messenger where you have zero contacts.
I do. Or, I’ll enter them manually.
However, due to XMPP’s inherent metadata leaks, XMPP should usually not be trusted for private communication. Does anyone have more information on this? I always assumed XMPP to be quite good for private conversations, considering it’s strongly decentralized nature and maturity.
The metadata thing is mostly to do with the server having a plaintext record of things like your contact list but honestly it’s a moot point if you run your own server for your friends.
Also: are XMPP’s voice calls (jingle) E2EE?
I’ve read a few months ago that voice calls via Conversations IM are E2EE. Alas forgot where I read that. Anyone ?
The new implementation standard (as used in Conversations) AFAIK uses p2p WebRTC, which is encrypted by default.
Yes, but back in June 2020 it sent the keys over transport encryption, not inside OMEMO, meaning it was effectively transport encrypted and not E2EE.
I’m asking whether that changed.
For reference: https://github.com/iNPUTmice/Conversations/issues/1234#issuecomment-644670884Calls do not use OMEMO, but instead use DTLS-SRTP - which is still end-to-end encrypted as only both devices have the keys for the calls.
That said, as of a few weeks ago, Conversations does use verified OMEMO keys in the handshake to display a shield on the call: https://github.com/iNPUTmice/Conversations/releases/tag/2.9.8 (note that this requires that you have physically scanned the QR code of your contact’s OMEMO key).
This is one of these “true, but” kind of things. Of course in a federated network servers need to communicate with each other and that “leaks” meta-data to them. Maybe XMPP could be optimized a bit more to share less metadata (but it already shares less then Matrix), but in the end there is no way to totally avoid that if you want to enable federation.
IMHO I think the privacy benefits outweigh the downsides, because in XMPP each server only has a limited subset of the metadata and thus is it much harder to do AI driven data-mining on it.
Thank you for the insights, do you know which data that is in particular? For federation I would think 1) who you’re speaking to (both servers?), 2) on which server they are, 3) how long, how often, etc. Is that about right?
Yes, and all of that lives inside TLS, so only the server admins on both ends would see it.
I honestly want to stick with Briar since it doesnt require personal info and uses Tor.The only reason why I am hesitant is because it lacks certain features like being accesible to desktop(macOS,Windows,Linux)and IOS.I also hope they add audio and video chat,and also 2FA.If these features are added im pretty sure ill stick with Briar
I wouldn’t hold my breath waiting for briar to get voice and video calls.
Its development is very slow. and It doesn’t seem like the dev team have shown interest in bringing calls.Other good choices would probably be tox and jami
sa
Jami would be a nice option, but the p2p are sometimes with errors and that brings a lot of delays in delivered messages.
I like Briar, mostly because the forum and group options
