Hacker News new | comments | ask | show | jobs | submit login
Signal Foundation (signal.org)
1314 points by conroy 12 months ago | hide | past | web | favorite | 284 comments

This is freakin' awesome:

A non-profit foundation with $50 million in the bank dedicated to providing usable encryption to the general public, with no other agenda other than the public good.

Go read the blog post by Moxie and Brian Acton (who is joining Signal). Very exciting!

I hope they eventually develop a federated, privacy oriented messaging protocol, once the rapid technological evolution settles down.

I know Moxie's position on federated protocols [1], but I think we must eventually agree that an open environment with a multitude of providers and implementations is the only way to provide long term privacy - any single provider is vulnerable. It would also be a very useful tool in the context of regulating communication platforms and breaking up monopolies.

[1] https://signal.org/blog/the-ecosystem-is-moving/

Edit: emphasize federated, not open, Signal is indeed an open protocol.

Signal Protocol is one of the best documented cryptographic message protocols on the planet, and is accompanied by multiple GPL'd implementations.


which sounds like it could be used to develop a federated protocol. I've heard there is an effort to do an RFC on the subject, but I'm not sure it uses the Signal protocols (for some reason), also there are two of them (I'm confused):

* https://tools.ietf.org/html/draft-barnes-mls-protocol-00

* https://tools.ietf.org/html/draft-omara-mls-architecture-01

Using OMEMO on XMPP is a federated implementation of the Signal protocol. I believe Matrix' e2e encryption is also based on it.

I’m really hoping OMEMO makes it into Openfire (XMPP Server) and Adium (XMPP Client) sooner rather than later, we current use OTR but OMEMO is objectively superior in every way I can see.

In general, servers should have nothing to do with end-to-end encryption, except for not actively breaking it.

OMEMO in particular uses:

- Personal Eventing Protocol (PEP, XEP-0163) to transport key material; and

- core RFC3920/RFC6120 XMPP protocol to transport encrypted messages.

Both of which are already supported by Openfire [see JM-1122]. So, as far as I can tell, Openfire is fully capable of delivering OMEMO messages right now.


[EDIT] For Adium OMEMO support, have a look at Lurch: https://github.com/shtrom/Lurch4Adium

I don't think Adium is doing much in terms of active development sadly.

Do you consider SMS a federated protocol?


SMS is federated, users of one providers can send messages to users of a different provider. Same with phone calls. Becoming a telephony provider probably takes a bit more investment than with some random Internet based service.

Unfortunately, it looks like the signal people are possibly not friendly to third-party devs and have levied seemingly spurious IP threats against third-party implementations: https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7

Obviously this is just one side of the story, but it sounds rather alarming.

I believed this was debunked by moxie somewhere on HN

Would you mind linking it? I've tried to see his past comments but couldn't find anything dated after the blog post on a first look. Just a lot of LibreSignal stuff.

Extract from that comment:

> We haven't patented any of the concepts here, and we've done a lot to explain and popularize them. We're happy for people to use these concepts to build their own implementations of similar protocols, but we don't want people slapping things together and calling that Signal Protocol.

That doesn't debunk anything in the blog post - it reinforces the point that moxie doesn't want any third-party implementations of the protocol.

It sounds like they'll defend the Signal trademark, but not the implementation concepts. I don't see how that's bad.

Especially with crypto, one small implementation error could ruin any security value. It's completely reasonable that they don't want their trademark used with code they aren't responsible for.

Yeah. "You can do whatever you want with our GPL'd code, so long as you follow the license, and we don't have any patents, just don't use our name/branding on stuff we don't control" is a reasonable way to ensure the reputation of your name. It's the same thing Firefox does with Linux distros who want to add their own patches.

> It's the same thing Firefox does with Linux distros who want to add their own patches.

"did", I think. I don't know which distros still run into this, but Debian now ships Firefox (RIP Iceweasel).

Or, conversely, modifications could add to the security value.

Did you read the license?

It’s just one side of the story, but after Moxies comments regarding LibreSignal, third-party clients, etc, it’s hard not to believe it.

And Moxie disallows people from building third-party clients for the server where 99% of Signal users are on, and without that, group chats aren’t useful.

Since when? You by default use the main servers when you install Noise or signal-cli, despite how Moxie may dislike this fracturing of the Signal client ecosystem.

Moxie still disallows their use of his servers, they just disregard his demands.

And yet even the best of the best cryptographic protocols provide little to no value on very insecure systems like iphone and android.

It's like bike shedding of security, where Moxi focuses on the things he can do but for the systems where it doesn't matter.

I find it odd that someone would say an iPhone is “very insecure” after the USG, of all players, very publicly couldn’t get into a model from right before the security design hardened, not to mention the also very public panic in the IC about losing access to intelligence due to mobile phone developments. That’s a strange position to tout with the underlying implication that PC platforms are better.

Are you broadening “insecure” to mean “centralized, opinionated security architecture designed for tech-illiterate masses that I don’t like?” Because that isn’t what it means.

Very secure means high-assurance for both hardware and software, very insecure means no assurance for neither hardware, nor software, with control over system belonging to multiple third parties and what not, basically consumer stuff. And threat model for this consumer stuff just doesn't include an adversary capable of intercepting all of your communication and cracking less secure protocols, this is just silly. Because with such level of capabilities an adversary can just target a whole bunch of third parties that have control over your system, penetrate one of them and push a fake update to your system with screen grabbing malware or whatever. By the way, this is an example of a real world attack.

I thought that ended with the government getting into the phone using an exploit, just without forcing Apple's cooperation.

Hence the hardened part. That exploit doesn’t work against any later model, and they spent a lot of money to get into that particular phone. Even with that observation, how can one claim “very insecure?” Do you think it’s that difficult to compromise a PC with physical access? What does secure even mean to people any more?

I trust my phone a hell of a lot more than any general purpose computing platform, and I’d say the same if I owned any number of a significant collection of Android devices. This isn’t phone vs. phone advocacy, just annoyance at opinions that people disingenuously consider factual, useful observations on security.

Only after they paid an Israeli security company for a 0-day vulnerability, which allegedly cost north of $1m.

Interested to know how that amount compares to other OSes, I really don't know what the going rate is on Windows/Linux.

And this was a vulnerability that concerned an iPhone 5c, which did not have a secure enclave. The iPhone 5s was the first model with Touch ID and an secure enclave.


I would question how much of this was not being able to get into it and how much was a platform for "we need backdoors into everything".

Ever ask yourself why they did this "very publicly"?

To convince congress to legislate a backdoor.

There are very logical and reasonable reasons for them to advocate publicly. Not everything is a conspiracy.

> I hope they eventually develop a federated, privacy oriented messaging protocol, once the rapid technological evolution settles down.

Like matrix[1]? That uses signals encryption.

[1] https://matrix.org/

You mean, Matrix does not pose arbitrary limitations to clients that want to use end-to-end encryption. Clients that do not yet feature it by default, and that give huge warnings when you try to enable it. Clients that have problems with complex navigation when trying to verify fingerprints. Matrix is not the future, because at some point you're going to need to defeat metadata, and decentralized platforms can't do that. The future is in apps like Ricochet and Briar.

To be fair; Matrix's crypto is fairly solid. The key management however is a mess, and we have run late on fixing it - but we're working on it currently. The metadata concern is bogus however: we designed Matrix to evolve into a hybrid p2p/decentralised architecture in future without changing a line of clientside code, so folks who want to store their metadata on their client rather than their server can do so - https://matrix.org/~matthew/2016-12-22%20Matrix%20Balancing%... has some notes on that. In practice, we think neither pure federation (like XMPP) or pure p2p (like Riocochet) or pure centralisation (like Signal) is desirable - you want to have a hybrid of decentralisation & p2p so you can get the best of both worlds.

What are the benefits of decentralized servers over p2p?

"Metadata concern is bogus" yet the linked documentation explicitly says bridges expose metadata, and that home servers expose metadata.

One advantage of Pond-hybrid is "Supports any and all Matrix clients via the existing standard client-server API". This means the issue is desire to remain compatible with insecure clients. This is lack of agility is not needed.

I hope you fix things before it's too late and focus on Pond or other Tor hidden service based communication.

> What are the benefits of decentralized servers over p2p?

* A server-based system gives you a well-defined secure place to keep an always-on copy of your data, with whatever physical/geographic/network security model you prefer... rather than smearing it across a bunch of handsets or laptops which could get lost/stolen/run-out-of-storage etc.

* Thin-client protocols like Matrix or XMPP are going to typically use way less battery and bandwidth than maintaining a full p2p mesh on a mobile device, which is generally desirable. The way to fix that in p2p is to introduce master nodes of some flavour... at which point you're back in a hybrid p2p/federated architecture again.

* A thin-client-first approach also means that you can easily support different clients (and bots/bridges etc) rather than the client being tightly coupled to a complicated p2p protocol.

To repeat: i'm advocating a hybrid p2p/decentralised approach - not religiously pure decentralisation, nor religiously pure p2p either.

> "Metadata concern is bogus" yet the linked documentation explicitly says bridges expose metadata, and that home servers expose metadata.

My point was that in the medium/long term we have a clear route to avoid having to expose metadata on servers.

> One advantage of Pond-hybrid is "Supports any and all Matrix clients via the existing standard client-server API". This means the issue is desire to remain compatible with insecure clients. This is lack of agility is not needed.

You're missing the point. There's nothing insecure about the clients. The whole idea of the PDF is to spell out that you could swap out a federated server for a local p2p-based server (perhaps even running in the client) whilst reusing all the same clients... which now magically become p2p (if desired). This agility is very desirable indeed, given the huge amount of effort which has now gone into writing good Matrix clients like Riot, nheko, Quaternion etc.

> I hope they eventually develop a federated, privacy oriented messaging protocol, once the rapid technological evolution settles down.

Yes. It's hard to get too excited for the 'expansion' of Yet Another Walled Garden. I say this as a long time user of Signal. It's currently the lesser of most evils, but it still has a lot of room for improvement.

If federated communcations is a desire, OMEMO[1] is a thing.

However, there are issues with federated protocols beyond the velocity issue that Moxie mentions. Some of them are technical and some of them are not (see conversations.im comment on doing xmpp notifications on iOS for example), but they do exist.

1: https://xmpp.org/extensions/xep-0384.html

> Signal is indeed an open protocol.

The Signal protocol is public, but not open. It is a proprietary protocol which is controlled entirely by the company behind Signal.

> once the rapid technological evolution settles down

Why wait?

Users don’t want federation.

See also: Adoption failure of Google Talk XMPP, massive adoption of Facebook Messenger and Whatsapp, and AIM before it.

I wish it were different, too.

Users "want" what everybody else is using so they can communicate. If everybody is using a federated protocol, like email, that's what they will want.

You might say it is fundamentally easier to build closed systems and entice users to adopt them, but that's a business aspect not a user preference. Exactly the type of business that's of interest to regulators.

I think users would prefer federated systems. Who wouldn't? Even though most people have probably never heard the word before, they almost certainly use and appreciate federated systems like phones and email.

Do people want federation enough to have to take a principled stance in order to force change? Heck no. And that's the problem: there's no reasonable way for their desire to impact the producer side of the market. Can't vote with your wallet since public IM service is universally free, plus network effects are strong.

Users are being worn down, too. I remember when Pidgin, Adium, Trillian, etc were rather popular. Now most people don't even use those kinds of consolidation apps either, and resign themselves to literally running many separate apps.

This is a crazy mess we got ourselves in, and there is no easy fix. Time machine to 1980 to get a standard out before ICQ, maybe.

> Now most people don't even use those kinds of consolidation apps either, and resign themselves to literally running many separate apps.

IMO that is really one personal hell for me. I blame android and apple for this. I was happy with my N900 where you got one chat application that supported SMS, Skype, XMPP, AIM, ICQ, whatever. The world was so simple back then. Now everything has to be a separate "app", where previous there where just plugins. Such a decline in usability.

Pidgin (formerly known as GAIM) and its subproject libpurple is the one to thank for. Telepathy [1] and Bitlbee [2] are based on that. I used all of these throughout the '00s. Before the Nokia N900, I used a Nokia E71 with Nimbuzz (basically proprietary but it runs something like Bitlbee under the hood on their servers).

Some of these protocols are open, some are reverse engineered. Problem with the current generation is that they're focussed much more on security features such as E2EE. Although before GAIM, we had other applications which did multiple protocols we also had loads of single purpose applications for all these protocols you mentioned and a whole lot more. Back in the end of '90s if you wanted to run MSN and ICQ and AIM on Windows, you had to use a client for each of these. Its basically a cat and mouse game. Look at the history of the Skype support for an example of that.

[1] https://telepathy.freedesktop.org/

[2] https://www.bitlbee.org

As a former user of N900 I get your point, but frankly I don't mind at all. For me it makes no difference if I need to open one app or another, it's the same amount of tapping. So I'm in the camp who wouldn't mind federation, but won't bother to lift a finger for it either.

> I think users would prefer federated systems. Who wouldn't? Even though most people have probably never heard the word before, they almost certainly use and appreciate federated systems like phones and email.

Except that they don't; they mostly use Facebook Messenger, iMessage, and Whatsapp. Those that do use email use gmail, which barely federates (most gmail users never see messages from my personal email address, because google routes them to spam despite my IP never having spammed).

What we've seen isn't users showing how they feel about federated systems, it's users being forced into walled gardens as closed systems added support for open systems, but open systems could not reciprocate, and the market adjusted.

If your choice as a user is to buy an iPhone that can communicate with your Apple friends over imessage and Android friends over hangouts, or buy an android phone and not access anyone through imessage, there's an advantage to Apple there. Google just decided to level the playing field (if slightly) by privatizing the hangouts protocol, and we all lost out a bit because of it.

Federation isn't something most people even experienced throughout all that, so it's hard to think it was factored in, even a few times removed, from their decision.

" it's users being forced into walled gardens as closed systems added support for open systems, but open systems could not reciprocate, and the market adjusted."

We haven't seen users forced to do much of anything. In general, there's multiple ways of achieving their goals. They almost always pick either a proprietary company that likes lock-in or a free, ad-driven solution that sells them out. They neither take time to understand the consequences of that ahead of time nor cared enough to switch in the years I've explained it to hundreds (thousands?) of them. Very, very few would switch. And for social media, it's usually a network effect they're joining where stadiums worth of people would have to switch at once or close together to avoid chicken-and-egg problem. They could collectively use open standards to communicate like open-source IM and buddy lists but most don't given they'll sacrifice control of their data and privacy for convenience.

There is a market effect like you describe where the suppliers benefit from lock-in. That's been steady a long time with even the open standards often intended to catch new customers in lock-in in other ways. On the demand side, though, the masses haven't used open-source as a factor in their purchasing much at all. So, it's not even a differentiator on their end for most suppliers to target. The market didn't even adjust: it defaulted on lock-in strategies for owners' benefit with companies occasionally experimenting with other methods they sometimes reversed.

> We haven't seen users forced to do much of anything.

Well, it depends on how you want to interpret forced. Sure, they aren't required to use a product, but if you've been using Gtalk for years, and that's how everyone knows to get hold of you and how you get hold of people, and it's an open protocol (XMPP) which you can and do use through a third party client (e.g. Pidgin), when they switch to Hangouts you are forced to use their proprietary client and protocol if you want to keep the same contact list without making everyone switch. It's not strictly "forcing", but Google is exerting force to drive customers to a different usage.

I'm not sure any centralized IM service that expected to compete would have done different and survived with any appreciable market share, but that the ones that existed switched is notable.

> On the demand side, though, the masses haven't used open-source as a factor in their purchasing much at all.

The benefits of an open system aren't readily apparent to many people until they start experiencing the problems of a closed system. Closed systems have numerous benefits at the starting stage the open systems don't (for example, a clear way to monetize that works in line with people's expectations and human nature). We were lucky with the internet because it was federated by design (and necessity, pretty much), and grew to the point that it would be too costly to close the protocol before gaining too much popularity. Even so, we're seeing pushes to in that direction. Maybe when the problems of the closed IM systems become apparent enough, we'll actually have some more widespread adoption of open systems. WRT human nature and systems such as these, I'm not sure we've even seen full cycles of how people perceive and deal with the systems (we're only now really having a sizable group of adults that have always had the internet WRT the population as a whole), so a lot of how people deal with open/closed systems over time is still in flux.

P.S. Long time no see/read. Nice to have a conversation with you again. :)

