Why does Signal want a phone number to register if it's supposedly privacy first?
Why does Signal want a phone number to register if it's supposedly privacy first?
I remember a time when visiting a website that opens a javacript dialog box asking for your name so the message "hi <name entered>" could be displayed was baulked at.
Why does signal want a phone number to register? Is there a better alternative?
You're viewing a single thread.
Ignore the comment saying signal is "end to end encrypted" "private" etc They are simply stuck in a delusional state where they try to convince themselves that signal is the best option so they can continue using it. Nothing is private if it isn't fully libre because you never know what the proprietary code is doing. The signal protocol itself has its source code released, and the encryption and security code is publicly available, but the signal Foundation has stated that it uses both free code and proprietary code. Their reason is UI, but it's hard to make sure whatever proprietary code is being used for because you simply can't see it. As GNU puts it: "You're walking in a pitch black cave". Jami is fully libre and is a GNU project. You don't even need any phone number!
Molly.im is a Signal Client fork with Security enhancements and the possibility to install a version with only free software.
Great, but it relies on signal's servers, so it's centralised. Also, Moly merely removes proprietary parts from Signal, but that’s a workaround (same thing for linux-libre kernel, it's free software, but just a workaround which is why I'm looking to help with HyprbolaBSD). I'm not coming here to say Molly isn't an improvement, but being centralised and relying on a non-tully-free program's servers is a huge red flag for me :)
It doesn't matter whether a server claims to run free software or not. You can't verify what it's running. That's why E2EE is designed entirely around the client. You can't trust the server no matter what.
Did anyone say that was the problem? It will not matter how encrypted your messages are when the centralised service gets easily attacked, banned or subverted.
You can easily verify the keys of the person you’re speaking with, and they’re generated locally… so technically speaking, even if their servers are leaking, your messages are still unreadable, but yea that’s not ideal
Not when it's backdoored. So, tell the guy above there's a fully libre copy.
? Even if the servers are backdoored, your messages are still encrypted by your key - as long as the server didn’t manipulate the keys at the first exchange, which you can check by verifying the security code
If it matches, then it’s okay. Such features exist in all encrypted messenger apps
The app, not the server.
Jami, as much as I prefer it on various philosophical grounds, simply doesn't work very well at the moment. :(
And we should report problems and fix them ourselves to make it better
Yeah I'm on their Discourse forum, but the situation isn't that great, and it's unclear to me if the problems are fixable. Particularly when there are incompatibilities between version X and version Y, where both versions are already in the wild. You can't travel backwards in time to fix those versions, and this (like email clients or telephones) is an application area where you can't tell people to update their clients all the time. You have to keep things interoperable.
It's also often inconvenient to reproduce bugs like that in order to diagnose them. If you try to talk to someone over Jami and it doesn't work, you generally can't borrow their phone to analyze the issue. If you're one of the core developers, maybe you have access to a room full of different kinds of phones and OS versions to test with, but a typical user/contributor won't have anything like that.
Yeah, this is just the reality of unpaid free software developers, they don't have the recourses to work on every single bug as quick as a paid developer, but that doesn't justify not reporting bugs and working with the developers to fix them. Like you said, Jami is grest ethically so why not make it great function? Also, don't you have a computer and a phone? Test on those. I don't own a phone, so I can't test the phone, but I do gladly test on my laptop.
Those are nice generalities but I think they ignore reality. Jami seems like sort of a side project to its developers. Bug reports often are answered with a suggestion to make sure everyone is running the latest version of Jami, which is often useless advice. Like if you try to call your friend with your new phone and the call doesn't complete, it's unhelpful for your phone manufacturer to say your friend should get a new phone. You might be interested in helping fix the problem but your friend just wanted to have a phone conversation and doesn't want to get dragged into a debugging project. It's even worse if the other person is not your friend but rather is someone you just met and exchanged numbers with. If you try to follow up with a phone call and there is a problem, GAME OVER. You permanently lose contact with that person. You can't possibly suggest Jami as a Skype replacement after that happens to you once or twice.
Another thing with comms programs in general is you really can't debug them with just one computer. Their whole function is to let two computers talk to each other, so you need two computers where you control both ends and ideally control the network as well, so you can insert delays, network faults, etc. If the Android version has trouble talking to the Iphone version, you need both kinds of phones. I'm not sure if Jami's devs really understand that. I've worked on telecom stuff in the past and it's just the reality of that field.
Yet another (I'm not sure of this) is that Jami is a peer to peer program so I suspect some of the problems revolve around firewall traversal gotchas of various types. I don't know if there is a cure for this while keeping the basic architectecture intact. I do like it in principle and I know that people get BitTorrent working reliably without too much trouble, so maybe Jami is just missing some trick.
Finally, Jami is pretty old and back in those days, people hadn't really thought about the subtleties of encrypted group chats. Signal does a better job, and these days there is a standard (RFC 9420) for how to do it (I don't know if Signal follows this standard). It would be good if Jami were revamped for that, but 1) that would break interoperability again, and 2) I don't know if it's workable at all with Jami's architecture (serverless, using a distributed hash table for peer discovery).
For now I've sort of given up on Jami and am trying to figure out what to use instead. It's unfortunate that the main devs don't seem to have that much interest in making Jami reliable. Randos like me capable of making small contributions can't really help much with more involvement from the experts.
You make amazing points, and I completely agree with you. I will continue to use Jami since it's good enough for me to talk with my friends. I mean now the only replacement which is not a replacement just another thing I use to chat is GNU Emacs. I hope the development speed and motivation increases and please do inform me if you found an alternative
Based