Why should I use this instead of Jabber/XMPP over TLS? Can someone sell me on this that knows how both work?
Thanks!
Signal Desktop
221–230 of 288 posts
Re: Signal Desktop
#222Earlier quoted context omitted.
They don't like to admit it, but Signal has a metadata problem. It's fine if that's not their threat model, but I wish they would be more clear about it, especially when other chat systems get criticism more often for precisely that aspect. Edit: "As far as we can determine, practical privacy preserving contact discovery remains an unsolved problem." -03 Jan 2014 [0] https://whispersystems.org/blog/contact-discovery/…
Do you have time to share more details on Signal's metdata problem, especially if you have any ideas about what they could do to solve it? Is this something that is going to require a Tor-like approach to even have a chance of fixing?
Privacy-preserving contact discovery and obfuscation of a message's metadata (what Tor can be used for) are pretty much orthogonal issues:
The first case is about finding out who of your contacts uses Signal, too. The way it's done in Signal right now is described here: https://whispersystems.org/blog/contact-discovery/.
The second problem is about whether anyone gets to see who is sending messages to whom, e.g. by tapping the wires or running the central server all messages are being routed through (for instance, Signal uses such a server).
In both cases, your social network might get get exposed depending on what data is exposed exactly (IP addresses, pseudonyms, …) and what the attacker can infer from it (your name / home address?).
Let me know if that helps.
Re: Signal Desktop
#223Earlier quoted context omitted.
Thank you for your reply. I really appreciate it. As I stated earlier, I feel bad about 'expecting more' here - I certainly see the appeal of a popular ~decent~ option. Without trying to derail this further, let me look at those points: If I use throwaway numbers: What happens if I lose access? Do I _need_ the number for anything in the future (say, device died)? Can someone else mess with me if they get access to th…
That's a pretty big holiday wishlist. =) This is the world we live in: people do most of their communication on mobile devices running iOS or Android, use Chrome on the desktop, and expect contact discovery to be automatic in their social apps. The browser has won the desktop, iOS and Android have won mobile, and the velocity of the ecosystem is unlikely to make "distributed" communication mechanisms possible for som…
First, congratulations on shipping. Usable E2E encryption is something I care deeply about and Signal is the best Ive ever used. Completely agree fighting mass surveillance for avg users is highest priority.
What do you mean by "the velocity of the ecosystem is unlikely to make distributed communication mechanisms possible for some time"?
Re: Signal Desktop
#224I'm feeling dirty, because I don't like to be that negative, especially if we're talking open-source software. And I feel that I kinda hold this project to higher standards: If I compare this to WhatsApp/Telegram/Threema/Whatever, I inheritently, somewhat subconciously expect more from Signal. And I'm disappointed. I tend to repeat the 'central server' and 'a phone number is not an address and not public information,…
If we were going to rank our priorities, they would be in this order: 1) Make mass surveillance impossible. 2) Stop targeted attacks against crypto nerds. It's not that we don't find #2 laudable, but optimizing for #1 takes precedence when we're making decisions. If you don't want to use your phone number, don't use it. You can register with any GV, Twilio, Voicepulse, or other throwaway VoIP number. If you don't wan…
Is there a technical limitation against having two phone numbers?
I live between two countries, and have two phone numbers - friends and family in one country have the one, in the other have another.
In places like Myanmar, people regularly have several SIMs with several numbers due to poor connectivity.
Re: Signal Desktop
#225Call it what it really is: "Signal Phone Remote". This is not Signal Desktop if you need a non-desktop to use it.
That name would imply your phone had to be online for the desktop app to work - that's not the case.
Oh, that does sound a lot more reasonable and I made an incorrect assumption.
I take it that you still need a phone to make a signal account though?
Re: Signal Desktop
#226This is slightly off topic but am I the only one surprised at the litany of permissions they require for the android app? Some make sense (like SMS or camera) but device & app history/location/identity/device ID & call info/contacts/calendar/microphone/phone seems like a smash and grab. I saw moxie speak at a conference once and he specifically called out the device id/call information permission as evidence that google doesn't care about your privacy, so why is his privacy-enabling app requiring it?? I thought these were supposed to be the good guys (and girls)? The good guys (and girls) don't do 'collect it all.'
Re: Signal Desktop
#227[deleted]
Re: Signal Desktop
#228Earlier quoted context omitted.
If we ever meet I'll buy you a beer for the year of the Linux desktop line. But honestly: I understand mobile support for iOS/Android only. I don't understand Chrome as a platform (FF isn't dead. And the biggest reason for that is that I fail to understand why that client needs to be 'web based' and then again not. A web app in a silo) Mobile numbers.. Why? I mean, if 90% of the population WANT mum to see that they u…
This is my question exactly. What features does Chrome have that are worth making the app completely incompatible with other browsers? Why is it not just a "Web app" and it's a "Chrome app" instead?
Similar to Firefox extensions, Chrome has "apps" and "extensions". Both are locally-saved packages of locally-run JS/HTML/CSS, differing in what capabilities they have w.r.t. chrome api access.
Re: Signal Desktop
#229Earlier quoted context omitted.
> "As far as we can determine, practical privacy preserving contact discovery remains an unsolved problem." This reminds me of an idea I had which I would love for people to tear apart (I know that the obvious bandwidth problem makes it completely impractical, but I wonder if there are theoretical flaws): Have a central server which everybody connects to. All clients send a constant stream of data, 24/7 - if they don…
You don't even need a central server for that. Just set up a p2p network and have all peers broadcast their messages (¶) to everyone they're connected to. Those peers in turn forward everything they receive to everyone they are connected to and so on. (And, of course, they try to decrypt everything in the meantime to see if any message is meant for them.) (¶) I think you could do without sending random data unless ne…
I'm currently working on a decentralized instant messenger Ensichat [1] which does exactly that. Right now, it only works over Bluetooth, but internet support will be coming very soon!
Re: Signal Desktop
#230Earlier quoted context omitted.
Surely battery saving modes should not drop messages? It could delay them but should never (well, almost never) drop them.
With no knowledge of how signal's servers actually implement this, I would like to ask you... how long should the central server hold on to the (encrypted) message that Alice sends to Bob if Bob never becomes available again?
Best effort, deliver at least once?
At least that how it seems iMessage seems to work. I have no idea how long iMessage holds on the queue but it seems no more than a few days.
Not sure what kind of attack vector a public TTL would constitute.