" Sure, they aren't required to use a product, but if you've been using Gtalk for years, and that's how everyone knows to get hold of you and how you get hold of people"

There's the problem right there. They created a dependency on a single provider that could turn on them at any time. Many providers have gone out of business or done unscrupulous things. One should always have alternatives if anything is really important. In this case, they usually solely rely on one provider for convenience when not also cost (sometimes trivial cost). Still true for things like Facebook.

They walked right into a big problem because convenience or apathy about risks trumped everything. From there, they can be forced in the way you describe to go along with what vendor wants. At that point, they might also start switching and/or avoid doing that sort of thing in the future. In many cases, they avoid the switching cost and do the same kinds of things in other services. Their very nature is to willingly create opportunities for suppliers to cause them problems.

Even as they do this, there's a small subset of the market doing either the opposite or taking steps to limit the damage which make me think this is more willing than forced. If anything, history has shown we have to use things like regulations to force market participants to behave more safely on average. They usually don't do it on their own because they don't want to or don't care. Seatbelts when driving are the classic example.

"The benefits of an open system aren't readily apparent to many people until they start experiencing the problems of a closed system."

I agree. We probably need a way to quickly present that when they make these choices. Enough of the market making an informed choice might sustain more alternatives that are better. This already happens with at least some of the FOSS market where the buyers specifically liked the benefits of open source. The wider, long-term effects you describe will also be interesting to watch. We might see some of the FOSS-friendly decisions on consumer side as they see the benefits or experience the detriments.

