Wrong signal
it-kollektiv.com
it-kollektiv.com
- phone numbers allow for signal to be a drop in replacement for other messaging apps with minimal to no registration required, I doubt I could have gotten my mother to use signal without switching from texting being so low-friction.
- lack of federation means ows can control spam better unlike in a federated environment where lazy/malicious operators can cause lots of problems. Take a look at the 2 big federated protocols email and irc where due to spam and other issues they are both increasingly centralized.
The entities most harshly critical of Signal are supporters of other messaging applications and protocols.
I think the most important thing to understand about secure messengers is that messaging in general is a back-ally knife fight of a market, one of the most vicious I've seen in my career. Perhaps it's because of the WhatsApp outcome and a general belief that there's another such outcome for some other messaging app. Or it could just be the network affect. Messaging applications themselves are interesting UX challenges, but as programming challenges they're pretty close to socket projects. So there are a lot of entrants in the market. Whatever the reason, the knives are out for Signal.
I don't so much care what messaging system you use to talk to your friends or chat with your gaming guild. But if you have real adversaries, the security part of your messaging system has to work, even more than the messaging part. For that situation, Signal is the only messaging system I'd recommend unreservedly.
Sorry, but I am still yet to see the proclaimed unanimous support for Signal as a messenger. As a protocol – sure, most infosec professionals obviously support Axolotl, but this does not imply your statement in any way.
> The entities most harshly critical of Signal are supporters of other messaging applications and protocols.
So the support for Signal isn't that “unanimous” after all, is it?
Otherwise, of course they will if they think that Signal has lost the proper direction for some reason (according to their view). Even many protocol supporters prefer using something like WhatsApp or Wire, the former due to its purported network effect and the likes of the latter because of features like E2E encrypted file transfers, 1:1 video or group calls w/o apparent security trade-offs compared to Signal.
> I don't so much care what messaging system you use to talk to your friends or chat with your gaming guild. But if you have real adversaries, the security part of your messaging system has to work, even more than the messaging part. For that situation, Signal is the only messaging system I'd recommend unreservedly.
In the end, it turns out that this is your personal opinion, not that of the security community as a whole (hint: there is none), which is fine if you didn't misrepresent it in most of your post. The networks of other people may or may not choose to go a different way, although some (or even many) of them may support the same core technologies, just because they do not agree with some decisions OWS made along the way and don't want to reconsider for any reason opposing parties have presented, e.g. in articles like the one we are commenting under.
To sum up, feel free to suggest Signal as an instant messenger, but please be careful with your supporting claims because there are other great and upcoming messengers out there like Matrix, Wire, Onion.chat, GNU Ring, any of the mentioned elsewhere Telegram and WhatsApp, or many, many others. Signal has legitimate reasons on its side that will make your argument weigh more than unjustified claims that it should apparently be the end-all and be-all of one's instant messaging needs.
A good way to rebut my claim would be to cite the most high-profile security engineer or security professional or crypto engineer or crypto scientist you can think of who recommends some other system over Signal.
If you believe people with state-level adversaries should exclusively use transparent and open hardware, that's fine; you should see Moxie's comment on this thread to learn how you might go about ensuring that the tiny minority of users with that hardware have access to Signal on it.
That's because when it comes to security often theoretical vulnerabilities end up being protocol-destroying vulnerabilities in practice. Security folks are notorious for saying, 'that won't work,' being ignored — and then everyone being surprised when indeed it doesn't work.
> phone numbers allow for signal to be a drop in replacement for other messaging apps with minimal to no registration required
The issue is not allowing phone numbers as identifiers: the issue is in not allowing other identifiers. There's already a URN scheme for telephone numbers, and there are URN schemes for many other identifiers, to include email addresses, and there are even ways to add additional schemes. If Signal used URNs rather than telephone numbers, then users could continue to use telephone numbers but advanced users could use other identifiers, as they wish.
> lack of federation means ows can control spam better unlike in a federated environment where lazy/malicious operators can cause lots of problems
A spammer cannot spam someone whose public key he does not know. If there is no central directory of identifiers to public keys, there's no way for a spammer to send spam. It is possible for someone who knows one's public key to spam one, but since the sender's public key is tied to a public identifier, one knows who sent the spam.
Does Signal perform any anti-spam activity anyway?
we're not talking about protocol destroying bugs, were talking about things firmly in the realm of trade offs between marginal security gains and usability with security folks tending to be far too focused on marginal security gains while loosing sight of the big picture of less then perfect security that people use is better then perfect security that nobody uses.
I.E. ChaCha is better then AES because it is more resistant to side channel attacks among other things, but if you are creating a TLS server and can only choose one algo, you probably want to choose AES because more browsers support it compared to ChaCha and the marginal gains from ChaCha probably don't justify excluding those users that don't support it.
> If there is no central directory of identifiers to public keys, there's no way for a spammer to send spam
If there is no central directory of identifiers to public keys, there's no way my mom will use it to send me anything
She'd never use an app where you two bump phones with NFC?
I think an IM which relied on in-person seeding and then bootstrapped with mutual contacts could be quite powerful, and easy to use for newbies too.
I still have the biggest difficulties to persuade my "normal" friends and relatives to prefer signal over whatsapp.
Everybody thinks whatsapp is more user friendly and convenient. In the end this is the key to adoption we should not forget that.
The criticism of signal's closed ecosystem is not new, this is just another write-up of what has been criticized numerous times before.
In the long run federated protocols and servers demonstrated their resilience regarding third parties and time, see irc for example.
Probably Signal is just a reference implementation, the big deal is implementing Signal protocol in different systems (whatsapp, allo, fb messenger..).
Having said that, I would be happier to not give my phone number for registration, and contact discovery but this is today a user interface well understood and accepted outside geek communities that's hard to eradicate.
Strongly disagree. The point of Signal is not just that it's encrypted. The point is that the source code is GPL and the service is free. Holding up a bunch of closed-source, proprietary, for-profit applications as examples of success only serves to obscure what should be the real goal: decentralized, anonymous, metadata-less, encrypted communication that anyone can easily use. Signal could be much closer to that goal but OWS & moxie refuse to allow decentralization or anonymity for bad reasons.
You are describing what should be the goals in your opinion, not the one of Signal's developers.
Having something that works to show (Signal), was a big point to sell to those, closed and already used by many people, systems; so having a non federated Signal means they can iterate more often and change things how they more or less want.
For example, their assertion that "... metadata is abundantly available here" appears to be patently false, given [0].
0: https://www.aclu.org/blog/free-future/new-documents-reveal-g...
Whether or not such metadata is available to adversaries (either through OWS or gathered elsewhere) depends on who your adversaries are and whether or not a corporate entity can be trusted to be completely transparent about what kind of data they retain.
As for [0]; even if no relevant metadata is collected today by whoever owns the servers, nothing stops the party providing the service from doing so tomorrow.
Conversations.im was (or is, haven't checked in a month) logs encrypted chats on cleartext by default, and history shows why that is a bad idea [0]
Until today I haven't seen a single XMPP that protects metadata, the roster is always on cleartext, to support omemo you are storing yet more info always, etc.
If the answer to Signal issues is XMPP, there is a lot of work to do before to even suggest going this path.
This is a point I see bought up a LOT. I don't believe it to be useful however - proceeding down this rabbithole rapidly leads us to a place of advanced paranoia where we can't get anything useful done. Once you start assuming actual malice on the part of the software developer, even open-source code with the ability to run your own service doesn't protect you - there's multiple ways backdoors can be inserted in sufficiently subtle ways it's extremely unlikely they will be spotted before it's far too late for you.
> using strongly identifying codes (phone numbers) as the required identifier — i.e., it is nearly impossible to create a throw-away accoun
Identifiers are only valuable if there is something to link that identifier to. Account creation time and last active time are very unlikely to be valuable to your adversary (for any definition of "your adversary" you had a chance at defending against in the first place). In other words, as long as the only data they have is your phone number, then that's not helpful. All that is is a record of a) this phone number exists (which is not secret) and b) this phone number uses signal (which isn't a secret either to any even mildly motiviated attacker).
When it comes to security, today's advanced paranoia is next year's common sense. Remember that folks used to think that telnet over the Internet was harmless.
Would OWS refuse to implement a court order directing them to collect and forward metadata? I don't know.
So the less than perfect steps we have been seeing recently (widespread transport encryption in email, end-to-end encryption in WhatsApp and Signal) are a huge improvement.
Let's assume OWS is playing nice, and they really don't store any relevant metadata. How can we be sure that a third party is not eavesdropping their communications?
Even with end-to-end encryption, given enough time, an attacker can easily build a user relationship network, something _very_ dangerous in the wrong hands.
If you really care about privacy, you should consider options like BitMessage, Onion.chat, Ricochet, Tox or GNU Ring. Or, as a middle ground between those (which are quite mobile unfriendly, due to its P2P nature) and Signal/WhatsApp/Telegram, a federated service like XMPP (as the article suggest) or Matrix.
Even if it is claimed that the metadata miraculously wasn't collected (provided it really wasn't collected under some other publicly invisible arrangement, which is still technically doable) that doesn't prove it is impossible to do so, especially as the result of another secret request.
I don't see the "FUD" in the article. It seems very popular using labels instead of talking about issues, but please, please don't.
The phone number problems were known since long, and the Signal's explanation "it's easier for the average user this way" doesn't explain why other alternatives aren't even allowed.
It's obvious there are certain goals behind Signal, and those with different goals have to organize themselves. What they surely can't do is claiming to have right to decide what Signal (as a company) does. If those who have clear needs want to introduce their own solution, they surely have to demonstrate what the Signal doesn't solve, and that's surely not FUD.
There's nothing unduly alarmist about the article, but it makes appropriate claims about (among other things) the security limitations that Signal has resigned itself to by remaining unfederated. Read TFA.
I tend to use Whatsapp because other people already have it but I have absolutely no motivation to use encourage other people to use Signal.
Edit: Whoever down-voted this, want to explain how this isn't a huge user-experience regression from giving your email and using gchat?
The phone number linking seems completely superfluous and has destroyed the user experience for me by preventing me from connecting with anyone else.
This design decision will become increasingly anachronistic in the near future, as phone numbers further diminish in importance.
I feel that providers that use number-as-identity know this and use it as a way of assuring they have greater confidence of knowing their user, especially after everyone failed so spectacularly at real names policies.
I entirely disagree. Even without traveling outside the US - my US phone-number has changed several times (change of carrier etc.); while it is possible to spin-up and shutdown email accounts (e.g. dummy accounts for services requiring registration) -- by this time most individuals should have a single serious account (and a larger percentage in the future): online bank statements, online bills, online shopping -- do you really not have a single primary account?
This must be even more true when moving to another country.
(Surely, there also must be some exceptions as well, where maintaining old number is an option.)
Oh FFS. We've seen a continuation of invasive, Bush-era policies under Obama...but now Trump is terrifying?
Spoiler alert: it has been a problem for quite some time, and given the alternative to Trump it was going to still be a problem regardless of who won the election: freedom ponies and rainbows were never an option.
Get a damn grip, people. Can we end the partisan pity party?
Uh, yeah. The Bush/Obama surveillance policies have largely been seen as dangerous not because of actual concrete harms that have materialized, but because if continued they raise the prospect of a much worse (because of the increased scope possible with modern tools) version of the kind of political targeting based on surveillance that was done by Nixon (prompting legal limits, notably the original FISA act.) And perhaps even beyond that, to the kind of retaliation for dissent seen in authoritarian regimes.
Trump is seen as the kind of figure that would be more likely than a more conventional candilate of either party to make those theoretical risks into concrete harms.
The house is already on fire, and people are wringing their hands because the new owner might have a can of lighter fluid in his pocket.
I don't think many serious observers think that, whatever the potential, the actual substantive harm has yet been even close to Nixon levels, though the potential scope of intercepted communication (and hence, potential for harm with simply a change of intent at the top) is much broader.
He is about to enter the house and does not believe jet fuel can catch fire.
I don't see the federation issue as being particularly relevant - at least not until someone else actually sets up a non-OWS server and gains some users for it.
> The drafted protocol is called OMEMO and combines the advantages of jabber and Signal. Even though the XEP Process will still take some time, the protocol is stable and can already be used today. On Android devices, users have the ‚Conversations‘ client [8], which offers an experience comparable to Signal, and on the desktop there is a plugin for ‚Gajim‘ [9, 10] under active development, which still has room for user experience improvements. Using one of the readily available tutorials, it is possible today to get started on Linux and Windows. iOS users will have to wait some time due to license issues.
Does Signal publish registration numbers?
I asked them if there had been something that prompted them to install it, they said it was my other contact (the first one) who told them about it.
I rarely do any proselytism.
> Signal uses servers controlled by OWS. Other organizations could conceivably operate their own servers because OWS open sources the software, but because OWS strictly opposes federation (meaning the interconnection of independently operated servers which the XMPP protocol (jabber) or e-mail allows), only the users connected to the OWS-run server can communicate with each other.
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.
> If a government does not approve of the use of Signal, it can simply block a single server farm, solving the problem for the state actor, and resulting in total loss of service to the users.
The authors of this article conflate a lot of things with federation. Federation = anonymity, federation = metadata protection, federation = censorship circumvention.
I don't think any of those are true. Email is federated, and I run my own mail server, but almost every single email I send or receive has GMail at the other end of it -- so running my own server does not provide me with any meaningful metadata protection, even though it is a federated protocol. The idea that everyone in the world is going to run their own mail server (or messaging server, or whatever) has not born out in practice, even in environments that natively support federation.
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 environments that can change rather than federated environments that are stuck in time (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).
In the case of censorship circumvention, I think it's much more common that people use censorship circumvention tools like VPNs or Tor rather than changing their entire federated identifier (and somehow re-discovering their entire social graph doing the same) every time a service gets blocked, particularly since censorship isn't just as simple as host-level filtering these days.
Again, I think we're more likely to see the incorporation of these types of censorship circumvention techniques into centralized rather than federated services.
> The community reacted to this by developing a version that does not rely on GCM, however, OWS refused to merge the changes into the Signal code.
I don't believe this is true. 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.
> The final point of criticism is that OWS distributes the Signal app exclusively via Google Play while actively preventing the distribution of independent builds.
We'd love to distribute Signal outside of Play, and have written about what we would need to be able to do so. As of yet, nobody from the FOSS community has stepped in to help.
We'll get there eventually on our own, but we have a lot of work on our plate, and have to set our priorities according to what we think is important for Signal as a whole.
> The community’s demands for decentralized web services controlled by the users themselves, or by designated professionals elected by the users, seems like a burden to them.
I do not feel like the FOSS community is a "burden," however I do wish they recognized that many of their desires are unique to a very small minority of Signal users. I wish that they'd take more responsibility for manifesting those desires themselves.
This is the second time in two months that someone from the FOSS scene has written up a list of complaints, but as far as I know, in neither case have the authors ever contributed anything to Signal in an effort to meet their own needs.
The biggest problem that we (my whole friend group) seem to be having is that we can't find each other due to the fact that we don't use phone numbers for communication.
Are you thinking about ways to resolve this problem?
Is it any less secure to use email addresses for identification and discovery than phone numbers?
What about ways to share a unique user id?
I think that the interest in the FOSS community is relatively low given the centralized format in which Signal is offered. I know many people who are deeply into FOSS who would love an alternative to IRC but cannot be found even using Signal. But "their own needs" are completely out of bounds for you, and it seems pretty clear that this isn't something that's going to be fixed in patches and code, so expecting them to come and fix it because you have an open code base is rather disingenuous.
If you started by promoting Signal as a generic protocol or backend to other projects, it would get much more traction in the FOSS community, as they are attracted to components on which other things can be built.
You can claim that this is a reason to ignore the criticism. But, you will always be right in dismissing critiques like this as you've set up the environment in a way which limits the kind of constructive collaboration that is the hallmark of FOSS.
You will probably say this is not true and cite existing public contribution to the project. But what I am saying is that the interest and contribution would be orders of magnitude larger if you really ran the project in a traditionally open way. One hallmark of this would be federation. Whether or not this makes sense practically (the gmail metaphor applies obviously), it is something that people want an need to order to feel they have ownership of their work on a messaging platform. You're simply not going to talk your way out of this.
For human and community reasons, the upside to federation is probably a lot higher than you appreciate. I hope you consider it. You have built a nice platform, but for your work to make a lasting impact you need to share it with others.
Many of the things listed in these articles, such as making GCM optional, or supporting distribution outside of Play, are not "completely out of bounds." We've expressly indicated support for them and enumerated the work required, but nobody has committed to doing the work.
I don't expect anyone to do the work, but I do think it's strange when someone from the FOSS community complains that we haven't done it for them.
> If you started by promoting Signal as a generic protocol or backend to other projects, it would get much more traction in the FOSS community, as they are attracted to components on which other things can be built.
Signal is broken into three layers, two of which are designed to provide exactly that:
A crypto protocol that can be incorporated into other projects: https://github.com/whispersystems/libsignal-protocol-java
A service protocol that can be pointed at any back end: https://github.com/whispersystems/libsignal-service-java
The service protocol even includes support for federation. I don't think it's a good idea for the reasons I've enumerated, but anyone can use this code to start their own federated network and prove me wrong.
> For human and community reasons, the upside to federation is probably a lot higher than you appreciate. I hope you consider it. You have built a nice platform, but for your work to make a lasting impact you need to share it with others.
We've done more than consider it, we've done it. We started Signal as a federated service, and it was kind of a disaster.
I'd definitely reconsider if people have a plan for avoiding the problems that we encountered the first time, beyond "federation is good." In the mean time I'm happy to help anyone deploying Signal in their own federated environment.
> I don't expect anyone to do the work, but I do think it's strange when someone from the FOSS community complains that we haven't done it for them.
The linked article notes that you have not been so supportive of such developments in the past:
> The community reacted to this by developing a version that does not rely on GCM, however, OWS refused to merge the changes into the Signal code. When the project was forked, they prevented the newly established LibreSignal project [5] from connecting to Signal’s servers and prohibited the use of the term “Signal” in their name.
Reading through the comments that are linked it looks like you mostly had technical concerns about the work. Is that correct?
Clearly the perception of your actions is different than you intend. In your comment here you make it sound like no one had even attempted to do resolve these issues. But that's not what the author of the article believes, and given the public record I'm inclined to agree.
> I'd definitely reconsider if people have a plan for avoiding the problems that we encountered the first time, beyond "federation is good." In the mean time I'm happy to help anyone deploying Signal in their own federated environment.
Your key point is that you're content if people do federation in their own, outside of your domain. That's fair. But what I'm saying is the dream of a federated secure messaging system that's also popular is something which you have the power to chase if you commit to it by making it a core feature of Signal.
> Clearly the perception of your actions is different than you intend. In your comment here you make it sound like no one had even attempted to do resolve these issues. But that's not what the author of the article believes, and given the public record I'm inclined to agree.
From that original discussion on LibreSignal:
"If the only thing that the remaining people here want out of LibreSignal is a websocket-only solution and gmscore isn't an option for whatever reason, 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. However, I also realize that still won't help people that are trying to build a Google-free experience on Google's platform, since we still don't have the things we need to be comfortable distributing software outside of Play."
I have repeated that many times. That was June. Nobody has done the work, but plenty of people have written articles like this. The latter is definitely easier.
> Your key point is that you're content if people do federation in their own, outside of your domain. That's fair. But what I'm saying is the dream of a federated secure messaging system that's also popular is something which you have the power to chase if you commit to it by making it a core feature of Signal.
Again, we already committed to making it a core feature of Signal, and it was a disaster. We've learned from our mistakes.
If it's something that you think is important, please get involved in the project and come up with a plan to introduce federation in ways that actually deliver on the promise of metadata hiding, anonymity, and censorship circumvention as well as avoid all of the problems that we documented based on our initial attempts.
How is Signal offered in a 'centralized' way? There is a free and open-source implementation that already (according to Moxie) supports federation. And a standing offer from the authors to help anyone doing further work on federation. What more could one reasonably expect, short of demanding OWS do the work.
Yet, they "worked with" Facebook and WhatsApp to incorporate their protocols presumably providing them with an alternative license. It sure would be nice if companies who wish to add encryption to their messaging products, but didn't have the pull of the bigger guys to warrant OWS's attention, could just use an LGPLed library to do so. If OWS's mission is to bring about widespread encrypted communications, playing favorites with a few larger messaging companies seems to send the wrong message.
(The points made in the article, while valid, seem to be splitting hairs relative to the overall net good Signal has provided.)
Quoting:
There are many things users can and maybe should be concerned about: Hackers, providers, promoters, crooks, spooks, shareholders or maybe the person on the next seat in the bus. Do they want to prevent their data from being used for other purposes than communication itself? Maybe they want their messages to be tamper-evident, or perhaps they want plausible deniability or immunity against eavesdropping? What is the use of end-to-end encryption when there could be a key logger or a rootkit on their device, transmitting everything they do to a remote entity? Encouraging users to believe in a general sense that Signal makes their communication safe, will tend to promote a false sense of once-and-for-all security (regardless of the indisputable and substantial increase in end-to-end encryption). It is very important to remember that even though encryption will increase security, some information should not be stored in IT systems at all – and especially not if they are provided by a third party.
However this is no argument against the use of the Signal messenger or protocol itself. We instead want to think about the problems created or supported by OWS‘ promise of security.
I don't believe this, as it would make programs like QUANTUM* unneeded. Why subvert global internet infrastructure if the providers do the dirty work?
This would be explosive if true