Why I won't recommend Signal anymore(sandervenema.ch) |
Why I won't recommend Signal anymore(sandervenema.ch) |
An optional user preference could allow some dummy wake up messages to be sent at random moments during the day, to support plausible deniability, at the cost of slightly worse battery life performance. This would all happen silently and the user would only notice a message notification when the app successfully fetches a new incoming message.
Yep, that's exactly how Signal has been doing it for >1.5 years now.
Once Signal and others have really wiped out all the insecure messaging people are doing, then we can start with the identity problem with phone numbers. GCM, Contacts, etc are all related to this "phone number as identity" problem.
RCS is an unfortunate grab in this space, and we need to move fast before RCS is the default, and we're back to insecure messaging.
Email addresses are the best form of "federated identification" but are wildly insecure for communication. Here's to hoping we can get some better ones.
Plus there's no way to search old messages.
Signal aims to be the most usable secure messenger, not the most usable messenger that also happens to be secure.
Use a federated secure protocol. Oh wait, there are none. Because if a problem appears you just can't fix it without breaking all federated clients. And then they will whine.
- Dependency on Google Cloud Messaging
Fair enough
- Your contact list is not private
Fair enough
- The RedPhone server is not open-source
While it would be nice that it was Open sourced I can understand them not releasing it (might be for IP issues)
tl,dr: "Signal does not work the way I wanted"
That's why you have to design your protocol with backwards compatibility and versioning in mind, ala XMPP. I'm not going to pretend its perfect, but it works pretty well 90% of the time. It does mean clients have to implement versioning and feature negotiation and not just blindly assume everything else supports all the features they do; convincing client authors to do this is the tricky part.
Check out the Riot client, web, android and ios. The apps are even native.
Plus, you don't have to show your phone nr.
So, how do you know that the Edward.Snowden@signal you're communicating with is the same Ed Snowden that we all know about, and not some TLA stooge?
I can change emails/usernames very easily and with little effort, and while burner numbers and applications that help that exist, changing phone numbers is not as easy and thus a significant percentage of users are unlikely to do it regularly. So you have a pseudo real ID that to the end user FEELS like it isn't you, but is a very strong (no pun intended) signal that it is to anyone looking in.
The phone number grants no you special verification of identity over an email address that doesn't involve an external verification mechanism (i.e, talking to the identity in person.)
Telegram sends messages in plain-text by default. Telegram servers have access to all plain-text messages that you send.
Telegram's private chats use end-to-end encryption. But they use an encryption protocol that they invented themselves that doesn't follow best-practices. Encryption experts have been critical of Telegram's encryption protocol since it was released. So your private messages might not be so private, either.
If you are doing something sensitive and want to stay out of prison, use Signal.
This sounds like everyone has access to those messages. Better: Telegram sends messages client-server encrypted by default and since you can't run your own Telegram servers, this is a problem.
Wouldn't a ISC/BSD-like license be better for the federation aspect?
I'm not sure he understands how app signing works and why it would be impossible for Google to forge a developer's signature. He also seems to have a problem with GCM and Google in general. Perhaps he should look into writing his own secure chat application.
Then later replace it with a signed version once they have the data they wanted. You would never know what happened.
The Giphy mention seemed really dangerous to me. Now I don't use Signal but I imagine it's 1) optional and 2) requests are proxified/anonimised through an intermediary (the Signal servers in this case). And why is this dangerous? Because this "don't build cool stuff on this serious app" is what makes people not use the app. It's creating boring, dull apps what stops them from becoming mainstream successes. If we are trying to make the public using secure apps because we believe in privacy, we have to make them appealing.
This is similar to the case of how nobody uses PGP because how horribly bad it is, UX-wise.
That said the rest of points he brings up are good. I just didn't like the Giphy mention, especially taking into account he didn't say anything else about it, he just brought it up.
I don't see anything in moxie's blog post about whether this is optional. If it isn't and it's sending everything you type to the Giphy API then we have a whole new problem.
In the blogpost by moxie, there's the example of typing "Im excited", which then gets sent in multiple API requests to giphy (basically one of 'I', one of 'Im', one for 'Im+' etc.). Now, if this is an action you don't do explicitly (like pressing a button or something, to search for gifs), then it would basically send everything you type in order to continually search for gifs and then offer suggestions? It's not clear from the blogpost. I hope at least that this is not what moxie had in mind.
I second the parent poster's question: "why is this dangerous?"
The internet will never be less walled, more free, and more federated than it was in the 90's. With such a poor understanding of the internet and its history, even if he did make a compelling argument (he doesn't), it'd be hard to take seriously.
Oh.
It's such a relief to have a modern chat system that's FOSS, federates, and offers a liiiiitle more advanced UX than irc...
Encrypted attachments was PRed this week: https://github.com/matrix-org/matrix-react-sdk/pull/533 (for the web; mobile will follow shortly)
Disclaimer: I do a lot of work on XMPP related things and rather like the protocol, so maybe I'm biased. I'm sure there are things for which Matrix is a better fit that I wouldn't use XMPP for too though.
Other projects can adopt parts of the Signal Protocol, and doing that is certainly better than just making stuff up. But Signal owns the protocol, because the experts who own the protocol are attached to Signal.
Just because the protocol has flaws, doesn't mean everyone can exploit them.
On the other hand it's possible for Google to read every communication because they have root on your phone. So using Telegram [1] with a custom ROM without Google services (e. g. [2]) will make it harder for Google at least. Not easily possible with Signal.
[1] https://f-droid.org/repository/browse/?fdfilter=telegram&fdi... [2] https://copperhead.co/android/
Matrix is not "all pull-based" - that's just the baseline implementation. Folks have already implemented push-based transports for Matrix - e.g. COAP or WS.
edit: [Disclaimer: i work on Matrix]
It's not connected to Signal or Signal Protocol or Open Whisper Systems, and subsequently we've added an entirely different new ratchet (Megolm - https://matrix.org/docs/spec/megolm.html) to handle Matrix's specific requirements for E2E.
But the reason crypto people are so positive about Signal Protocol isn't just that they like the ratchet. It's also that they trust the entire design of the system, not just the ratchet but all the rest of the cryptographic details, and also the oversight of the protocol.
It's kind of the same way that crypto engineers like stream ciphers designed as simple hash cores running in counter mode, but really what they like is stuff that Dan Bernstein designs --- they aren't encouraging you to go design your own hash-core based stream cipher!
So: it's good that these other systems adopting "Axolotl" are at least starting from a cryptographically serious place. But it's a bit jarring to see them reference "Axolotl" as if it answered the question of "why should we trust this cryptography".
A better answer would be to provide the bios of the people who designed and implemented the crypto in these systems.
In terms of bios: the folks working on libolm have 10-15 years each of professionally writing decent security-conscious native code, the vast majority of which (pre-Matrix) has been proprietary, with the exception of occasional contributions to things like Wireshark. I don't think they'd have described themselves as specialising in cryptography before embarking on libolm, but the team's learnt a lot along the way and the label might be more appropriate now. Ooi, what would you consider an appropriate bio? (short of being DJB or Moxie? :)
He says he thinks the protocol is secure, then says he doesn't want it to use GCM because it routes messages via Google who he doesn't trust (fixing that is the point of the encryption) and then talks about an attack that'd apply to any app regardless of whether it used GCM or not.
He finishes with a call to action: "We as a community need to come up with a viable solution and alternative to Signal that is easy to use and that does in fact respect people’s choices ... this tool should not have dependencies on corporate infrastructure"
But like a lot of armchair moralising, he isn't willing to debate the hard choices that go into building successful software. He says it should "respect people's choices" as if Signal is built by people who are disrespectful, he says it should not have dependencies on "corporate infrastructure" as if volunteer run datacenters actually exist, and then says his motivation is avoided paywalls, ignoring that both Signal and WhatsApp are free.
It reads like a collection of talking points rather than a coherent argument.
Signal is unusual because it combines cutting edge cryptography with consumer friendliness and is actually successful. It's pragmatic, not ideological. Crypto-warriors have a long history of producing secure software that nobody uses and then blaming the general public for not getting it; this sort of blog post is just a continuation of this decades long trend.
The 10th wants you to use something else because they're working on an attack for that "something else", and want their paper to be splashier when it's released. :)
When reading critiques of messaging software, keep in mind that messaging is a fucking midnight back-alley knife fight of a market. For whatever reason --- I think because (a) basic chat software is pretty easy to write, with a near- hello- world payoff similar to, say, blog software for Ruby on Rails and (b) because there have been multi-billion-dollar acquisitions of messaging tools --- there are a lot of different messaging products. Messaging is a network-effect market, so all the different vendors are fighting for users.
I don't think Signal has sockpuppets (it's just not their style), but I know several other "secure" messaging applications do.
I invite those who have opinions about Signal to start by getting involved in the project. To my knowledge the author of this blog post has never submitted a PR, issue, or discussion post to any of our repositories or forums. Many of these points are things that we would like to address, and we could use the help. The day to day reality of developing apps like these is a lot of work.
To provide some color on a few of these:
> Dependency on Google Cloud Messaging
To clarify this for casual readers, no data at all is transmitted over GCM. GCM is only used as a push event to tell the Signal Android client to wake up and connect to the Signal server to retrieve messages from the queue if the app isn't in the foreground.
This is pretty fundamentally just how Android works. However, people who want to use Google's OS without any Google services flash custom ROMs onto their devices that are missing this dependency.
I have said many times that I have no problem with supporting these custom ROMs. But I would like someone from that community to submit the PR: "I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services."
Nobody has done it.
> Your contact list is not private
First, on Android 6+ you can just disable the contacts permission and everything works (although you obviously won't see your contact names).
However, we also spend a lot of time thinking about this class of problems, as well as metadata in general. Right now things are playing out alright for one specific class of attack:
https://whispersystems.org/bigbrother/eastern-virginia-grand...
We'd obviously like to do even better. The nice thing about having a centralized service is that we can eventually take steps in this direction. People seem to equate federation with meta-data hiding for reasons I've never totally understood, but I think serious metadata protection is going to require new protocols and new techniques, so we're much more likely to see major progress in centralized rather than distributed environments (in the same way that Signal Protocol is now on over two billion devices, but we're unlikely to ever see even basic large scale email end to end encryption).
> Lack of federation
I've tried to write about why I don't feel like this is going to be a part of our future here: https://whispersystems.org/blog/the-ecosystem-is-moving/
However, I would love it if someone proved me wrong. The Signal clients and server already support federation, so there shouldn't be any technical hurdles stopping the people who are really into federation from using our software to start their own federated network that demonstrates the viability of their ideas.
If anyone needs help doing that, let me know. I'd be happy to help.
It seems a really strong and a bit aggressive of an attitude to have against a person's opinions
Especially the phone number thing. Phone numbers are quite sensitive. In some cases, the USG uses phone numbers alone for targeting drone strikes. They're enough to pull your credit report.
Could you provide details/sources? This seems like a good opportunity for some public shaming.
But two issues - or call it 'differences in opinion' - in that article are relevant for me: The inability to use the service without a mobile number and federation.
I understand the rationale behind the former ("It's easier"), but I don't understand why it is mandatory. I could've been 1283783127356128531312 on Signal and optionally add my phone number to that identity for others to find me (and optionally let Signal use my contacts to search for someone). That could even be the default, opt-out during registration. But right now, I'm basically using my phone number, which I really hate to do.
Federation is probably hard to get right, and looking at Eric Lippert's "Every feature idea starts with -100 points" rationale I guess it is understandable that this isn't a thing. But I don't want to join another silo, even if it's the best of the crop so far.
For users like me, Signal, WhatsApp and yes, Telegram are basically the same thing, come with the same set of limitations and I feel that it is worth pointing them out from time to time. Just as the article did (I'm not agreeing with everything in there btw.)
People jump in to defend Signal whenever this comes up, but maybe that isn't necessary. Signal is a great project and most criticism I've seen here so far is not 'Signal sucks', it is usually more a long the line of 'Signal is not for me' and I have a hard time understanding why that is debatable or why this shouldn't be a valid position.
If you're just using a secure messenger on general principles, it doesn't matter much which one you use. Probably WhatsApp is your best choice.
But if you actually need secure messaging, you should be using the safest secure messenger. Since we don't know who's reading these recommendations and what they're doing with them, we should employ the precautionary principle, and be clear with people that systems like Telegram, while probably fine for keeping messages out of the hands of jealous ex-partners, are simply not up to the task of protecting messages from serious, well-funded adversaries.
Yes, the phone number thing is a policy decision by the Signal people. As I write in my article, it's maybe marginally easier to get connected using phone numbers, but I may want to communicate via Signal with someone I don't want to give my phone number to. Handing out personal phone numbers on the willy nilly is not something I'm comfortable with. There's no reason why we couldn't have some other identifier, possibly easy to remember to connect us to via Signal. So this was a policy decision by the Signal people.
Federation is indeed hard to get right, but I think with proper versioning, and various teams keeping their software up-to-date and close to the reference paper/the Signal protocol, I see no reason why it cannot be overcome. For XMPP/Jabber it also works quite well.
Whether you are a journalist or an abused individual hiding from the ex spouse/parents/whomever that abused you, if your life and/or the lives of other people are on the line, this detail (and perhaps others, as I am not super technically literate) is a serious deal breaker.
It has nothing whatsoever to do with some kind of vague, hand-wavy preference, like preferring red phones over blue ones because you like the color red. It has to do with "If I use this, will I or others end up dead, maimed, in jail for a lot of years or otherwise basically have one's life utterly ruined?" Like that movie scene where they blow up everything "because you made a phone call" (Enemy of the State, IIRC).
[1] https://whispersystems.org/blog/the-ecosystem-is-moving/
Like you say that is the point of end to end crypto.
You do realize that since last year WhatsApp actually uses the Signal protocol?
First, ease of use: the distinction you miss is ease of use from a UX point of view. Managing your own security is hard for the vast majority of people. It is an advantage that there is ease of use with respect to the security aspects - no command line commands to generate keys, for example - and ease of use from a UX point of view is completely different. Making a decision to to ease the UX can indeed negatively affect privacy elements, and there is no contradiction there.
Which brings me to the second point, which is that there is no contradiction in the discussion of security. The service could be using insecure protocols or algorithms, but the author says it isn't - from the point of view of cryptography, those choices are said to be sound. On the other hand, having your communication routed through a PRISM partner is a different concern. There is no contradiction in saying that the part of security under their control is sound, but that the part routed through Google may not be.
Cryptography is complex and rigorous. What you call puratinism is actually rigor with respect to sound practices. The points the article makes are, in fact, coherent; where you call puratinism and hipsterism on the article, I call cynicism and likely uninformed reasoning on your comment.
Signal was marketed as anti mass surveillance secure messaging system. It is but a mere user friendly email+gpg alternative. It actively avoid anti-mass surveillance methods and does the opposite - encourages centralization and collection of user statistics.
Even Telegram is better, as people arent fooled by what it is.
A better alternative is Ring.cx or Tox.im with for example Antox client.
People always overlook the fact that the world is full of adversaries and 99% of them can't get access to Google's datacenters. Those adversaries matter too. Look at Turkey!
The author is wrong. LibreSignal won't replace Signal. Something like Telegram will: an "open source" messaging system with inferior cryptography, "opt-in" end-to-end messaging, a long-term dependency on the telephone system for authentication, and a far "cuddlier" personality with its users and, more importantly, with people from the app development community (like the author). Telegram will continue to gain adoption, because sexy beats sound in every end-user match up. Signal is the closest thing sound cryptography has to a palatable solution for end users.
Iran has already compromised Telegram users, because it systemically trades security off for user adoption. They'll get more of them, and people will hang from cranes as a result.
It's not wrong to criticize Signal. Signal does things I don't love, too! But we should be clear-eyed about the market.
Before the days of doze mode & other battery optimizations, you could just listen & block on a socket, then let the phone go to sleep. Incoming 3G packets would wake up the phone, you grab a wakelock, then start doing things. From what I remember, at least a while ago Facebook Messenger did this using MQTT. But this is not possible any more.
It's open source, uses a federated, open protocol, and can do multiple types of encryption including OTR and OMEMO (an XMPP wire format that uses the Axolotl ratched devised for signal). It does not do VoIP, so it would just be for chat (although there is a large bounty on Jingle-based voip support open). It has also had a public security audit, and is designed to be white labeled so you can tweak a few variables in the source and build your own hardended version or encrypted-only version, etc.
While my current phone doesn't support Signal, once I get a new one I will continue to use it.
You might opine that allowing Signal clones would allow me to use the app, but they would almost certainly be maintained by people who aren't really crypto experts, and so it's better to operate as though I am broadcasting in cleartext than to pretend that I'm not and get burned.
Sorry but you've got that backwards. He doesn't propose using that, he mentions OpenWhisperSystems banned them from using the service. It's criticism towards Signal, not a product recommendation.
> my current phone doesn't support Signal
I think it's Signal not supporting your phone, not the other way around. The manufacturer probably didn't make a conscious choice to not support Signal, but depending on what the issue is exactly, Signal probably did.
Nobody has been banned from anything. People have been politely asked not to distribute 3rd-party builds of Signal using their name and their servers, and that's it.
I don't trust Google with this information and don't want to carry such a device, but a handful of friends and family use Signal, so I must choose between easy/secure communication with them, and reducing my exposure to corporate surveillance.
Signal may be "pragmatic" among the current choices (just like the project's decision to use GCM is pragmatic), but OpenWhisperSystems absolutely deserves criticism for:
1. Tying secure communication to running what amounts to Google's spyware on your device
2. Offering no alternative for privacy-conscious users
3. Showing hostility to those trying to introduce such an alternative to the project
I think those dismissing these concerns as "crypto-puritanism" will be on the wrong side of history.
Quite the contrary, they're actively asking people to contribute code for an alternative push mechanism [1][2]:
"I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services."
[1] https://github.com/LibreSignal/LibreSignal/issues/37#issueco... [2] https://news.ycombinator.com/item?id=12883410
If I'm going to give up the convenience of reaching anybody by WhatsApp, it is going to be at least worth it in the sense of privacy.
Still hoping for a GNU project that garners enough interest to be technically strong, and used universally. One can dream.
"Also, there’s the issue of integrity. Google is still
cooperating with the NSA and other intelligence agencies.
PRISM is also still a thing."
What's this based on? Google immediately denied any association with the NSA and PRISM:https://googleblog.blogspot.com/2013/06/what.html
Google’s chief legal officer claimed that collection was being done without Google's consent:
http://www.irishtimes.com/news/technology/google-outraged-at...
Evidence leaked by Edward Snowden also points in the direction of illegal infiltration of Google's private network without Google's consent:
https://www.washingtonpost.com/world/national-security/nsa-i...
there are links on that page that point out multiple e-mails from the STRATFOR leaks and other files that point to Google being deeply embedded with the U.S. security apparatus.
Also: https://www.theguardian.com/world/2013/aug/23/nsa-prism-cost...
The leaks related to exploitation of Google traffic refer to programs unrelated to PRISM.
*Willing in the sense that they have to respond to FISA orders and NSLs, and they have agreed to do it according to a certain protocol.
Come to the matrix!
It's free -- all FOSS, including the entirety of the server -- and yes, all of it: proof by existence: several of my friends run their own.
It federates. I regularly join channels hosted on several different servers, and exchange messages without issue.
It's on every platform. I use it on the desktop, my android (cyanogen, without gapps, none the less!), and my ipad, every day.
It even has voice and video calling built in, using webRTC. This feature has been a little rough while it was in development, but I used it last week in a 1-on-1 call and had an effortless experience. The audio and video quality was on par with Google Hangouts.
Crypto is hard, but it's coming. The Matrix developers have huge respect for the axolotl ratchet design used in Signal. They've worked on making another implementation (in C, for easier linking in various languages, ostensibly) here: https://matrix.org/git/olm/
The deployment of that code to give full End-to-End encryption is a work in progress, but the beta is roughly functional. It includes everything you'd expect: communication works by default, but in an encrypted room, messages are flagged yellow if you haven't explicitly verified the sender's key. There's a key per device; it doesn't leave the device; and as soon as you verify that device/key, messages from it are green, and you're E2E secure.
Disclaimer: I have no direct association -- I became a Matrix convert after trying to write some XMPP client code about a year ago. I'm just really enthusiastic about recommending it because the tech is solid, the sync is good, it solves a problem, and the team hasn't stopped either: they been firing on all cylinders constantly since I started using Matrix.
I love Signal for their dedication to getting encryption right and the security of their users. But yes, I also share a lot of the concerns listed in this article. Most of all, I honestly believe federation is an imperative. So, while acknowledging Signal's history of outstanding security work... Hey, let's celebrate there's more than one game in town working on alternatives.
I would agree with this statement from the article: "there should be a tool that is fully free software (as defined by the GNU GPL), that respects users' freedoms to freely inspect, use, modify the software and distributed modified copies of the software. Also, this tool should not have dependencies on corporate infrastructure like Google’s (basically any partner in PRISM), that allows these parties to control the correct working of the software."
There are such tools. None of them are as easy to use as Signal. So for now, I recommend Signal. I can't, in good conscience, recommend anything else... and given the author doesn't speak to what they recommend, I'm curious about what their recommendation would be.
Isn't part of the reason that Moxie went with the Google Store is that he gets to sign the god damned binaries, making it impossible for Google to modify the app.
Of course, us more technical inclined people could then check the signature, or compare the apk with one built from the official sources, to see the difference and complain about it.
But between those things is a time frame where this is possible.
I was under the impression that the Play Store doesn't run as root and the package manager API (controlled by the phone manufacturer) is what checks signatures. Can the Play Store override the signature checks on upgrade and if so, what codepaths is it using?
The .apk on the site uses websocket, no GCM required.
Documentation is also getting a refresh in 2 weeks.
"The Google Cloud Messaging service basically handles message handling from/to the user’s devices to the Signal servers. The GCM service then handles all the aspects of queueing all messages and delivery from/to users."
This is not true. Messages are delivered via Signal's own servers only. GCM messages are empty; their only purpose is to wake up your device. [1]
"The phone component of Signal is called RedPhone. The server component of this is unfortunately not open source [...] this is also probably the reason why secure encrypted phone calls don’t work in e.g. LibreSignal"
No. The reason for that is that the signaling for RedPhone calls is currently still done via GCM and not via Signal's own message transport.
Regarding microg: I've never heard of the need to re-compile kernels for that. I think most people use it with Xposed (admittedly, a giant hack, but it works).
>Lack of federation
Moxie's pissy because he trusted the kangbangers at Cyanogenmod to to keep in sync with his development. They didn't. Someone will need to volunteer to run their own server that's kept updated, then buy Moxie a Snickers and hope he stops being moody.
>Dependency on Google Cloud Messaging
Fun fact: The iOS client doesn't use GCM, it uses Pushkit. GCM was chosen for Android because what else is as robust and doesn't eat battery? Moxie's voiced support of Websockets if someone implements it correctly and he can merge it as a fallback option when Play Services are missing. If you can't code and want it, contribute to the bounty on it:
https://github.com/LibreSignal/LibreSignal/issues/37
https://github.com/LibreSignal/LibreSignal/issues/43
> Your contact list is not private
https://whispersystems.org/blog/contact-discovery/
TL;DR, it's a tradeoff because nobody has a better idea that works at scale and is usable. Redphone used to have a good way of blindly doing contact discovery but it would require too much data for their current userbase.
As far as usernames go, that would require the signaling key to be remembered by the user. That doesn't work well in practice. As far as contact sync goes, has anyone submitted a patch for the android client to add an advanced option to disable that? On IOS access to the address book is user controlled at runtime. destinations will be validated by the server at compose time. Regarding federation, let's see some code. It's ridiculous to demand the small team that is OWS solve every single problem.
Moxie has explicitly rejected federation. Anyone writing such code is wasting their time it won't get accepted.
- It now supports e2e encryption.
- It has a nice web and mobile client, called riot.im
- I has many other client options
- You don't need to show any phone numbers.
- Federated, you can host your own server
Let's throw the best available solution under the bus.
This post will be my go to example of the myopia of some members of the security community. We have very few examples of well executed, consumer friendly privacy soloutions. Signal is the best for all possible scenarios: Open source, user friendly, buy in from a major Internet service.
I like wickr, but it falls short due to the closed source nature of the project.
Consumer friendly, usable security needs to be the number one priority for security advocates. We need to stop burning down houses because they are short a door or are the wrong color. The foundation is the hard part. Wait till there is a real alternative that can be used by people who are not c.s. majors before you argue that people should stop using the best available solution.
I appreciate the authors perspective and I agree with some of their points. Then they fuck it up by demonstrating purist jackassery. Worth a read as a useful persuasion antipattern.
Free yourself from the bonds of corporate infrastructure by installing this tool on your Google Android or Apple iPhone device (Microsoft Windows desktop version coming soon).
Tox works now, but for all their talk of trying to be user-friendly, asking users to exchange long alphanumeric sequences inherently isn't.
Psyc, maybe?
In terms of "syncing data everywhere" being 'terrible for realtime messaging'... i'm not sure that holds water ;)
They could use anyone for that functionality. Even if the messages are given to an "adversary" what can they really get from that? Your phone app contacted the signal servers. That's really it.
I don't know why it's closed source. It's been suggested elsewhere in this thread that it was potentially IP issues they kept it closed for. Is it possible loose US CALEA law interpretation influences the reasoning? Or a gag?
I honestly don't know why they chose to do that but I wanted to comment in to see if a lawyer or someone from the project could hint at the reasoning.
https://github.com/Spark-Innovations/SC4
Working on a better UI at the moment. Could really use help, especially beta testers.
https://github.com/WhisperSystems/Signal-Android/tree/master/libs/armeabi
But I always thought that .so was just a compiled version of this C++ source, which in the same github repository: https://github.com/WhisperSystems/Signal-Android/tree/master/jni/redphone
I haven't compiled it myself so I can't be 100% sure, but the C++ entry points matches the API the Java code is using. I presume it's written in C++ for speed. There isn't much to the C++ bits. It just pumps data through an encrypted RTP connection - CPU intensive but not particularly complex.The server code is up there too - in fact it's all up there. AFAICT, Signal is completely open source.
I never said that LibreSignal will replace Signal, and frankly, LibreSignal itself is not the solution either. But maybe LibreSignal will be the catalyst to a better solution.
We all want to prevent people hanging from cranes, but crypto alone does not equal privacy, does not keep you safe, especially not in those countries, where rubber hose cryptanalysis (https://xkcd.com/538/) is much more common. In those dangerous situations/countries, good operational security practices are better to avoid detection/suspicion than using any 'magic' crypto messaging app.
We now have two examples --- CryptoCat and Telegram --- of "secure messaging" systems being used by governments as a way of hunting down activists. Why do we need more? Can't the question be settled now?
As gently as I can, I'm going to push a little further. I poked around your site a little to get a sense of where you're coming from. Your post today opens up like this:
One of the things I do is cryptography and infosec training for investigative journalists who have a need to keep either their sources and communications confidential so they can more safely do their work in the public interest.
Can I ask what your qualifications are in training journalists in keeping their communications secure? Investigative journalists working in hostile regimes, even in smaller countries, are facing adversaries that are better funded than almost any other imaginable threat. Cryptography is incredibly hard. Elsewhere on the thread, you said "I'm not a cryptographer". Neither am I! I've spent the better part of 10 years getting decent at breaking cryptosystems for clients, and I still refuse to do privacy implementation work, because I'm simply not up to the challenge. Are you sure you are?
Then just put a TL;DR at the end of your article and say 'use iMessage/Facetime, it's probably good enough for operating in an unstable region' If it worked for Erdogan it will work for you!
EDIT: (While I intend to come off as cocky, I'm serious:
https://www.apple.com/business/docs/iOS_Security_Guide.pdf page 41
http://www.independent.co.uk/news/world/europe/turkey-coup-e...
)
I see Signal as having positioned itself as a compromise that makes nobody happy.
They don't require using phone numbers so it's not really annoying to sign up without giving away anonymity.
You can protect your Telegram account with a password (it's opt-in). Iran couldn't have compromised it then.
Did something change in recent Android versions?
Edit: Apparently Nougat's Doze is the issue. Conversations bug report, you can apparently put it on a whitelist:
It's still just a JAR (no native components), so AFAICT there's no technical reason someone else couldn't do a similar thing with their own servers.
I’ve reversed it, and rebuilt an alternative
The jar you include actually opens just an IPC channel to the Google Play Services framework, which runs with system permissions, and handles the actual stuff.
You can’t implement your own FCM without having root access on EVERY Android phone out there.
It's not a coincidence that the Facebook app was known for being an absolute battery killer. Go to any android forum post about battery life from a year or more ago and you'll see that the first suggestion is always "have you tried removing Facebook?"
No, fortunately Google has made it impossible for apps to abuse waking up the phone.
My current 'solution' is to use ZNC connected to Bitlbee (supporting OTR). On Bitlbee I use the jabber.fr service. ZNC has a push script for Mutter (great iOS IRC client) that I modified to redact my notification content from Apple's push service. I connect to the ZNC with TLS, so in theory everything should be ok.
NOT USER FRIENDLY but allows me to keep all my chats in one client and not tied to some shitty walled garden. Everyone less savvy I just tell them to use Signal.
I tried to write an XMPP client about a year ago and found out about that compatibility table the hard way. It's rough -- I had no idea what I was getting into.
Turns out that XMPP, before expansions, has no standard definition of what message IDs are. Which means "good luck, have fun!" is pretty much the best anyone can hope for on synchronizing messages when you have multiple devices or when the network flakes on you. Which in turn means XMPP is basically unusable on multiple devices. If you're lucky, everything supports all the same extensions, and it'll probably work most of the time; but if any piece of software you use is missing one extension, your day is toast. (And even then, frankly, the "carbons" API is wrong-headed and not very capable of recovering from network failures. In no uncertain terms: It's time to move on.)
I wrote about this more previously on HN: https://news.ycombinator.com/item?id=9772968
> do multiple types of encryption including OTR and OMEMO
Oh and it can also do something else: no encryption at all. That's the problem with XMPP: The user is faced with three different encryption modes, none of them is the default.
There shouldn't be multiple types of optional encryption. There should be one that works and is enabled by default.
I don't say that Conversations (and the XMPP community at large) couldn't do better, though. For example, there could be a standardized, automated, transparent process for determining which e2e schemes are supported by the clients involved in the conversation.
[1] For example, I skip e2e when talking to my several XMPP bots. They run on the same host as the XMPP server, so e2e won't reduce my attack surface when I already have TLS enforced along the way, but make the bot implementation considerably more complex.
Something fairly significant has happened in the world of XMPP recently. You can get real certificates for XMPP servers under your control from letsencrypt. That means that things now work transparently between clients and servers and between servers. As a result, organizations that do things that some governments might not approve of can do transparent encryption simply by setting up a server or servers in places that such governments can not physically get at.
So unless you're planning on hosting hundreds or thousands of users, you should be fine IMO.
So people could use their address books securely if they wanted — if OWS would allow them.
If I want someone I don't know yet to reach me, I expect them to Google search my phone number/email to make initial contact.
For those I already established initial contacts with, I'd like an account on a service that knows practically nothing about me other than my username(like coolkid654) and lets me send messages to others(coolkid655).
Given the state of data leaks[data snooping by the Gov or anyone else], and spam, it wouldn't be a terrible idea for someone to have a username that they reveal to only the people they trust(are worth). More like a Blackberry key. If packaged well, and made to look 'cool', it could even catch on and everybody would create one(or many).
The problem for me is that my contact list of Signal users is quite small (1 or 2 people) and everyone else isn't using it. I don't see the reason to allow Signal access to that list of people "Just in case" they decide to. It's incredibly unlikely bordering on near impossible.
This isn't the golden bullet of reasons that it should be this way, but the fact that in design Signal has made the choice to force access to contacts to me, says one of two things.
1. We haven't thought about cases outside of our own experience and expressly reject those as being outside of the market we're interested in. "You're not the user we're looking for."
2. There is value/commoditisation in that contact list that signal is interested in and this is the price to play in their system.
The problem is that either of these two options run pretty counter to the idea of secure privacy focused messaging client designed to be seperate from the user.
People's value of privacy is nuanced enough that making broad scoped decisions like this can run afoul of their expectations. Considering that Signal is aiming itself at the privacy conscious (Over-conscious in a lot of instances I'm sure), it's very weird that they would forgo this obvious affordance of information.
I've personally reached the conclusion that software isn't enough for this, though: it is people who choose to flog your data and it is money that buys it (think FB and WhatsApp). In my view a collectively owned version of something like Signal would offer protection from what is termed corporate surveillance by allowing people with skin in the game to directly influence decisions on things like privacy policies and development roadmaps. I've sketched this in a bit more detail here: https://news.ycombinator.com/item?id=12881917
Switched to Matrix and setting up my own homeserver took about half an hour, comes with everything I need (history, "Carbons", notifications, attachments, voice/video) built in. Plus it's federated and has support for bridges so I can interact with pretty much anything else through it if I like.
It's quite good at realtime, and especially reliable realtime. Compared with protocols like XMPP, Matrix scores way higher on reliability because it has message IDs and message ordering baked into the protocol, so it can actually converge on a correct state after network flakes. (I consider this a pretty big deal because silent message drops were a pretty regular issue for me in XMPP, and we all know about netsplits in IRC. I've simply never had silent message loss in Matrix because the protocol is simply better.)
I don't have an issue with Moxie except that he's been pissy over this and a few other issues. I don't think anyone is going to argue that he isn't. Why not check the first link to the Libresignal thread and read his comments on the topic?
(EDIT: I get the downvotes on this comment, but like Moxie, I too am seriously annoyed that Cyanogenmod dropped the ball so bad with them. Moxie would need to get over it if there's a new solution in the future and HE ALREADY VOICED HIS OPINION THAT FEDERATION IS UNLIKELY. If that's not being pissy, I don't know what else is. I used to run Libresignal on BB10 and now I can't because of this policy of being anti-federation and no work moving forward on websockets fallback. He'll likely say no to approving the fallback on Replicant/Sailfish/BB10 because he doesn't get version reporting through analytics and is concerned about disturbances of the signal server.)
The only thing that we know they store is the creation timestamp and last-seen timestamp for each account: http://arstechnica.com/tech-policy/2016/10/fbi-demands-signa...
Reading over the article again, though, it neither confirms nor denies where these timestamps are the only thing stored about an account. They explain these are the only data matching the concrete subpoena they received.
As for the politely asking, yeah that is still banning. If you banish someone from a country, they can still physically walk into the country. They're just not allowed to.
this one spent 240 hrs: https://www.wickr.com/about-us/blog/2014/08/05/aspect-securi...
You haven't talked about Wire.
People have to trust someone. If you are not a crypto expert you have to rely on crypto experts to tell you if the protocol/app is sound.
I don't have to be a security expert to know that google can get the phone numbers of all the contacts I talk to on Signal. So the anonymity angle is lost completely.
Regarding privacy, I don't have to be a crypto expert to know that google services are running as root on my phone. They can easily replace the app itself. Avoiding using google proprietary services and still using Signal is a lot of pain.
This is exactly why I'm shying back from recommending Signal to my family. I taught them that the equation "permissions = bad" generally holds, so Signal would look like spyware to them, even if every single permission turns out to be justified for some reason.
Not really. I consider myself poweruser in many areas, but I would never recommend most of my tools to "ordinary" friends. The tools for them should be easy to use and difficult to misuse.
I mentioned this a bit below but this wasn't the case with Matrix. Setting up a homeserver took me about half an hour and gave me everything out of the box. Setting up Prosody took me days and gave me nothing but trouble.
There are a lot of XMPP servers around but I really want my own so that I can store plaintext chat logs on the server.
https://android.googlesource.com/platform/frameworks/base/+/...
for the Android base framework. It has the checkSignatures() abstract definition and some other stuff that seems to be the API you talk about. Now this is all abstract, so some other party (maybe phone manufacturer, possibly others) must implement these methods to conform to the API. Could Google (or some other party) not just override the abstract implementation?
I find it hard to believe this is something only the phone manufacturer would have access to, not Google itself, given that Google has created the entire operating system basically, and is pulling more and more stuff from the AOSP into their proprietary apps (like Play services).
Android doesn't rely so much on root vs non-root: it uses SELinux and lots of capability based security. Root is still there of course but out of the box, even the parts under remote OEM control don't run as root. If the OEM wants to change the basic rules of the system they must push a system update and get the user to agree to it. Of course a firmware update can change anything but outside of that I'm not convinced Google can just replace software at will.
Getting a real cert for s2s doesn't really help as long as you have no agreed upon mechanism how they can enforce validation of those certs.
Of course an organization using TLS as their only security for XMPP would almost for sure just use one secure server, so I might be being a bit fanciful here. My ultimate point is that because of the way XMPP works, it is possible to make the normal default clients work securely in practice by doing the correct things at the server level.
I mean, I think I wrote[1] that I really dislike the connection between identity and phone numbers. I happen to use Telegram at the moment (I have exactly 5 contacts, one of those is the Telegram 'we updated the software' bot, another one is a random 'Sticker' bot), but I'm an xmpp guy deep down. Matrix looks promising, I just need to find the time/energy to make the switch (and convert the 3 'real' Telegram contacts).
If you look at the thread with tptacek I do have to agree that the safest bet probably is Signal right now - if it leaks the phone number or not. I don't have to like it though...
1: If you look at my comments it seems that I repeat that in every other one, but English isn't my native language. Please blame the language barrier first, then blame the human behind the message.
To me, remarks like this one read as "Eh, if Signal is not to your tastes, no big, but no reason to trash it either." But the article and I and others here are saying, "Yeah, no. This is not the same thing as picking a phone because you like red more than blue. This is more like refusing the blue one because it explodes sometimes when you answer it."
For people for whom lives are on the line, this goes a lot deeper than personal preference.
Yes, you (and I, let's not forget that we kinda agree that this is bad design) might not want to share your private phone number just to contact someone via Signal. But I feel you're painting this a bit too black or white.
If lives are at stake or not, Signal might or might not be the right solution. If people feel that their life is at risk, I hope they know how to evaluate the trade-offs - or have someone around that can explain it.
We both don't like Signal. I don't agree that it should be dismissed and emotional appeals are ~questionable~, can probably be turned around (see first paragraph). Individual decisions need to be made and if Signal is a good fit or not for a specific scenario isn't an good indicator about the general fitness of Signal in general imo.
Wire for example, doesn't require you to sign up with a phone number. You don't even have to have a phone.
How is it not an obfuscation mechanism that works at scale?
Also, what if google has a rogue employee who works for one of the surveillance agencies?
Trusting all your private data to an advertising company that has root access on your device in an app that is explicitly built around security and privacy is insane.
Also, what if google has a rogue employee who works for one of the surveillance agencies?
Trusting all your private data to an advertising company that has root access on your
device in an app that is explicitly built around security and privacy is insane.
In that eventuallity they might be able to keylog or otherwise monitor the activity of applications anyway. I don't see how you can avoid that sort of eventuality aside from tossing the mobile phone and using snail mail and a OTP. Even then there could be someone looking over your shoulder.There are degrees of difficulty. If you use Signal, you make it more difficult than if you use whatsapp but easier than if you have a rooted phone with open source software.
Also, you make it easier than it has to be with giving away contacts/phone numbers.
Pnacl provides sandboxing, but it doesn't seem to provide any protection against buffer overflows. Android apps are also sandboxed, so I'm not sure what your point was.
Android (at least recent versions) has both NX pages and ASLR, both of which are specifically designed for these kinds of attacks. Sandboxing isn't, really, especially if your sensitive content (messages!) are inside the sandbox, obviously.
You may be aware that of late there have been numerous buffer overflows (or other parsing problems) in standard image parsing libraries. Where these are implemented in Java that may be less of a concern, but this type of task is often handled by native code. And while more Java exploits are via breaking the verification in clever ways, via reflection or priviledged calls or pickling, that does not rule out that processing external data can lead to an inconsistent state. It might not be a problem with gifs, if they are small, but animated gifs can be large. Or maybe java See this discussion on Android image processing: https://code.facebook.com/posts/366199913563917/introducing-...
The point of PNaCL is that you can use it to sandbox components within the same process/permission set, you don't have to rely on the OS. It has a much smaller attack surface than Java.
You talk about NX and ASLR being useful in the same post as you say buffer overflows can't happen. In any case, while they may be designed to restrict attackers, they are by no means sufficient. There are Java ROP gadget chain builders! JVMs use JIT, which inherently means they are creating new code. Eg. see jit spraying.
Which causes the entire issue.
I wrote a complaint to the EU privacy official responsible for them and the EU antitrust committee.
Rereading my post here, I can see why a reader would infer from it the idea that the author might be a sockpuppet. I don't believe that! I was thinking more about the kinds of comments on message boards that say Signal is a "honey pot". I could have written that more carefully, so, sorry about that.
While Signal might have an excellent protocol, also well audited all this comes with some bad compromises.
E.g. you are forced to run GCM, or you share your address book. Both are unacceptable to many people that really need secure end-to-end encryption.
Both can compromise you.
It's a solved problem, but Signal doesn't implement it.
Also, how does this protocol even help? What's the use case? It allows participants to discover mutual contacts, but what then? Do we use Bob as a web-of-trust style introducer? What if Alice doesn't even want to talk to Charlie? Do we do this for all the friends Alice has in common with Bob? Do we do this for all the friends Alice has in common with everyone? Does Charlie initiate the process, only to have it only work if all three of them are online at the same time? Who kicks it off and why, and what would the user experience be?
You end your last post with "So, problem solved" but I'm not sure this protocol even solves any practical problems for the Signal use case, and seems like a mere first step of solving a much more complicated problem of actually trying to turn this into a useful feature with good UX.
They don't actually have to be online at the same time (and they don't care about whether Charlie is online or not: it's a pairwise protocol): they just to be able to send and receive one another messages, and to store state. Fortunately the former is some Signal's quite good at, and storing state is something that phone hard drives are quite good at.
> Also, how does this protocol even help? What's the use case? It allows participants to discover mutual contacts, but what then? Do we use Bob as a web-of-trust style introducer? What if Alice doesn't even want to talk to Charlie? Do we do this for all the friends Alice has in common with Bob? Do we do this for all the friends Alice has in common with everyone?
It's the exact same use case as Signal's existing contact-discovery code, only private: it enables Alice & Bob to share information about a mutual acquaintance, e.g. Charlie. This might be used to share Charlie's key ID, in a trust on first use style. Note that this is no less secure than everyone everywhere trusting Open Whisper Systems on first use.
The idea is that when one starts using Signal, one exchanges keys in some out-of-band mechanism (NFC is a likely candidate) with an acquaintance, and then from that person get keys of mutual acquaintances, and from then others, and so on and so forth. Whenever you add a new acquaintance, one can reiterate the same protocol with all previous acquaintances (it's amenable to batching, too, which is nice) in order to propagate that information.
It may have some interesting uses in a certificate transparency sense, but I don't know about that.
> You end your last post with "So, problem solved" but I'm not sure this protocol even solves any practical problems for the Signal use case
It solves the exact same problems the Signal contact-discovery protocol solves, without actually revealing all one's contacts to OWS. That's all. If it did nothing more than that, it would be a good thing.
Your answer to all that is "I heard it's hard but really, versioning/XMPP and also, it's not hard". How well has 'proper versioning' worked out for SSL/TLS? Federation hasn't really 'worked out' for XMPP. Never mind anything substantial in response to Moxie's writing. People calling your piece 'hipsterism' are being very, very polite.
However, we very strongly feel that the resulting freedom and choice from the resulting open ecosystem is worth the additional complexity.
Users can choose any service provider without compromising interoperability. They can run their own servers. They can write their own clients. They can write their own servers. They can choose precisely who they trust with their data. They can contribute to the spec and help define the ecosystem. They aren't forced into trusting a provider who may be trustworthy today, but who knows in future.
I believe Moxie's viewpoint is that privacy is paramount, and any complexity which could introduce bugs which could undermine security/privacy is anathema. From a cryptography dev perspective, this makes perfect sense.
On the other hand, Matrix believes that there is more to life than just privacy, though (as critical as privacy is, of course) - and it is possible to have both privacy and freedom.
Yes, it slows down the rate of development a bit. Yes, it means you have to think much more carefully about layering the protocol to allow the different layers to evolve as independently and efficiently as possible, with the necessary mechanisms (both technical and organisational) to upgrade and lock out obsolete clients and servers. Yes, it means there's more complexity, where bugs could hide. Yes, it means that you may not be able to force the world to upgrade as rapidly as a silo might in the face of a critical security issue.
However, we think it's worth it.
IMHO Signal is only usable on smartphones. I don't want to link my desktop client with the phone, so I use Wire on the desktop.
Oh and Wire is a Swiss company. I see you run your blog off the .ch TLD.
You can 'block' people, but simply removing them? Nope.
Why do I care? Because at one point the 'upload all contacts to Wire to help you find them on Wire' wasn't optional (I understand it is now) and now I'm stuck with entries on my contact list that I just don't care about. Very weird..
And Google became a PRISM partner in 2009,
as the slides here from the Snowden collection prove
Read those slides more carefully: they say that collection from Google began on 1/14/09, not that Google became a willful partner of the PRISM program.This is also an interesting read, albeit a bit long: https://wikileaks.org/google-is-not-what-it-seems/
Google continues to coast on the goodwill of its "don't be evil" doublespeak, as Mr. Assange puts it. There's no reason to trust them now.
An attacker who cannot generally passively intercept (but not decrpyt) traffic on the wire but can passively intercept traffic to/from the GCM servers would be foiled by not using GCM, but that's a very narrow case.
Edit:
I was running it on a DigitalOcean box with only 512MB of ram at the time, which I found a bit silly that I would come back and the server was down, but it was a different XMPP server than Prosody.
[1] https://modules.prosody.im/ [2] https://prosody.im/doc/installing_modules
> If anyone needs help doing that, let me know. I'd be happy to help.
I appreciate that you would say this. I suspected that you actually felt this way despite your pragmatic approach outlined in that blog post. I'm a fan of federation, but I think the developers of federated systems have to take the problems outlined in your blog post very seriously and not defensively.
There's already a built-in warning on modern Android because apps need to request a battery optimization exception just as they would one of the dangerous permissions. Otherwise, GCM is the only way they be woken during Doze / App Standby for push notifications. Apps can't simply poll anymore. It's unfortunate that even an app doing a great job like Conversations gets a warning / prompt about this but there's little that can be done about that beyond the OS whitelisting the keys for known good apps.
Conversations is pretty much the only viable option without GCM. It uses a take on the Signal protocol via XMPP (when supported by the other contact) so you helped to make that happen anyway.
> First, on Android 6+ you can just disable the contacts permission and everything works (although you obviously won't see your contact names).
This is very good.
> However, we also spend a lot of time thinking about this class of problems, as well as metadata in general. Right now things are playing out alright for one specific class of attack: [federal subpoena]
Good, so Open Whisper Systems has no metadata. Do any third parties retain metadata about Signal messages?
There's also the issue of mobile numbers. I get that more-or-less anonymous numbers are doable. But arguably, most Signal users don't have anonymous numbers. However, maybe this is a non-issue, if the only data available are "the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service". Is that it?
I'll try to answer to the best of my knowledge (I'm not associated with project, I'm just a happy customer).
Does your ISP know that you are communicating with Signal servers? Yes, IP addresses.
Does it know to whom you are sending messages? No.
Does Google know you are using Signal? Yes.
Does it know whom of your contacts use Signal? Yes, because they have a full list of your contacts and they know if someone has installed Signal.
Does Google know you've sent a message? No.
Does Google know that you are receiving a message? Sometimes, because Signal servers ping your device via GCM with "wake up".
Does Google knows who from your contact list send this message? No, unless you have only one contact who uses Signal.
Can Google infer from pings who is communicating with whom? Yes, although pings are needed only if app has disconnected from server, and this severely limits usefulness of this technique.
Where else may any metadata coming from usage of Signal be? Nowhere.
As for Google having your contact list... Take a look into Flock.
I get that Signal is probably the best option for smartphones. And that maybe its vulnerabilities are only relevant for "TAO targets". But the problem is that "TAO targets" is in rapid flux, given developments in automation and AI. So arguably, more and more journalists and dissidents are becoming vulnerable.
And there's the fundamental insecurity of devices with cellular-radio connectivity, and operating systems that users can't control and lock down. Signal can do nothing about that. Even something as simple as reliably obscuring identity in connections to Signal servers is nontrivial.
Does it know whom of your contacts use Signal?
Does Google know you've sent a message?
Does Google know that you are receiving a message?
Does Google knows who from your contact list send this message?
Can Google infer from pings who is communicating with whom?
Yes to all of those, because they have root on your phone.
Yeah we've been there. Do you remember someone on Github complaining about the Google dependency? You closed that issue as a wontfix. Or LibreSignal? I read the post where you basically told them to go away on Github too.
That's why I haven't recommended Signal ever since trying it myself a year or two ago.
Not sure what you're talking about, because the issues in question, #127 and #1000, are open.
> you basically told them to go away on Github
Quite the opposite [1]:
"I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services."
[1] https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
Tox's goal is essentially to create a user-friendly Skype-like chat application, with not centralized server, and strong security by default.
The downside is that your user ID on tox looks like this:
56A1ADE4B65B86BCD51CC73E2CD4E542179F47959FE3E0E21B4B0ACDADE51855D34D34D37CB5
And you have to give it to anybody who wants to connect to you on tox. There are services like ToxMe which can give you email-style shorthands, but as the Tox FAQ notes, this can leave you and your contacts vulnerable to an MITM attack, if the site you use is untrustworthy.Ah, see, you lost me there already. I'm sure it's clever and well made and all the rest of it, but fully distributed systems either almost never work, are very difficult to get setup and use properly, or end up just not being fully distributed systems (eg. early Skype and it's "supernodes" or whatever it called them, aka "servers", or Tor [which I love] and it's directory authorities which admittedly are elected, but even so are effectively just "servers", or Bittorrent which has either trackers, aka "servers", or hard-coded DHT bootstrap nodes, aka also "servers").
Distributed systems sound great in theory, but in the real world I just never think they're worth the effort, or you have to compromise them and add some centralized element anyways, at which point you might as well just use a federated system so that people who don't want to deal with all that can use a third party server and people who do want their own specially contained distributed node can just run their own server and client.
First, they have full forward secrecy. This is notably unlike Ring, which does not.
Secondly, all communications are end to end encrypted and endpoint-verified, as there's no "legacy SIP support" (eg: SIP) or such nonsense and the DHT addresses your contacts gave you are actual ec25519 public keys.
For nontechnical users, that's a massive downside. The first tox client to integrate ToxMe into itself will get very popular, very fast, provided it's got the right marketing.
Ouch. qTox had it for quite some time already, and given that I didn't observe massive increase in its popularity (there was increase, but ~normal), it's got to be the marketing (or lack of thereof)...
Sadly, I don't know about marketing, and while there were some people who could into marketing, hiring them would require money, which Tox ecosystem doesn't have at all, and if it had, it would be spent on hiring devs part or full time. :|
With that being said, it's quite likely that the UI for the integration in qTox is not the best one, and could use some improvements. If you have any suggestions / ideas how it could be made better, please don't hesitate to make an issue on qTox repo with them: https://github.com/qTox/qTox . Or any other part of qTox.
Anyways, aside from qTox also Antox should have ToxMe integration. I don't know about other clients.
I disagree entirely. It's an upside. They get to benefit from PKI without even understanding anything. A person's address gets them the actual person.
ToxMe requires trusting the ToxMe identity provider, and is an obvious point of attack. And we'd no doubt see fake addresses that resemble other peoples, and other such nonsense.
There's minimising the inconvenience (with ideas like the QR code feature they have), and there's plain giving up security for minimal gained convenience, which we should just avoid.
While you may hope that they know how to evaluate the trade-offs or have someone around that can explain it, many people live life under very risky circumstances and an uninformed choice can be the last choice they make.
No, I am not painting this a bit too black and white. Alive or dead is a pretty black or white thing and many people live lives where death dogs their steps. This is not an appeal to emotion or hyperbole. This is a fact.
If it isn't that big of a deal for you, cool. Glad to hear your life is fairly comfortable. But I do think it matters that informed, knowledgeable people discussing it on a forum with a strong reputation for being a good source of technical information (as well as other kinds of information) is a place where someone needs to make it very clear what the potential consequences are for people who live in dangerous circumstances and don't have the technical background or connections needed to figure this out.
Yes, I'm living a comfortable life (if we define that as "Not worried about dying"). I seriously cannot imagine what people in those situations might go through.
But regardless of one's technical skills, I believe that someone cautious about giving up their phone number would stop and reconsider when Signal wants you to provide your phone number? I also really hope (for the sake of the people you stand up for) that getting a random / anonymous SIM card, a 'just for close friends and family' phone number is something that is well-known and good practice?
I .. don't want to dismiss your opinion. Honestly, I'm _still_ convinced that we feel the same about Signal. Let's turn this around: What would you _hope_ for here? What do you expect or wish for? What do you criticize exactly?
I am not trying to argue with you. But I think this is a distinction worth making. We don't know who all is reading. People in real trouble often cannot ask questions. They may only be able to read. In which case, it matters if someone points out such a detail.
Thank you for engaging me.
You are implying that cost of TAO consists mostly of labor costs. Which is false. NSA and friends are not really limited by money. They are limited by amount of unpatched software vulnerabilities. Every use of vulnerability in the wild is a chance of revealing it to world and losing it. Snowden docs reveal the existence of automated software which evaluates chance of vulnerability being revealed by attack. XKeyScore or one of related pieces, AFAIR.
There's another HN thread where I've talked more about XMPP vs Matrix here: https://news.ycombinator.com/item?id=9772968 -- long story short, I tried to write an XMPP client, and I got grey hairs, fast. The story for consistent delivery is pretty much bananas. (And huh, based on that date, I guess I've been a Matrix convert for almost TWO years now! Time flies.)
I'm not entirely sure what the comment about battery is about either. If anyone has a networking technology that can work without turning on the phone radio, I'm sure we'd all love to hear it...?
Practically speaking, I leave the Matrix Vector app open on my phone constantly. As of this morning, I have half a charge, and three more days of charge to go. I don't have any other apps to provide a good comparison here, but I'll leave this screenshot here for what it's worth: https://matrix.org/_matrix/media/v1/download/matrix.org/IgkU... Looks like my phone has spent about the same order of magnitude of battery on just plain paging the cell towers as I moved around the city. As other comments on this thread cover, if you use proprietary Google stuff, you can wake the phone up slightly more efficiently. But whatever this app is doing works pretty fine for me.
It's not a case of radio off vs on, it's a case of the radio being able to stay in RRC_IDLE mode (which I've probably called "off" more than once, which is where the confusion came from I'm sure, apologies for that) for more of the time, where as with Matrix it almost always has to remain RRC_CONNECTED mode.
I used cryptographic software as an end-user for many years, like GPG for instance, and agree that it's hard, and we need to train people to use correct security habits (infosec and opsec), to minimise exposure to hostile elements.
I've tought at cryptoparties and other events, I have spoken to many intelligence whistleblowers, some of which I consider to be close friends, and they've told me about some of the techniques used on the national intelligence agency level and how wrong use of crypto and general bad operational security practices can expose you. So while I'm not a trained cryptographer, and do not claim to be, I have extensive experience not only building secure software, but also, thanks to whistleblowers know about some of the ins and outs of the intelligence industry re crypto and surveillance.
An alternative needs to be as a bare minimum cryptographically secure. And then on top of that it would be very nice if there was federation, not tied to phone numbers and all the components being open source. Those last 3 points is where Signal fails currently. Federation is something that moxie tried, didn't work out, now he's basically not in favour of that, the phone number issue is of course well known, and the redphone server component is not open source.
Hits all your technical requirements. Setting up your own homeserver is cake. Federation is a key part of the core design. End to end encryption is just about to be finalized. History syncing between multiple clients. Bridges for pulling in other chat systems like slack and IRC. Completely open source. To me, this is the perfect messaging platform. Just needs some UI polish and I could see it really taking off. Had you seen this yet?
[1] https://whispersystems.org/blog/the-ecosystem-is-moving/
I recall e.g. that Moxie reviewed Telegram's security, found that none of it made any sense and that its authors didn't know what they were doing. https://tobtu.com/decryptocat.php looks like the cryptocat analogue of that. Have the two projects improved somehow? Have some people joined or others left?
Could you please also provide links for the claim that CryptoCat and Telegram are being used by governments to hunt down activists?
Except it doesn't. If you share your contacts with Signal, it can tell you which ones are on Signal.
If Alice shares her contacts with Bob, she may discover some contacts she has in common with Bob, but not necessarily which ones are Signal users. Perhaps Bob has talked to Charlie some time in the past using Signal, but perhaps not.
So if we run this chatty, online, synchronous protocol with each of your contacts you already know are on Signal who happen to be online at a given time (which will be a subset of all your contacts), you may-or-may-not discover some of your contacts use Signal.
In my previous post I was really asking about the user experience angle, which you didn't respond to at all, so rather than asking a question, let me simply say: I think this feature (at least in as much as I can conceive of it being used) would provide a poor user experience.
The contacts which would be shared would be Signal contacts, identified by some public identifier like their phone number (which is the only public identifier Signal currently supports; it could easily be extended to support other identifiers though).
Yes, it won't reveal to Alice that her friend Etta is also using Signal, if Etta and Alice don't have anyone in common. That's part of the privacy-preserving feature which prevents Signal from knowing who's using it, and whom everyone knows.
Given the small-world phenomenon, the odds are that one will very quickly add most folks one knows about, and the others can be added manually.
> So if we run this chatty, online, synchronous protocol
It's not chatty: the exchanges are large, in order to protect privacy, but they are also rare, and are not ongoing. Whenever you add a new contact, you re-initiate the protocol with your pre-existing contacts, that's all.
It's not online: as I indicated before all that's required is for each party to send & receive messages, and have some state.
It's synchronous, I'll grant, but only in the trivial sense that one party acts, then at some point in the future the other party acts. It certainly doesn't require both parties to be online at any point.
> In my previous post I was really asking about the user experience angle, which you didn't respond to at all, so rather than asking a question, let me simply say: I think this feature (at least in as much as I can conceive of it being used) would provide a poor user experience.
I think that the user experience would be identical to the current Signal UX: from time to time one's phone would buzz and indicate that one of one's friends uses Signal. If one wanted to, one could add a contact in person, e.g. through NFC or QR codes or whatever.
You seem very invested in hating this idea; you might ask why I'm so invested in it. Very simply, Signal is a tool for secure communication, but it requires that end users reveal every person they've ever communicated with to OWS.
> The contacts which would be shared would be Signal contacts, identified by some public identifier like their phone number
If Alice and Bob are just comparing their directories of already-known Signal contacts, there's nothing for a discovery protocol to accomplish: Alice, Bob, and Charlie are already each other's contacts!
So this protocol can only help people discover contacts they are not yet aware are Signal users. That would involve comparing their full set of on-device contacts and sharing mappings of which one of those are within the subset of known Signal contacts.
> You seem very invested in hating this idea
I would continue trying to give you what I thought were constructive technical criticisms, but apparently you interpret that as me being "invested in hating" the idea.
It's more like I'm invested in providing good user experiences for security tools, which often involves starting with the user experience you want to provide and working backward, not starting with a cryptographic algorithm and trying to bolt-on a good user experience.
The latter is how we wound up with a pervasive ecosystem of unusable security tools that Signal is a refreshing departure from.
You are starting with a protocol, not thinking about the user experience, and declaring it a "solved problem". I'm not even convinced this protocol is the right tool for the job.
The only difference is that (in the baseline impl) you start a new HTTP request after receiving each response - which chews some additional data relative to XMPP. The radio will already be spun up from receiving the previous data, though, so it shouldn't impact significantly on battery consumption.
Also, we put a timeout on the long-lived request (typically 30-60s), to aid recovery in case of the request or connectivity breaking - which could theoretically increase bandwidth and radio battery consumption, but in practice almost all Matrix use cases involve receiving events more frequently than the timeout, so the timeout doesn't actually have much impact on battery.
That said, there is (deliberately) huge scope for improvement with alternative transports - using strict push rather than long-polling; using transports with less overhead; using more efficient encodings, etc.
I haven't checked but my hunch would be that HTTP/2+JSON would be very similar to typical XMPP in terms of bandwidth, if not better, and obviously requires no spec changes; just an HTTP/2 capable client & server/LB.
In terms of what transport people use: well, I assume end-users will use whatever the best performing clients implement. Riot is the flagship client and will obviously do better than HTTP+JSON; meanwhile we've had a lot of pressure from Weechat to start using a better transport (e.g. websockets) for them (https://riot.im/app/#/room/#matrix:matrix.org/$1477998960439... meanwhile Ralith (the author of the NaChat Qt matrix client) has been working himself on a capnproto transport due to wanting something faster & better than the baseline.
So we're not particularly worried that most people will stick with the baseline for daily usage. Instead, it'll act as a really nice and easy on-ramp for new developers, debugging/deving on the API, etc. Anyone serious will end up using a better transport.
Finally: it's worth noting that adding E2E by default into Matrix increases the complexity of clients enormously - so we expect the plain `curl -XPUT /_matrix/client/r0/rooms/.../m.room.message --data { "body": "hello world" }` style APIs to increasingly be just for experimentation, initial dev and prototyping. As soon as you want to start talking E2E folks will reach for a full client SDK, at which point they will get access to both E2E and whatever weird & wonderful transports that SDK happens to provide. So, again, the majority of users won't be on plain ol' HTTP.
Yes, but which messaging service will the nontechnical user use? The one where they can exchange usernames, or even phone numbers, and it Just Works? Or the one where they have to give their friends a long alphanumeric sequence of gibberish?
It doesn't benefit them if they don't use the protocol.
>ToxMe requires trusting the ToxMe identity provider, and is an obvious point of attack. And we'd no doubt see fake addresses that resemble other peoples, and other such nonsense.
Obviously. This is why it's a bad thing that nontechs will probably go in that direction, if they use Tox at all.
>(with ideas like the QR code feature they have)
I was hoping somebody had implement QR: that helps a lot, but I'm not sure if it's enough...
There's no benefit from using the protocol if it gives up security for convenience like the others.
> Obviously. This is why it's a bad thing that nontechs will probably go in that direction, if they use Tox at all.
My point exactly.
Conversations / OMEMO is a great Android messaging client, but it's ONLY available for Android and a desktop client (Gajim OMEMO plugin). It can use OTR (which it marks as less secure) but there isn't even a decent iOS OTR client anyway. ChatSecure iOS will probably get OMEMO and push support along with becoming a more decent client but it's going slowly. Until that happens, Conversations is problematic because there isn't a decent way to talk to iOS users.
But if his journalists are using Android or iOS anyway, there's no practical advantage in Signal not depending on GCM or the Play Store, and some real disadvantages (like less secure updates). So the whole complaint seems like rather contrived to me.
(I would contest the claim that running a massive, not-practically-auditable open source OS is actually any more secure than running iOS or Android+Play Services, but whatever.)
Osomocombb is the closest we've ever gotten.
No, they are sharing (tel:+12025551212 signal:a31d79891919cad24f3264479d76884f581bee32e86778373db3a124de975dd86a40fc7f399b331133b281ab4b11a6ca) pairs. Alice and Bob determine that they both know Charlie; Alice and Bob then — since they both know one another and both know Charlie — feel good about sharing with one another what Charlie's Signal ID is.
> So this protocol can only help people discover contacts they are not yet aware are Signal users.
Which is exactly what Signal's current contact-sharing protocols does, in addition to helping Signal discover all of one's contacts.
> I would continue trying to give you what I thought were constructive technical criticisms, but apparently you interpret that as me being "invested in hating" the idea.
I will give you the benefit of the doubt and assume that your repeated failures to understand the protocol and its requirements are due to by own poor explanations, and further that you actually intend to be constructive.
> It's more like I'm invested in providing good user experiences for security tools, which often involves starting with the user experience you want to provide and working backward, not starting with a cryptographic algorithm and trying to bolt-on a good user experience.
I'm starting with a principle, not a protocol. That principal is that: online service providers must know the absolute minimum amount of information to do their jobs. Ideally, instant messaging would use some form of private information retrieval protocol so that server couldn't know who is talking to whom. Given Signal's current architecture, it must know to whom one is talking; there's no reason for it to also know everyone to whom one could be talking.
> The latter is how we wound up with a pervasive ecosystem of unusable security tools that Signal is a refreshing departure from.
Is it better to be usable but insecure than unusable but secure? I think the answer is mu: a product must be both usable and secure. Granted, security is always in the context of some threat, but it should be possible for users to intuitively grasp the security context.
> You are starting with a protocol, not thinking about the user experience
So, what do you think the user experience of contact discovery should be? I've already demonstrated that my proposal has an identical experience to Signal's, with the exception that one must manually register contacts not know to one of one's contacts. How would you implement contact sharing without giving OWS access to everyone's address book everywhere?
I said that for me they are basically equivalent. And for now I pick Telegram as the best compromise I'm going to get (still using my mobile number, still a silo, crappy encryption vs usability and cross-platform/multi-device support).
You seem to say that people should cheer for Signal so that people that NEED the secure messaging features aren't lured into the wrong direction. That makes sense. But if someone reads HN for secure messaging recommendations .. I kinda expect them to read more than a single comment and do a bit of research.
People are pointing out that Signal doesn't satisfy some requirements for their individual needs. It's not a "You shouldn't use Signal" (which would be bad), it's a "You might not like Signal, if .. " listing reasons like federation and identity. In this setting here I think that's fair and reasonable. No harm done, no danger for a random person stumbling upon these discussions and dismissing Signal because a random person online said that it doesn't support federation.
Signal is a nice project, I'd recommend it for everyone that has hard requirements for their secure messaging solution. I still don't want to use it myself and feel that it's fair to point out why Signal cannot cater to everyone. That doesn't harm Signal or its global perception, I think.
But please remember the article we're actually commenting on starts like this:
One of the things I do is cryptography and infosec training for investigative journalists who have a need to keep either their sources and communications confidential so they can more safely do their work in the public interest.
Wishing that Signal would do things differently? Fair. Not recommending Signal to these users if it is your job to train them? Not a good idea.
As long as Telegram isn't compromised by USA-allied countries (Iran is somewhat allied with Russia), it might be a safer choice than Signal for US journalists. The reason is that USA can easily send a letter to Google that would reveal a lot about that person + they have root on the device.
Just like the safest place for Snowden right now is in Russia.
I just wanted to add some details: someone checked the Iranian phone numbers range at Telegram servers and learned which of them are registred with Telegram. Message contents or contact lists were not obtained.
I guess this attack could be done with other apps that use phone numbers and phone contact lists for identification.
But once a node is acutually inside the DHT, it should never need to talk to the bootstrap nodes ever again: that's a pretty major win, in some respects.
Edit: OK, I get that maybe these are non-issues.
As usual, security threads consist of ancient beliefs, non-users and stories of low-conscious people using high-tech software. And there is always someone who mentions whatsapp as an alternative. Things like wickr are not even mentioned here.
Google definitely has root on your phone, but is that automatically an implication that Signal is compromised?
Do you have any pointers on how Play bypasses local signature verification? I'm surprised about that.
In what sense are they more secure using stock Android than CopperheadOS? They wouldn't be installing it themselves either way. It's a product available for purchase too... have you done any research into what it is before making claims about it?
> Do you have any pointers on how Play bypasses local signature verification? I'm surprised about that.
Play contains a bunch of privileged / platform signature apps. They don't follow the regular permission rules. An unprivileged app not signed with the platform key cannot do automatic upgrades and counts as an unknown source. The Play Store chooses to bypass the trust-on-first-use signature checks of the package manager too. Upgrading apps via F-Droid or manually will perform the signature checks, but the Play Store does not. Try installing an app from F-Droid on a phone with Play, and note how Play will happily clobber it with an update signed with a different key. On the other hand, F-Droid won't do that even if you sign it with the platform key as CopperheadOS does to mark it as a unknown party source.
Eh, that’s exactly what it is currently advertised as.
A tool, supported by Snowden, to be used by journalists who are at risk of being under active surveillance by state actors.
That is the very definition of a TAO target.
And for non-TAO targets, WhatsApp is just as good as Signal – the users won’t read the source code anyway, and in both cases President Trump gets your social graph.
Aka NSA's "we really need to get access to this device and will fund diverting backbone traffic / writing firmware malware / whatever else we need to in order to get it" team(s).