"Long time no see/read. Nice to have a conversation with you again. :)"

Likewise, buddy. Although I comment less, I've read plenty of yours. Usually insightful and enjoyable. :)

> They walked right into a big problem because convenience or apathy about risks trumped everything.

Well, or just lack of knowledge, and lack of knowledge about lack of knowledge. I think from our positions it's easy to overlook that. Sure, it seems like people are becoming more technically literate, and they are, but I think when it comes to knowing what you can do, and knowing what you should do, the latter comes well after the forming in almost all exploratory loarning (which internet usage mostly is). We've heard the historical stories (myths), that impart this knowledge. Usually we've lived a few cases of it as well. Even then, it doesn't always take right away, or we get caught out not heeding our own advice. I can't fault a largely novice internet populace for not having had the same conditioning we have.

That doesn't mean they are off the hook though. You're right, there's a shitload of ignoring the signs in favor of convenience and general apathy, it's just not the entire story.

> If anything, history has shown we have to use things like regulations to force market participants to behave more safely on average.

I agree with regulations. I just vastly prefer them to target the specific problems and not try to get too complex with mechanics. Sometimes that requires really looking into the problem, and it can be a hard sell if the general audience for choosing/voting the implementation doesn't have enough knowledge. In this case, I think a lot of the problem all stems from using personal information as currency. Strong regulations on the collection, notification, maintenance, and ability to force removal of personal information by remote entities would make what the real cost is of the systems obvious (you know what they collect and how it's used, or in some cases you know what actual money you pay since that will become a much more viable model again). Open source cometes well in that market, because the actual costs are all apparent instead of hidden.

> We probably need a way to quickly present that when they make these choices.

I have hope this is a problem that will be mostly solved through the normal way societal best practices are passed down, from mentors (parents, teachers, trusted authorities). We just need to get to a point where the mentors actually know this stuff, which requires time and them being bitten by it and learning the hard way, or reading about those stories, or eventually learning it from their mentors. When your Mom or Dad is usually the one that cautions you at an early age to beware any free service that might be trading on your personal info, we've reached a good equilibrium (but we'll still have issues with those that don't have as much access to mentors, which is a constant societal problem).

> most gmail users never see messages from my personal email address, because google routes them to spam despite my IP never having spammed

This is off topic but very briefly: implement SPF and DKIM and get a number of Gmail users (I'm not sure what this number is, but it is order of magnitude 10) to mark your emails as "Not Spam". Eventually Gmail will come to accept emails from your self-hosted server.

“they almost certainly use and appreciate federated systems like phones and email”

Two channels which have become saturated with spam and junk once the federated network starts to include players who are willing to permit bad actors to access the network in exchange for money.

People enjoy federated networks of regulated, good faith players; wide open federated networks tend towards anarchy.

>People enjoy federated networks of regulated, good faith players; wide open federated networks tend towards anarchy.

Like... email and the phone system? both of those have huge amounts of bad actors and spam, and people still use them as primary means of communication. Email and phone are generally expected to be more reliable, I think, than any of the walled garden communication protocols.

(Speaking of, if you have ideas about curbing phone spam other than keeping the number secret, do let me know.)

I'm explicitly questioning "people still use them as primary means of communication"

Really? Even internal company phone systems have largely switched over to walled garden voip or videocalling systems in most places I've seen. Nobody calls anybody any more - the only use of phones I see is for dialling in to conference bridges. Email is used internally within businesses.

What do people really still use public phones and email for?

On a more personal note, I grew up using messenger protocols, icq, aim and yim. Now, I'd use a multi-protocol client, which is a little like federation, but now that doing this is inconvenient? SMS has almost entirely taken over the role of instant messaging in my life.

It's interesting, because I always felt that a SMS was way more 'urgent' than an instant message over AIM, but... most of the adults in my social circle, even those I knew from back when we all used AIM, no longer are on any instant messenger services. They have sms (often, but not always through imessage) and they have email. Then they are on their various social networks, but everyone I know checks email more often than their social network accounts.

>What do people really still use public phones and email for?

My impression is that inter-company communications all go over email and public phone. Intra-company,of course, you use the company's walled garden, if the company is large enough to dream of forcing the world into their garden (as most of the companies I've worked for lately have been.) but even so, interviewing is conducted through public phone systems. In fact, even when I'm interviewing a candidate on behalf of my current employer, half the time the connection between the internal walled garden voice system and POTS is so bad I end up using my personal cellphone. Silicon valley companies are serious about 'dogfooding' to the point where actually doing your job sometimes feels like a secondary concern. Smaller players tend to use existing technologies, and so more often use federated systems.

I have worked at smaller places, earlier in my career; I've even setup VOIP for one of those places, but it was still terminated to a POTS T1; it just used SIP lines and asterisk rather than a wired PBX, and they mostly used public email (I mean, their own email server, but it was federated email) - those are still federated systems.

I'm currently considering going to college; today, I scheduled a bunch of academic stuff, using the phone and email. If I end up locking myself into an institution, of course, then we will probably switch to using their walled garden, because they will have the power to force me to do so, but until that happens? we're communicating via federated systems.

Whenever I'm scheduling a medical appointment outside of my primary hmo? I use the phone.

My impression is that the walled gardens are mostly used in places where the relationship has been established, and one party is big enough to have built a walled garden system, and important enough to force the other party to eat the dogfood in question. Within my primary HMO, I use the proprietary 'secure messaging' application to communicate with my doctor. Within the company, I use the company's messaging system and screen sharing system.

My own conclusion is that forcing you to login and use my communications system is a power move; everyone is still dreaming of replacing email with something more profitable.

At least in my country, incoming call filters do wonders, in particular those which query the incoming number at an online database to show you who's the caller.

Not sure about elsewhere, but in the US, it is possible to spoof phone numbers. The only way to verify that the person you are talking to is actually associated with the number is to hang up and call them back. This is particularly a problem for companies like banks and insurance.

Android actually does provide some amount of filtering[1], but if someone, say, spoofs a seemingly legitimate number, it will come through fine.

[1]: https://www.androidpolice.com/2016/07/25/googles-phone-app-n...

I've seen similar applications for ios, but they all seemed to want permissions I wasn't so happy to give to some rando. If apple provided the service, I'd probably be okay with it, but I'm not super comfortable feeding my entire contact list and all my call metadata to some random third party

Is this something the phone company implements? or that your phone implements?

It does not have to be regulated by any third-party, though. Federated networks participants can regulate networks for themselves. Look at Mastodon network. If some server tolerates spamming, it will be blocked by major servers as a whole.

Parent's downvotes are undeserved as they are spot on.

Users don't want federation in a sense that they don't _care_ if it's federated or not. Not that they actively decide against it.

They only care if they can start chatting with people from their address book right after installing a chat app.

> Users don’t want federation.

I don't care what users want. I want it!

That is the beauty in narcissism: You can use the best technology to chat with yourself. :)

Xmpp was pretty popular. Fb messenger and Google talk never allowed federation, but they did for a while allow access by xmpp clients.

