Signal adds a payments feature with a privacy-focused cryptocurrency

With Signal not releasing their server code and now this, I regret using and asking a good chunk of my base to move to Signal.

I haven't made up my mind regarding the payments feature yet but yeah, what's up with the server code? Why hasn't it been updated in over a year?[0]

Also, why do the Signal developers trust SGX so much and have stayed completely silent about SGX vulnerabilities – even when the cryptographers whose quotes they used to put on the signal.org home page[1] are increasingly critical?[2]

Finally, why is there no open communication about major events like the Signal PIN UI fuckup last year or the server issues earlier this year? Foundation or not, if no communication is happening and they're not demonstrating that they're capable of openly admitting mistakes and learning, they're not gaining the trust of anyone.

Don't get me wrong, I've been a die-hard fan of Signal since the early TextSecure days and have convinced > 100 people to switch but I'm starting to have a bad aftertaste and some of my friends (equally big Signal fans) are, too.

EDIT: Looks like the Signal server repo[3] was updated today, as this article[4] (in German) attests to. I had last checked the repo this past weekend. I suppose the repo hadn't been updated to keep the MobileCoin thing secret but I do wonder: Why not simply create a private branch instead of risking one's reputation for openness?

[0]: http://web.archive.org/web/20210311053716/https://github.com...

[1]: http://web.archive.org/web/20200201112751/https://signal.org...

[2]: https://blog.cryptographyengineering.com/2020/07/10/a-few-th...

[3]: https://github.com/signalapp/Signal-Server

[4]: https://www.golem.de/news/crypto-messenger-signal-server-nic...

This is not entirely true. There has been a delay (11 month) in the sync of the server code with a public GitHub repo. Currently all commits are there: https://github.com/signalapp/Signal-Server/commits/master

My thoughts exactly. This makes a very bad impression.

That's how I felt the moment they insisted on storing user's personal data (contacts, name, photo, phone number) in the cloud with no way to opt out of the data collection while also being very vague and elusive about it all in their communications. I'm feeling more and more justified in moving off Signal as time goes on. Jami had better stay good.

> why do the Signal developers trust SGX so much and have stayed completely silent about SGX vulnerabilities

Maybe because the marketing of their sketchy token scheme depends exclusively on the illusion of SGX security.

> There has been a delay (11 month) in the sync

That is quite an understatement. This is like Facebook saying "we will protect your privacy, but there is a slight delay".

I didn't understand the hysteria about Whatsapp to begin with. Yes, Facebook doesn't exactly have great brand recognition but by all indications the TOC change didn't even actually change anything for individual end users but people kept bugging me about switching to Signal.

Compared to the ICO crypto shenanigans of Telegram and now this I don't see a reason to switch. People also kept trying to get me to use Brave instead of Chrome, and the first time I opened it there was crypto advertisement everywhere.

Same. It's extremely concerning. Where's the transparency? If the backend has been compromised and turned into a honeypot, how would we know?

That would only compromise metadata as signal is e2e encrypted and the client has always been opensource and up to date.

All the SGX stuff is about making metadata more private for features that absolutely must be done serverside. So a compromise in SGX is more an issue if Signal itself becomes adversarial or gets compromised. Most services only rely on this for security and don't use things like SGX to hide things from themselves.

I regret finding out Signal uses recaptcha in its welcome screen, and sets the Google PREF cookie permanently in the App's Cache.

Traceable by Google every time you open the App... and using Google's Backup service to store the private keys unencrypted. Well, so much for E2EE.

This combined with what went on with LibreSignal and legal threats from moxie made me realize it's just a company selling privacy claims without proof.