Apparently WhatsApp still use xmpp, but afaik also never supported federation.

Aim didn't allow federation.

So I'm not sure what you're trying to say?

You could claim the rotting corpse of duckduckgo's xmpp service is evidence that users don't want federation - but I thinks more just an example of a mis-managed service.

[ed: the other two obvious examples of users do seem to want federation is the rise of irc despite many architectural flaws, and the continued popularity of email.]

Google Talk absolutely federated: http://googletalk.blogspot.com/2006/01/xmpp-federation.html

Unfortunately they were the only major service provider to do so, and the capability was later discontinued.

[ed: aha! They didn't really support federation in a standards compliant way:

"However, since the Google Talk Service does not support server-to-server encryption via TLS (something that was required by RFC 3920 in 2004), a number of servers (including jabber.org) refuse to establish a connection since May 2014."


I recall there were issues...]

Wait, what? You could chat from you@example.com on your bespoke xmpp server and send messages to user@gmail without needing a Google account and vice-versa?

Was Google talk really so unpopular that I didn't seriously try to use it until it became the walled garden that didn't support server federation?

> Wait, what? You could chat from you@example.com on your bespoke xmpp server and send messages to user@gmail without needing a Google account and vice-versa?

For some glorious years between 2006 and 2013 (Hangouts), this was indeed possible. I run my own XMPP server and I used to chat with GTalk users all the time. For literally years.

> They didn't really support federation in a standards compliant way

It was standards compliant enough. In the original RFC, server-to-server TLS was mandatory to implement but not mandatory to enable/deploy. The XMPP community later moved towards enforced server-to-server encryption, but this was many years later and had little impact on GTalk federation during the time that it was supported.

I remember looking into it, and discovering that it didn't work in a sane way (ie: no server tls support). Why would I want to expose traffic unencrypted? Especially considering dangerous content, like attachments etc.

Now I see that Ms allows federation for on-premise lync - but not for office 365. :-(

Everyone wants their own silo, and force their multitude of awful clients on people.

Actually, it still worked for existing contacts until half a year or so ago, when they seem to have silently dropped it completely (I haven't really investigated, contacts I had on google simply moved to other servers, that fixed that).

User want federation. See the adoption of email.

you mean that means of communication where spam problems effectively forced a centralized infrastructure provided by a few providers and that now is relegated to mostly being used as a poor man's notification service?

running your own smtp server these days is painful.

Not that painful (speaking from experience of running one).

It's somewhat painful, but not because of spam. The pain all comes from jumping through hoops for the centralized providers (and then discovering that no matter how many hoops you jump through, it's never enough).

And see the subsequent flocking to APNS, its child iMessage, Firebase Messaging, and Facebook Messenger.

Email is obsolete.

Why does every product always have to conform to the most general use-case? Who cares what "users" want?

It seems like they have a lot of overlapping goals with Keybase.io.

I wonder if they're in contact or work with each other.

Isn't keybase a for-profit startup leveraging advances in cryptography to build yet another social network?

Keybase is not really a social network. It feels much more like a sort PKI with a Slack client on top of it. The focus seems very much on Teams.

However they could go into more of a social network direction, the features are basically there.

Keybase is an amazing idea which seems to be trapped by the current zeitgeist. It implements smooth and intuitive PKI via a command line, a mobile app and a web/electron app and seem to be rolling it out as a slack and/or dropbox alternative which are pretty solid use cases.

The downsides are that it has a very cartoony 'silicon valley' type feel which is great for early adopters, but will be a significant barrier to enterprise and government customers who would otherwise be an absolute prime market for easy-to-implement, easy-to-administrate PKI.

It also has a very start-up oriented world view in terms of 'teams'. There would be great call for generic group management. I would love to have some stakeholder management across some projects where we could have a shared space, but also have separate areas for client, supplier and subcontractors. Keybase kind of doesn't quite fit the need for privacy there, although it is so close to being exactly what is needed.

Bringing it back round to the social networking thing though - it feels kind of like it was inspired a lot by social networking. This would be a boon if it were to become a social network. It is absolutely a downside if they're looking for a wider remit.

Idk if they realized what they had... They don't even need their own chat client - I implemented an example where I could encrypt and decrypt messages automatically to anyone, over any web based client:


(Current version in repo doesn't automatically encrypt, but tests show it's straight forward).

I think that's the real power, the centralized authority of "you are X, with public key Y"

They came up with a good solution to the 'key signing party' problem.

Using public social media accounts to help prove identity is a good idea - it's a solution to the main problem that PGP had.

I think Facebook could have done something similar by generating key pairs for all users and then allowing third part access to the public keys (basically a huge public key server). For users that wanted their own private key off of Facebook they could upload their own public key. It's probably better with the keybase model though and using multiple social media accounts.

> The downsides are that it has a very cartoony 'silicon valley' type feel which is great for early adopters

I feel like once they want to role it out to companies its frailly easy to change these things.

> There would be great call for generic group management.

They have subgroups, so that's something.

is it for profit?

Nothing is monetized yet as far as I can see. I like Keybase more though, it doesn't force me to have a phone (what the hell, Signal's Linux desktop client requires that at least).

I also like the keybase product. But when I see an ambitious, well-funded startup without a paid product or clear business model... that tells me I cannot yet trust their product, strategy or management team to endure. Next year they might be a completely different company, or might not exist at all. Since they haven't open-sourced their server, that makes it risky to rely on their products, because I don't really know what it is I'm relying on.

Signal in comparison is very clear about their goals, management and business model, and I believe are 100% open-source. That gives me confidence to adopt it now, even though it's a less feature-rich product.

I would love to see Signal adopt the Keybase identity-by-proof model, I think it's very clever and pragmatic.

When you sum it up like that it sounds like a blatant op run by a clandestine agency...

Sigh, trust is hard after the crypto wars.

Not that it matters that much, but where did the 50 mil come from? I didn't see it in the post, but I may have missed it.

From Brian Acton, one of the cofounders of WhatsApp and now Executive Chairman of the Signal Foundation board.

Gotcha, I wasn't too clear on that from the post. Quality philanthropy.

Quality philanthropy in the tradition of Mitch Kapor (EFF).

Morally, how does one weigh the implications of this, in that it will be easier for general citizens to use strong encryption, but also be easier for terrorists/ne'er-do-wells as well?

Simple. There are more "good people" (people who care about others lives', even if only in small ways) in this world, than "bad people" (people who don't care about others' lives). By a large margin.

By that same logic I assume you don't believe in gun bans, right?

They are also dozens of other Actons and companies that can write a $50 mil check if needed. NSA might be in trouble

This is very very good news.

As a heavy Signal user, from where I sit I personally see the following clear needs:

-Better group support. Right now, to do a group in Signal you have to name the group, which makes it kind of a pain to create ad hoc quick groups. I'm forever naming them "John Sue Bill" or "Jane Roger Amanda". iMessage, by contrast, just automatically makes a group without a name. You get a thread for that group, so you can follow the discussion clearly, and you can leave the group, but it hides the nuts and bolts of the fact that a group has been formed. Also, Signal has no per-group notification settings, so if you're in a "noisy" group your only option is to turn off notifications universally (including one-on-one messages and other groups) or live with it. Lastly, you cannot form a group from Signal Desktop.

-Better support for long messages (or a new product using the same network and security). Signal was clearly designed for short session lengths — brief messages that are composed quickly. But as it has become the catch-all app for encrypted comms — "just use Signal! PGP email sucks!" — many people, at least that I deal with, are trying to use it for email-type purposes. Long messages with arbitrary attachments. It would be nice if, like, putting a line break in a long message didn't mean hitting Control-Enter or Command-Enter. It might even be nice if you could have multiple threads with the same recipient. You know, like email. I am not holding my breath on this one. But if people could email as securely as they chat, using Signal protocol, it would be a huge leap forward in keeping the NSA out of our business. Not to mention Google/Gmail's ad clients etc.

-Ability to search. I can't full-text search my messages, even within Signal. As I use it more and more, this is a hindrance.

-Group video chat. This is very pie in the sky. But a lot of sensitive comms involve groups — think of people organizing a protest, or a corporate takeover, etc. And right now there are few private options.

I'd love to use Signal, but in order for me to do so there's a lot that has to be added.

- Real multi device support. I want my messages on all my devices, without having to have my phone on.

- An iPad app.

- A desktop app. I'd pay for a native one, without Electron.

These things are basically table stakes for competing with Facebook Messenger, Telegram, and iMessage. If Signal's goal is to bring encryption to the masses they have to solve things like this, since regular people care less about security and more about convenience.

> - A desktop app. I'd pay for a native one, without Electron.

I'm working on a native app that supports Signal, Slack, Twitter etc. It's only 90 KB (!).


*edit Signal support is coming in early March.

Although you claim Wireshark, etc. can be used to verify the lack of external communication, the fact of the matter is that it only verifies you aren't sending data to third-parties all the time. It does not mean that it won't do so occasionally, or that (say, if triggered via a message in an existing platform) it won't suddenly send your credentials to someone else and then erase its tracks, or do anything more sophisticated than the naive approach you illustrated. The reality is that open-source really is necessary to prove that nothing nefarious is going on, as unfortunate as that is. I hope you can open-source it in the future so that it enjoys full adoption.

It will be open-sourced at some point within the next 2 years without a doubt.

Like I explained in the FAQ, the plans and the potential are huge, and it would be really silly to risk it all just to become another data miner. Even if it's very sophisticated, and there's a 0.01% change it's found out, why risk everything? Besides, it's simply illegal. All the information about me and the company is public.

I wonder if you have the same concerns about other closed source software like Sublime Text.

> I wonder if you have the same concerns about other closed source software like Sublime Text.

This was an unnecessary personal jab, but I'll respond. Sublime? I don't use it. Software that deals with my credentials just like you do? Yeah, I definitely do. That's why I don't trust closed source password managers either. Text editors? Mine are open source so the thought has never crossed my mind. Other random software like my OS or Visual Studio? Depends; e.g. Microsoft is a huge corporation that has nothing to gain and a lot to lose from keylogging my passwords, but e.g. I wouldn't trust Facebook not to record my audio or fish out my contacts behind my back. Smaller utilities? Yeah, but again, they don't have my credentials at their fingertips, or need Internet access at all for that matter (I turn off auto updates so I can just block internet access for them entirely).

All of which is to say, yeah, I'm not picking on you specifically, but this isn't about me, or about you. I'm just a messenger. Verifiability is the requirement many people have for software that manages their credentials; pinkie promised aren't enough. For some of them, you can make up for some of it by having a big enough reputation to lose, and criminal history to jeopardize in their jurisdictions. For others, you can't. In your case, you don't seem to have that going for you either.

This was not meant to be a jab, sorry if it came out that way. English is not my native language.

I was genuinely interested, and I expected this answer. This is a very valid point of view. I hope you'll use it once it's open-sourced.

Thank you so much for this, I can't wait to try out the Linux version. Are you using GTK+ for the UI on Linux? Your website does not specify.

I'm asking because high-dpi support on Linux/Wayland is constantly problematic for desktop applications that don't use GTK+ 3 or Qt.

GTK+ 3, yes.

For #1, Multi device support already exists. I can put my phone on airplane mode and still send and receive messages just fine on my laptop

That's cool. When I tried it last it required my phone to be on just like WhatsApp. I'll check it out again.

I still hope they use some of this cash to make a real iPad and Desktop app, though. I'd really love to use the service but those are deal breakers for me.

Signal Desktop has never worked that way.

After the initial linking process, Signal Desktop has always functioned independently of your phone being on.

I must be misremembering it. I'd edit my comment but it's timed out.

...and my pet peeve (which Signal explicitly denies on iOS and has some convoluted method on Android) — allowing the user to backup data from the app and restoring it on a new or different device! Don't treat chats as disposable.

I've slowly been working on a native version for Windows 10, source available here: https://github.com/signal-csharp/Signal-Windows

Signal has no per-group notification settings

Yes it has, at least on Android. Within a group, press the three-dots-menu on top and choose mute notifications. You can choose for how long they shall be muted, similarly to other apps.

Adding to your list:

- Working backups for text and media.

> - Working backups for text and media.

Yes pretty please! For Android, any kind of media (bulk) backup option would help, for example. (IIRC iOS doesn't even have plain text backup). This is affecting a lot of everyday common users who cannot move to a new phone (or uninstall and then later install again) without losing all the media in the conversations. Saving the media items one by one (and detached from conversation and context) is not the same and sometimes impossible due to the sheer quantities involved. And so on.

I know the resources have been really scarce but since this is hopefully changing now, this would be greatly appreciated. There's been some recent related work[1] required for encrypted backups to work, though. Also see ongoing discussion[2], GH issue thread[3] and possible implementation PR[4] etc., for anyone curious. Alpha testing[5] may help, too. (Me, I'm trying to find time and energy to help with this, but so far have only be able to grovel and complain). :)

[1]: https://github.com/signalapp/Signal-Android/commit/f36b296e2... [2]: https://whispersystems.discoursehosting.net/t/encrypted-back... [3]: https://github.com/signalapp/Signal-Desktop/issues/522 [4]: https://github.com/signalapp/Signal-Android/pull/7380 [5]: https://whispersystems.discoursehosting.net/t/signal-android...

I'm pretty well stuck on my current phone without a working backup for texts and media, unless I'm okay with losing my memories. Essentially, there is no way for you to take any media with you in a reasonable fashion when changing phones with Signal.

Completely agreed on all of these (the lack of search, in particular) is just atrocious. I'd also like to see:

- Improved export functionality on all platforms :: I should be able to export my chats in some readable format from any client.

- More clients :: I should be able to read my Signal messages within emacs.

- Support for non-phone-number identifiers :: I shouldn't need to purchase a new phone number in order to get another Signal account. I completely get how valuable this is in limiting certain forms of abuse, but it also limits certain forms of legitimate use (e.g. Haven).

- Better privacy for contacts :: I shouldn't be sending my contacts to Signal's servers. I don't trust Intel's secure enclave technology any more than I trust Intel's ME. There are ways to discover mutual contacts privately.

> There are ways to discover mutual contacts privately.

Such as? I don't have the URL handy but the Signal team did investigate the literature and known techniques for this a few years ago and found them to be nonviable.

> I don't have the URL handy but the Signal team did investigate the literature and known techniques for this a few years ago and found them to be nonviable.

Private set intersection (in which two Signal users compare contact lists to see which contacts they have in common, then trade Signal information for them) would work just fine.

This is their latest blog post on the topic: https://signal.org/blog/private-contact-discovery/

Absolutely there with you on full text search. The only way is to ... export in plain text my text messages. If only we could export it in a secure manner and have the export also encrypted and be prompted for an encryption password on import. That would be awesome!

I think Group Video would be interesting but I personally don't do video on Signal, nor did I have a hint that it supported this? I thought it was just audio?

Even so it would equally be amazing if they could improve the usage of a Desktop client and / or maybe allow for Tablet support? I don't want to run my texts through Google Chrome, I rather run them through a more stripped down Chrome (Electron, but it shouldn't be too much different!) that wont be randomly phoning home to Google or require me to open up a browser I rarely use outside of work.

I really would love to see Signal work without phone numbers at some point (email as an alternative would open up Signal for Tablets - really wish Signal worked on Tablets) but I may not know enough about the existing structure to know how feasible this is or isn't.

I think you hit the nail on the head about email though. If the Signal Foundation is serious about making encryption accessible by all I think their next big focus should be:

* Making something that allows table usage of encrypted messaging (wondering if they signed something with Facebook and Co that disallows Signal to run elsewhere?) * Make email encryption painless and straight forward, whether they build their own mail client and plugins (please make this AND mandatory no exceptions) or they make plugins for all major mail clients, especially Thunderbird.

> -Better group support.

To go along with that-- Support for exporting group messages. I recently moved to a new phone. With the latest versions of signal on android, I had to export a plain text backup of my messages. The problem? All the group messages were removed from their groups and threaded into the individual conversations with the person who sent it. So not only did it ruin the group message, but it also ruined the individual conversations, too.

I ended up downgrading to an older version of signal, creating an android backup of the data and then copying that to my new phone.

This may sound silly, but:

- Stickers

I know many consider those to be annoying distractions, but in my experience stickers are the reason why many "normal" users prefer Telegram over WhatsApp.

Had them for a while now on Android: attach -> gif -> stickers tab. The browser UX isn't great though.

> Over the lifetime of the project, there have only been an average of 2.3 full-time software developers, and the entire Signal team has never been more than 7 people.