(if you don't think this is true, use AppWarden or decompile the APK. Play Services, Firebase and Recaptcha are still integrated years after LibreSignal was forked.)

And to wit, the sync only occurred once major tech media outlets started to notice. Thus the sync happened to throw them off the scent. Pay no attention to the man behind the curtain, if you will.

You're making very strong claims here. Signal regularly goes the extra mile to protect their users from 3rd-party tracking (by Giphy[0, 1] etc.) and, as they noted on GitHub at some point, they also consciously decided against UI/UX tracking and error reporting because they did not want to give off the impression that they themselves are surveilling their users. And now you're telling us that they deliberately included tracking by Google? That doesn't seem likely.

> Google PREF cookie

The PREF cookie is for Google's safe browsing feature. How on Earth would that find its way into Signal? (I doubt the link preview feature uses that, given how much effort they put into making sure they get it right[2].)

> Traceable by Google every time you open the App...

How so? AFAIK the Signal app doesn't connect to the Google servers directly (reCAPTCHA aside – I have yet to see it in Signal but even then it would be a one-time thing), so even if the cookie existed, it wouldn't get transferred anywhere. The Firebase Cloud Messaging library / Google Play Services on your phone do connect to Google but they carry unique identifiers, anyway (or otherwise push notifications would not work). If you don't want that, use a phone without all the Google stuff – Signal works fine without it (though it might need more battery).

> and using Google's Backup service to store the private keys unencrypted

Could you provide a source that's more accurate than "decompile the APK" or "read the source code"? AFAIR the app's database is encrypted at rest by a key in the phone's hardware key store precisely because the Signal developers did not want Google Backup to get access to the app's data. (Which is why they ended up rolling their own backup solution.)

> This combined with what went on with LibreSignal and legal threats from moxie made me realize it's just a company selling privacy claims without proof.

What legal threats? (I'm familiar with the discussion but I have yet to see Moxie threatening anyone.)

[0]: https://signal.org/blog/giphy-experiment/

[1]: https://signal.org/blog/signal-and-giphy-update/

[2]: https://signal.org/blog/i-link-therefore-i-am/

> AFAIK the Signal app doesn't connect to the Google servers directly, so even if it exists, the cookie doesn't get transferred anywhere. The Firebase Cloud Messaging library / Google Play Services on your phone do connect to Google but they carry unique identifiers, anyway.

It does connect to google's servers for pretty much everything [1] - you can look for these constants in the codebase and you'll find lots of things that would worry any netsec person, including the key backup related stuff.

Signal doesn't only use firebase for the sake of Push Notifications. Also have in mind that push notifications/firebase is unnecessary with a high priority notification, which is what e.g. other f-droid FOSS forks of other apps use instead.

> What legal threats? (I'm familiar with the discussion but I have yet to see Moxie threatening anyone.)

Granted, most of the discussions in LibreSignal's repo [2] got very heated very quickly. Can't find the twitter thread of @moxie at the time, and lots of replies in there got deleted from both sides. Maybe someone else can provide an archived version or screenshot? [3]

> Could you provide a source that's more accurate (...)?

Make an Access Point, use smartphone to connect to it. Run Wireshark, and you'll see what's happening. Use an AOSP ROM and use the Signal Download without Google Play Services (to be sure that it's not Google Play noise you're observing) [4].

[1] https://github.com/signalapp/Signal-Android/blob/d74e9f74103...

[2] https://github.com/LibreSignal/LibreSignal/issues/37

[3] https://twitter.com/comzeradd/status/733677192870297600

[4] https://signal.org/android/apk/

Thanks for the response! I will have to postpone a detailed response to later. In the meantime:

> Make an Access Point, use smartphone to connect to it. Run Wireshark, and you'll see what's happening.

That won't help when it comes to how stuff is encrypted locally, i.e. the hardware-backed encryption[0].

PS: I think I updated my comment while you were already responding.

[0]: https://blog.elcomsoft.com/2019/08/how-to-extract-and-decryp...

the usage of SGX here is to protect against a fairly benign adversary: Signal themselves. The alternative to using SGX in these situations is to hand over the data in the clear to Signal servers.

> Granted, most of the discussions in LibreSignal's repo [2] got very heated very quickly. Can't find the twitter thread of @moxie at the time, and lots of replies in there got deleted from both sides. Maybe someone else can provide an archived version or screenshot? [3]

I remember reading all those threads (the one on GitHub and those on Twitter) back in the day and, honestly, I didn't come away impressed by the way some people treated Moxie. I've been in his shoes a few times now (trying to build a product that works – technically and economically – with team of anarchistic techies) and can empathize with the path he's taken. Not understanding his POV is no excuse for being rude, though. Now, since you posted the link, I went through that GitHub thread again and my impression has stayed the same. A few quotes:

> Wow, moxie0 just sounds sounds like a giant cunt. Anyone who uses a binary compiled release of Signal from the Google Play Store for security is a fucking idiot. (https://github.com/LibreSignal/LibreSignal/issues/37#issueco...)

> FUCK YOU OWS!!! (https://github.com/LibreSignal/LibreSignal/issues/37#issueco...)

> I must say, you [moxie] really are the worst anarchist I've ever encountered in my life; but I'm no authority on the matter. Writing good software doesn't give you a license to bully other projects around unless they give you a WhatsApp-level payout. How about you keep your narcissism tucked in so that secure messaging in general doesn't have to suffer from it? (https://github.com/LibreSignal/LibreSignal/issues/37#issueco...)

> That post [by moxie] is pure politics. It's a bunch of feel-good phrasing, cringe-worthy in its superficial slickness, that obfuscates what is really a giant policy-level middle finger from in terms of Open Whisper Systems shifting away from free software and into a centralized, All Rights Reserved commercial outfit. (https://github.com/LibreSignal/LibreSignal/issues/37#issueco...)

Here's what the people in the thread had to say who didn't get all personal:

> [Directed to someone else on the thread:] Whatever your take on what "the right thing" is, there is no need to get personal. And as previously said, Signal is free software - that entitles you to the source code, and no more. Noone is in the right to demand that OWS do anything else, and that includes most of what is being said in this thread. (https://github.com/LibreSignal/LibreSignal/issues/37#issueco...)

> I thank @moxie0 for replying when asked by @mimi89999, providing his (OWS) point of view in a polite and useful way, bringing up some truly interesting aspects of the issue. I can understand @cjeanneret's frustration, feeling just one step away from a truly free and secure messaging system, but this is no excuse for being rude. (https://github.com/LibreSignal/LibreSignal/issues/37#issueco...)

> It does connect to google's servers for pretty much everything [1]

Have you actually looked at that code? It's for domain fronting[0], so nothing shady, and it's only used when you're in Egypt, UAE, Oman, Qatar, or Iran. Have a look at

https://github.com/signalapp/Signal-Android/blob/d74e9f74103...

vs

https://github.com/signalapp/Signal-Android/blob/d74e9f74103...

and, finally,

https://github.com/signalapp/Signal-Android/blob/d74e9f74103...

> you can look for these constants in the codebase and you'll find lots of things that would worry any netsec person, including the key backup related stuff

I just ran a recursive grep on the entire repository and the file you referred to is effectively the only place where a google.com URL shows up in the code (apart from two or three more instances which are not suspicious, either).

Maybe I'm missing something, so feel free to prove me wrong, but right now my impression is that you're spreading FUD for no good reason.

[0]: https://signal.org/blog/looking-back-on-the-front/

> Signal doesn't only use firebase for the sake of Push Notifications

For what else does it use Firebase?

> Also have in mind that push notifications/firebase is unnecessary with a high priority notification, which is what e.g. other f-droid FOSS forks of other apps use instead.

That's news to me. OTOH I'm not familiar with the term "high-priority notification" outside the FCM realm. Unfortunately, a quick Google search only yielded results related to FCM. Could you explain what you mean?

> a fairly benign adversary

Given the Snowden leaks and everyone's experience with what Facebook etc. do with our data, I wouldn't call that a "benign" adversary at all. Besides, even if Signal itself is benign, someone who manages to hack the Signal infrastructure might not be.

> The alternative to using SGX in these situations is to hand over the data in the clear to Signal servers.

This is not correct. The alternative would be to tell users to choose a passphrase with enough entropy. In that case, SGX wouldn't be necessary. Unfortunately, they didn't do that, so now a lot of users have chosen a short PIN and their data will be compromised should SGX ever fail to live up to its promises. (This is what I meant by "Signal PIN UI fuckup" – the word "PIN" alone suggests choosing a short number over a long passphrase.)

Sorry, the use case I had in mind was contact discovery. Existing cryptographic protocols for private contact discovery do not scale to Signal’s numbers.