This is awesome. Amazing what an excellent small team can build.

Don't tell SV!

When WhatsApp was acquired by Facebook for $19B they only had a little over 50 people.

is it known how many of those 50 were devs?

"When WhatsApp was acquired by Facebook for $19 billion, the popular messaging app had about 35 engineers and 450 million users." http://www.businessinsider.com/facebook-f8-whatsapp-engineer...

35 still seems high to me

You forgot the /s

Congratulations to moxie and the Signal folks from the Matrix.org team :) The world wouldn't have the increasingly pervasive E2E encryption we enjoy today if not for the double ratchet algorithm, and it's fantastic that they can continue that work as a 501(c)(3)!

>The world wouldn't have the increasingly pervasive E2E encryption we enjoy today if not for the double ratchet algorithm

Too bad the Signal Protocol doesn't actually implement the double ratchet algorithm but a derivative of it that fails to protect metadata making the Signal Protocol leak metadata. Granted, it only leaks metadata leaked by the transport layer anyway, but this makes it pointless to implement the Signal Protocol over something like Tor, i2p or GNUnet.

Moxie is and will continue to go down as a legend of the digital age. He carved his spot way back with work like sslsniff/sslstrip, and has proven himself to be a real philanthropist. Kudos to him.

This is a bit of a tangent, but I first heard of Intel SGX (Secure Guard Extensions) via Signal's blog post about secure contact sharing[0], so it's almost relevant :p From what I've read[1][2][3], Intel SGX is vulnerable to Spectre exploits. Does anyone know if this has changed Signal's approach to security at all? Granted, contact sharing was a technology preview, but I'm curious if SGX is still considered a feasible, "good enough" security measure for Signal Foundation.

[0]: https://signal.org/blog/private-contact-discovery/

[1]: https://software.intel.com/en-us/forums/intel-software-guard...

[2]: https://github.com/lsds/spectre-attack-sgx

[3]: https://security.stackexchange.com/questions/176635/how-does...

Signal's use of SGX was to increase users' trust in Signal - OpenWhisperSystems couldn't log your contacts even if they wanted to. Its up to potential users to decide if they think OpenWhisperSystems will surreptitiously perform an attack on their own secure enclave to secretly log your contact information.

Regarding the SGX enclave and contacting sharing, the blog post announcement dated 26 Sept 2017 says 'deploying into production...over the next few months'. Can we assume that's happened already? Or are contacts still being exchanged in a way that would allow a middle man to reconstruct an individual's social graph?

Given that it now takes an order of magnitude more time than it used to for newly added contacts to appear in my list of Signal contacts, I assume /something/ has changed with the way they exchange contact data.

Since you are in the US how do you keep the US government from interfering with your mission because Signal uses strong encryption?

How do you address the EARs (Export Administration Regulations) and ITARs (International Traffic in Arms Regulations)?

These regulations look like a tar pit to me.

My experience is that government and gov't contractors have been turning their heads. The proliferation of E2E communication has been too fast to analyze and regulate with respect to WWII era regulations, similar to how cryptocurrency is to the financial market.

Interesting to note:

>Publicly available software under the EAR, as under the ITAR, is exempt from export control. However, before strong dual-use encryption code is made publicly available via the internet or otherwise placed electronically in the public domain, exporters must provide the US Government with either a copy of the strong dual-use encryption code or a one-time notification of the internet location (URL) of the code. This must be done before making the software publicly available. Notification after transmission or transfer of the software outside the US is an export control violation


edit: More guidance on what's exempted from EAR is at https://www.bis.doc.gov/index.php/policy-guidance/encryption...

Why do you think strong encryption will have an export problem now when it hasn't for decades? Keep in mind that Signal is already open source and the algorithm is already widely distributed. Any restriction on export at this time would be closing the barn doors after the horses have all escaped.

Quora article on issues in US export of products using strong encryption => https://www.quora.com/What-regulatory-issues-have-to-be-cons...

I hate these regulations but EAR and ITAR with respect to crypto seem to be concerned with the key length and algorithm. Over a certain strength the software using the encryption seems to be still treated as a munition!? I've heard of people who ignore this getting huge fines.

And any export to Cuba, N. Kora, Sudan, Syria, and Iran is banned by OFAC (Office of Foreign Assets Control). Yes, the very countries that need Signal the most are banned!

Hopefully I'm wrong and we are free of regulatory issues in the US so I'm asking a serious question here - how does Signal solve this problem?

I think the US still requires cryptography products to be registered with the Department of Commerce, but that's about it for non-military products.

I've tried reading the regulations (but IANAL) and am almost certain that over a key-length for given algorithms its a munition and an export license or similar is required with regular updates.

And then still there is the issue of the OFAC banned countries list.

I'm hoping Signal's compliance can show other hackers how to also comply without hassle or fear.

I think this is the one: https://www.bis.doc.gov/index.php/documents/regulations-docs...

> You must submit a classification request or self-classification report to BIS for mass market encryption commodities and software eligible for the Cryptography Note employing a key length greater than 64 bits for the symmetric algorithm (or, for commodities and software not implementing any symmetric algorithms, employing a key length greater than 768 bits for asymmetric algorithms or greater than 128 bits for elliptic curve algorithms) in accordance with the requirements of § 740.17(b) of the EAR in order to be released from the “EI” and “NS” controls of ECCN 5A002 or 5D002.

If it's illegal and in a surveillance state, they can selectively prosecute or just coerce people any time they want. I tried to dig into the export regulations one night at this link:


My research suggested they did not change the status of encryption products in general: it was a narrow set of them like mass-market, downloadable stuff that got that designation. They kept high-assurance security, tools for building secure systems, customized secure software, and so on classified as munitions needing a license.

What I can't tell you is anything about that process since I never asked for an export license for any software. Maybe it's easy as some people told me with no restrictions. They weren't doing high-security stuff that irritates surveillance states, though. There could be pressure on big companies or providers of strong stuff. There could be nothing for now but something down the road. It's kind of a black box for me from this vantage point except the parts where it straight-up says specific things have old classification.

I'm really curious what experiences any of you have had that made strong security products on hardened OS's you requested permission to export.

Chrome, Firefox and IE ship with very strong encryption (128 bit AES) just fine for many years now.

That cat is out of the bag.

I read in the CFR (Code of Federal Regulations) somewhere that 128-bit AES is under the threshold so can be self-classified (but IANAL!). Anything stronger and the legal constraints seemed to be more than onerous.

Cat is quantum undetermined in my book - maybe someone from Open Whisper Systems, Signal Foundation, or the Freedom of the Press Foundation will share some wisdom.

Or they secretly allow it because they know something we don't.

They don't need to break encryption.

They can just "ask" any of the softkeyboard makers like Swiftkey, Swipe (Rip), Hacker's Keyboard, Google, Apple, Samsung etc.

The US government doesn't need to break the encryption of the application to monitor it. It can do remote screen grabs.

I hate to be the one naysayer, but it seems to me like the benefits of this influx of funding and scope has very few tangible benefits, while predisposing them to a standard failure mode of large and well-funded tech activist organisations where the means (the organisation) are confused for and eventually put ahead of whatever goal they were founded for: see e.g. Mozilla support for EME, the continuing negative news pertaining to Pocket and trying to collect user data. (On the ground, part of the problem may be something of the form: imagine you are the CEO of $foundation, are employing dozens of people and hundreds of volunteers who you have to keep motivated and now you are supposed to tell them they can't do the one thing that might keep their employer going and relevant just because of some philosophical considerations about how compatible it is with the core mission.)

It's easier to criticize than it is to build.

Mozilla has been doing a lot of awesome stuff and people keep forgetting that their direct competition and threat are Google, Apple and Microsoft, the world's largest tech companies. Mozilla basically had no choice with EME, but to comply.

When the majority of HN's userbase has been using Chrome for years, power users, nay, freaking developers which should know what EME means, when Chrome is approaching the monopoly of IExplorer, good luck selling your values to the general public, who don't give a shit as long as their Netflix stream ain't working.

Open Whisper Systems has been delivering the best encrypted chat protocol to the masses, their tech being used now in WhatsApp for example.

So you can be the naysayer, but IMO these foundations are building and releasing products with a measurable positive impact on the world, whereas most of us here don't ;-)

I understand the case in the case of Mozilla, because a browser is an intrinsically absurdly complex product. In the case of Signal, the benefits of having a foundation like that seem unclear to me. What exactly is it that they want to do but couldn't before they had a $50m foundation? The linked page seems very vague about this.

Any reason Signal isn't available through F-Droid? It may be unjustified but I'm not a big fan of installing privacy conscious apps through Play.

Edit: Wait, haven't installed anything yet, but I read the getting started guide. I have to sign up using a phone number? That throws all expectation of anonymity and thus privacy out the window.

You can get a phone number from https://jmp.chat/ if you like. The signup process can be done entirely over Tor.

If you don't use it beyond the trial, it's like the public payphone option mentioned by another commenter - someone could take your number. But if you choose to get a paid account (which, among other methods, can be acquired using Bitcoin, Bitcoin Cash, or a prepaid gift card purchased with cash), then the number will be yours. JMP is probably the most anonymous way of getting a phone number.

I'm not sure of your assumption that lack of total anonymity implies no privacy. They are independently important concepts. You can have privacy (no knowledge of information shared) without anonymity.

That's true, but I believe the concern would be that there's information just in knowing:

1) what's your number, and 2) with whom you connect or communicate.

That is, there's still the danger of social graph analysis: "Oh look, this person's communicating with a known journalist!"

The phone network can do that just by correlating traffic to devices, it doesn't need any help from the software running on those devices.

If the target use case was people that could reasonably do the job of limiting the information just the use of their devices leaked, it might matter. But the target use case is replacing SMS and the like, so it really doesn't matter (except that people want to pretend that the use case is something other than replacing SMS).


Of course there is. That's why one of the cleverest parts of signal is the engineering to invalidate number 2. Moxie and signal are the world leaders in trying to make it impossible for the service to know who you communicate with... Even to the point of using the Intel secure enclave to audit the server software and validate that it doesn't peek.

That's not the point. Why doesn't Signal provide the option of using a pseudonym? The model is broken from the perspective of people who care about privacy.

F-Droid wants to compile their own binaries, and Signal/OWS/Moxie want to provide checksums and the like for Signal binaries.

That's an argument for reproducible builds; building the same source should give the same checksum.

The funny part is that Signal and F-Droid both have their own reproducible build system, but they’re incompatible (part of that is that Signal requires proprietary code in its binary)

Can you elaborate more on this? What is the proprietary code used by Signal?

They link several proprietary libraries into their APK, including GCM (which has its own internal analytics package)

Theoretically, but when you throw in things like build systems often not being deterministic, minor versions of dependencies changing, different OS or slightly different OS version with different libraries; there's a multitude of places to throw the final binary off by a few bytes or more and end up with a different checksum.

Signal wants to distribute a binary with a checksum. Once the checksum is different all bets are off, that's why it's not in F-Droid

As if reproducible builds hadn't been done before. If Debian can get to building 80% of their packages reproducibly[1], the communities around Android can get there too. Luckily, it's being worked on.[2]

Now the question is: (when) will this be supported by F-Droid?

[1] Scroll down for a big graph https://wiki.debian.org/ReproducibleBuilds

[2] https://github.com/signalapp/Signal-Android/wiki/Reproducibl...

F-Droid has supported reproducible builds for years: https://f-droid.org/en/docs/Reproducible_Builds/

The real question is, when will Signal finally support it?

Nice, thanks for pointing that out!

So why don't they just also list checksum of the F-Droid binary?

They don't trust F-Droid.

Yeah, figured. They seem very inconsistent in applying their trust. At times they'll do strange things like build app on Chrome Apps platform / mandatory phone ID and on other times they'll make user-hostile decisions like hijacking SMS messages and refusing to publish to F-Droid due to "security".

The end result is an app that keeps shooting itself in the foot and being beaten by Messenger and WhatsApp.

The reasons why have been given by others, but you might also like to know that you can download the APK yourself and that it includes its own updater: https://signal.org/android/apk/

The phone number is the contact discovery mechanism on Signal. If you don’t want that, you don’t want Signal.

Me and the persons I want to communicate with are perfectly capable of finding eachother through other means - ids, qr codes, ...

At the same time, maybe I don't want everybody who has my phone number to see that I am on Signal.

You can signup using the number of a public payphone if it makes you feel safer, with landline verification. (Of course, you expose yourself to having the account hijacked by anyone who figures it out and has acces to the payphone).

But it won't improve your anonymity significantly, unless you also use it over TOR.

> I have to sign up using a phone number?

Use a voip phone number if you want, you only need it to get started.

Search for Noise. I believe Copperhead OS is working on a fork that's compatible, but doesn't rely on Google Play Services.

The swiss messenger Threema can be used fully pseudonymously, but is paid (Bitcoin available) and not open source: https://threema.ch/en

Telegram is available on F-Droid. It's similar to Signal with more functionality and greater ease of use - https://f-droid.org/packages/org.telegram.messenger/

You need a phone number that can receive texts for the initial setup, but once you're set up people can add you by @username and never need your number. Stuff like https://www.textnow.com/downloads works just fine for the initial text. Once you have a single device set up, it messages your existing devices rather than sending SMS when you try to connect another device.

One of the main people behind Signal actually tried to spread a bunch of FUD about Telegram years ago, saying the crypto was weak, but it's really not. No working POC code was provided to decrypt anything, just FUD.

Protocol details here: https://core.telegram.org/mtproto They just released MTProto2 in the last year.

Telegram isn't remotely similar to Signal. Telegram communications aren't encrypted by default, and Telegram group chat messages aren't encrypted at all.

This is 100% false. EVERYTHING that goes over the wire is encrypted, always, just like when you're on a TLS website such as your bank.

Group chats aren't end-to-end encrypted, and 1 on 1 chats are only end-to-end encrypted if you make it a Secret Chat.

Did you really think they were talking about SSL in this context? Of course they meant E2E.

To say there's no encryption AT ALL when it's fully encrypted over the wire is still false. Not having E2E encryption is different than not having encryption AT ALL.

They are encrypted in the same sense that the Sesame Street website is encrypted.

So, it's similar to Facebook Messenger rather than to Signal?

(Actually I think Messenger might support E2EE group chats, but I'm not sure.)

All crypto is weak until proven otherwise. Telegram never received a good review from cryptographers. The fact that no POC was provided may just as well mean no cryptographer cares enough to find a bug.

No, he said the crypto was weird (which it is. Who the eff uses IGE mode?) and that their competition to find vulnerabilities was bullshit and would be secure even using crypto primitives that are known to be weak.

Could this mean that Flock will be making a return?


As a complete layman, I don't understand why this is different than WhatsApp (they claim to fully encrypt stuff, right? Is it worse than this?). If I don't understand encryption and computers, why should I be sold on this? It seems to be aimed towards CS majors who understand the backend benefits. To an end user, it looks like an ordinary chat app. Am I wrong? This seems to have been heavily upvoted; is there a 10x improvement I'm missing?

While whatsapp messages are, apparently, e2e encrypted - your phonebook and metadata are slurped up by facebook.

Signal does not have that goal and have been shown by courts documents to not store the metadata.

The Signal app asks for a ton of permissions. Apparently this isn't decentralized either, so how is it different than Facebook? Did they prove it was mathematically hard/impossible for them to see any of the (meta)data? Have they proven that they are a 100% oblivious broker?

The courts not getting any data, as parent just mentioned, is very strong proof for that.

> The courts not getting any data

I don't know what that means.

WhatsApp uses the Signal Protocol, so its encryption is the same as this. The Foundation will continue to advance the Signal Protocol, and presumably WhatsApp can benefit from any improvements.

Pretty amazing and absolutely deserved. After the failures of systems like PGP, which aren't really suitable for the masses, the Signal protocol did a great job at spreading end-to-end encryption. I'm happy to hear that they got some philanthropic funding, even though I don't doubt that Moxie and the others did the work out of principle anyway and might have continued to do so even without the money.

IMO, saying PGP has failed is like saying cryptocurrencies have failed.

Considering the diversity of opinions on cryptocurrencies, this post leaves me with no idea what you think about PGP.

The verdict is still out on both, because, as a society, we aren't ready to make use of them/the UX haven't been made easy enough for the unwashed masses yet.

There is no public interest in PGP from non-technicals

And the only reason Bitcoin is interesting is because "we" have effectively communicated, correctly or otherwise, that there's value in cryptocurrencies.

The overwhelming majority of people use Bitcoin and other cryptocurrencies through exchanges, they have no interest or knowledge of technical details. So it's not like technical communication has won here, more like greed and ease of use.

I agree with this completely! Bitcoin evangelist Trace Mayer always harps on keeping your private keys and not using exchanges to hold large amounts of coins. And Mayer's an investor in Kraken, one of the big exchanges. I have taught my friends this and they all had interest in it, but some skeptical if they trusted in themself enough to hold onto their coins offline.

Like probably everyone else, I have an idea on how to use the money: Distributed, persistent, group-possible, configurable chat. What's the difference between person-to-person chat, group chat, twitter, reddit, HN, a discourse forum, etc? Configuration, if you ask me. But distributed is the key though I understand identity, disk, and peer management are difficult.

I'm really excited about the possibility of a better client. I want to switch to Signal with my friends but the clients feel so behind Facebook Messenger

I've assimilated most friends and all family very easily by educating them about the why. Not to mention if you're a parent explicitly banning sharing of photos with relatives via social media. People accept any small inconvenience or lack of feature quickly. But at this point I'm not following on the "so behind" comment. Care to elaborate?

On top of the myriad of missing features that for example Telegram has, the UI/UX for Signal (at least on the iOS app) is far behind. The app feels laggy and slow in comparison to Telegram or Messages (only other apps I use). It has giant text bubbles with large padding which IMO looks terribly ugly. Also, Telegram now has dark mode which I find very useful. And as mentioned, as silly as gif support is, it's a nice feature to have. If only Telegram used Signal's encryption by default.

On Android... Slow and laggy: not in the least, maybe this is IOS specific. Giant text bubbles: again on Android this is not a problem. Dark mode: Signal has had this for well over a year at this point. GIF support on Android has been there for almost a year as well.

The downside to Telegram? I don't trust it - so even if any of the above we're true they're all subjective and in my mind not worth compromise.

It's small things like gif/emoji support, @-ing people with their nickname/username sends them a dedicated notification on facebook messenger.

As much as I hate fb, messenger is a pretty decent application.

Signal has both gif and emoji support.

Does it? That's good, I haven't used it recently and it used to be pretty basic.

Their Android app at least is way too difficult to use.

I tried it with my friend some time ago and we just couldn't figure out in a reasonable amount of time how to add each other etc.

I consider both of us tech savvy and we have absolutely no trouble with other IM clients or more archaic stuff like IRC.

Difficult to use? I'm even more confused as there is literally nothing to do to "add" someone.

As I stated our entire family uses Signal across Android, IOS and desktop. That age range in our entire family group is 20s to 70s and I happen to be the only user who would be considered tech savvy.


We didn't have each others phone numbers in our contacts.

Manually adding by phone number didn't work.

At this point we just gave up.

I use prepaids because I travel a lot so my mobile numbers are just throwaways.

I'd rather not give _all_ of my contacts to an app anyway.

So there really should be a way to manage contacts inside the Signal client and add people via screen names or email addresses.

Contact permission is only required to associate a name with a number. All you would need to do is type in a phone number and Signal would have worked.

I agree that it would be nice to have another root artifact for using signal (screen name, email, etc). The one frustrating piece about Signal is not being able to use it across mobile devices.

However it needs to be considered Signal was originally securing texts via TextSecure. It didn't, fundamentally, come up as a Slack or Telegram competitor. So that design decision may make it feel "behind" in comparison. However, I'll again state that I don't trust the others. There's no way you could force me to use FB Messenger or Google (product here). Most complaints here are fundamentally still UI/UX, not privacy. And useable privacy was the original intent. Signal has that in spades.

Thank you for the explanation.

I'm curious though; what happens if someone takes over your phone number? Eg. If the operator re-assigns a prepaid number?

That an account is linked to the phone number is the major problem for me because once you are in another country where you can't receive SMS with that number, you need to create a new account! Matrix is more friendly in this regard, but not as good as Signal in terms of privacy features.

Maybe they can use their $50,000,000 to make it possible to sign up for their service without a phone number.

The hype around Signal is insane to me considering this lack of basic functionality.

Also considering questions like "why does this app want all my contacts?" or "how do I know I can trust the implementation? or, critically, "how much does it even matter when the OS itself might be compromised?"


Huge congratulations to Moxie and the team. Signal is a wonderful project and I'm super excited to see what they achieve with such serious resources behind them :)

What is Signal Foundation's vision for interoperable, open-standard E2E messaging between different central services?

A null vision. Moxie is against federation, and he's against interoperable clients.



I don't think he's against federation, it just doesn't make sense to federate an experiment. Once you've got something really really really solid, then it does make sense.

They've been able to iterate their protocol really fast thanks to it not being an RFC or something.

Fully agree and I want to elaborate. After SHA-1 broke, IETF's OpenPGP work group have failed the community by wrestling hand over what hash function should be in 5th revision of fingerprint protocol. When they couldn't reach an agreement, the development of the next standard was abandoned, leaving all users vulnerable with no date for fix.

And FFS, it hasn't even got anything to do with protocol, it's something the client can do by itself. Having worked on secure messaging apps, I would never go to federated protocols. Signal's infrastructure allows rapid improvement of protocol and fast elimination of insecure protocol revisions. That's where we need to be at. Just look at the history of TLS and the potential in downgrade attacks. Old revisions die slowly. Signal can easily monitor what versions are still running, push updates to users and ensure codebase isn't bloated by code that merely represents insecure protocols.

Signal succeeds because of it's "closed" ecosystem, it doesn't suffer from the tyranny of the majority that occurs when there's disagreement about e.g. seriousness of some attack, when some feature might be risky. With Matrix, I worry developers of clients can affect choices, and the protocol is already dangerous, to ensure (backwards) compatibility with older clients and (other) protocols, Matrix is not end-to-end encrypted by default. I will eat my hat with mustard the day I see all Matrix clients support only end-to-end encryption for everything.

If you're suggesting that Signal will eventually federate, there's nothing in those two links to support that interpretation. In fact, to the contrary:

> Early on, I thought we’d federate Signal once its velocity had subsided. Now I realize that things will probably never slow down, and if anything the velocity of the entire landscape seems to be steadily increasing.

> You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run. If you think running servers is difficult and expensive (you're right), ask yourself why you feel entitled for us to run them for your product.

The axolotl ratchet has been used in at least two different federated protocols that I am aware of. There is no plan to federate signal itself, but he not only allows, but seems to encourage the protocol's use elsewhere.

I really, really wish that he'd reconsider. Interoperability is a huge Good Deal.

Signal now has the resources to compete with the IETF effort by Mozilla, Google, Cisco, Facebook, Wire, Twitter, MIT and INRIA: https://news.ycombinator.com/item?id=16325803

Hopefully they fix the huge privacy problem that requires people to give out their phone number in order to exchange messages. It still amazes me that they don’t see why vulnerable people, or even most women, are not ok with doing this. Even Apple lets you use an email address.

I'm hoping they can use some of this cash to make a better desktop client:

1. That can be minimized to the system tray.

2. That can be used when behind an http proxy server.

3. Doesn't require a phone to use.

4. Doesn't take 200MB ram to run.

You seem pretty passionate - wanna help us test proxy and system tray support?

Tray support behind command-line argument: https://github.com/signalapp/Signal-Desktop/pull/1676

Proxy support behind command-line argument: https://github.com/signalapp/Signal-Desktop/pull/1878

So, what are you using the 15,800 MB of RAM for?

Running Slack. Gosh

Running 4 instances of IDEA, 2 Android emulators, gradle to build an app, and a browser?

100 tabs on Chrome?

Without tree style tab?

I hope they rebadge an android phone the way Fairphone has.

Signal would only need to make a small profit to keep it sustainable and that would bring down the handset retail cost pretty significantly. It would be like the Raspberry PI of phones.

Signal guys: if you are toying with this idea, hit me up (email in profile), I've put way too much time into researching how to do this as quickly and miserly as possible.

Anytime I hear about signal, I try to sign up and my verification code never comes.

It may be something this simple that is holding it back from adoption.

I had a similar issue a long time ago. I was able to circumvent the roadblock by signing up on a different device, and then signing in on the original device.

I and a friend signed up for signal a few days ago. I received verification code after few minutes, he received it on next day. Smells like underpowered server to me.

Moxie seems to be the right person in the right position. I’m excited and happy for him.


Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact