It's an open source client[0]. It's not a "pinky promise".

There are valid criticisms of Signal (primarily around the use of the Google Play Services Framework), but your comment seems to be jumping to a lot of conclusions without any research.

https://github.com/whispersystems

But, they still expect me to trust the signed binary they send through the App store right? How is that anyway non-proprietary just because there is a Git repo somewhere that may or may not be the same code running on your phone? Can I run a client from the Git repo and still use all of their infrastructure?

Until I'm able to do that, it is still their "pinky promise".

> Can I run a client from the Git repo and still use all of their infrastructure?

Yes. You can.

They describe how in the very repo I linked. Your ardent unwillingness to spend the 30-45 seconds it would take to find this out before spouting unwarranted false criticism is quite strange. Do you have some personal issue with OWS?

I really didn't mean to be defending OWS here - I'd much rather see Signal leveraging non-Google APIs in some way and provided via F-Droid (though I have read their arguments against that w.r.t. performance) but I'm astounded at the wilful ignorance here.

If you're genuinely interested in promoting secure messaging, a desire to get your facts straight and answer your own questions instead of assuming the negative should be step 1. Otherwise, you're needlessly steering people away from a tool that could practically improve their privacy.

>> Can I run a client from the Git repo and still use all of their infrastructure?

> Yes. You can.

The thing is, lucideer, the "restrictions" on the use of the source code are engineered to raise the barrier to independent use, notably by preventing or discouraging redistribution. This means that only those who are able and willing to compile Android source can run their own binaries. Everyone else has to go with the binaries they distribute which, as the other poster has correctly argued, cannot be independently verified.

> Do you have some personal issue with OWS?

I do not know about him. But I do. Please read on.

> and provided via F-Droid (though I have read their arguments against that w.r.t. performance)

Oh, so it's "performance" this time? It's not something about "updates" like last time¹, or "features", or "metrics"?

Do you really not think, if you go through the discussions, that there's just too many excuses? Does it make sense to you? Do you not get the feeling someone's got something to hide, if you would pardon the pun? :-)

But I tell you what really got in my tits, it was this message: (https://github.com/WhisperSystems/Signal-Android/issues/53#i...)

"Please do not install software from F-Droid. It is an unverified build, exceptionally out of date, and should be considered malware."

You know what? I fucking trust F-Droid. And I for one I am very grateful to everyone who collaborate to make that happen and stand firm in their commitment to open source, and especially to Ciaran, the founder, who gives so much to the community in spite of very challenging family issues (which are publicly known). Top bloke he is.

And then you get some lying, incompetent, manipulative², and possibly delusional individual accuse them of distributing malware. That is seriously not cool.

For those of you unaware, this is the person we are talking about (I suggest you read the comments too): http://www.gandibar.net/post/2010/04/07/The-googlesharingnet...

¹ Cooperative and competent (or at least willing) open source developers can set it up so that F-Droid auto-builds every time you tag a new release. ² And I say this because I'm sure someone will correctly argue that he did not call F-Droid itself malware--that would be too crass even for this guy. He's very careful in choosing his words.

I would love to see Signal provided on F-Droid, as I mentioned above, but I would temper my criticism quite a lot more than yours, for a number of reasons:

1. I haven't read/heard excuses based on updates/features/metrics/&c. as you mention, but their one performance excuse sounds reasonably plausible. Moxie has commented that he'd welcome a PR[0] even if it had bad performance (provided it only ran conditionally of course).

2. The tone in your Github link is a bit heavy-handed, and calling it malware is going too far, but I can understand the developer of software for which security is extremely critical advising strongly against using an outdated version that's being built and distributed by someone else. There is definitely no implication in that comment that F-Droid is malware, he's only referring to TextSecure.

3. I understand your Github link was just to provide an indication of Moxie's tone, but it is very old and the actual factual details in there are probably not very relevant today.

4. I trust the F-Droid software itself, but not necessarily the repository. The distribution of the outdated TextSecure above is as good an example as any - the idea of a 3rd-party building TextSecure and providing it through F-Droid may be all well and good in the spirit of Free Software, but it doesn't really instill trust when the actual author of the software isn't involved at all.

Finally, I'd never heard of the Gandi issues with Moxie's cert before reading that article. After reading it, I'm much more inclined to be suspicious of Gandi than of Moxie. The article is littered with red flags - that fact that their initial response seems to be to go after their customer rather than to question their business relationship with Comodo being a big one.

[0] https://news.ycombinator.com/item?id=12883410

> Everyone else has to go with the binaries they distribute which, as the other poster has correctly argued, cannot be independently verified.

Do you have reverse engineering experience on Android?

APK uses the zip format. Extract its contents and compare those, minus the META-INF directory, which contains digests and a detached PKCS#7 signature.

Apps whose code output isn't reproducible can still be compared with a varying amount of IDA analysis.

Re-reading this post, I'm not sure why I typed IDA -- I meant baksmali. IDA is still useful for bundled ELF dependencies.

Thanks for that link. I'll go through the build process and play with the apk.

But even if I wanted to build my own apk, and run it on my custom Android build, it would'nt work right? Because of the need for Google Play store?

Verifiable builds are atleast a step in the right direction.

Why do you need the play store? You can install apk files without it just fine, if you have the appropriate dev options enabled in your phone.

Signal requires the Google Play Services to work, and includes several proprietary libraries from Google in their app, too.

And so? You're still trusting them and the various libs they're using to protect you... Did you read the code? Did you understand it?

Me neither. How can a bit of software like this obtain any kind of reputation whereas we barely trust openssl anymore is fucking beyond my understanding.........

This criticism applies equally to every piece of software you haven't written yourself. You have to trust someone at some point. OWS has demonstrated that they are more trustworthy than their competitors.

Sure, but the ease of someone abusing this is far greater than what we've been using before.

Can you honestly say that you trust signal over locally or even airgapped pgp'd text?

Nope! But they solve two completely different problems. And the metadata with Signal is actually much better than PGP+email. Have you looked at email headers recently?

You could just look into their APK.

Survey says: NOPE.

Realistically, the code in that repo probably isn't even everything that would run on your device even provided you built it yourself.

Bets on some 'fetch js from somewhere' code in there which could completely unfuck the whole thing which acts as a help screen or something that would be very hard to find...

There is literally no way this sort of thing can ever be trusted. Christ, we barely trust PGP anymore...

All well and good for us, but we're probably not the target here anyway.

And be honest, did you really bother to do all that?

The hole point about this sort of things is you can detect mass attack. If only one person finds a problem all get the benefits.

Its much harder to make a targeted attack, specially if you are not google or have the full support of google.

Nothing is perfect, but there is very little that is better.

Your other options are only not using the devices at all.

I think as long as they are GPL, you can use the infrastructure.

https://github.com/WhisperSystems/Signal-Android/issues/282

You can, but moxie will throw a temper tantrum about it.

https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

You call that a temper tantrum? I thought he was being very reasonable.

We'll agree to disagree.

If he said "Please don't use our servers with your custom client, shit might break. You could run your own infra and keep it up to date with us and we'll federate", this would be reasonable.

Instead, if you read that thread a bit more he throws up his hands and says federation is a thing of the past because he had a bad experience with CM. Yeah, because we don't still use federated standards like email and telephony every day. Come on.

https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

Yes, and because it's a federated protocol, it still sends every damn thing in cleartext by default.

Federation does not require things to be transmitted in cleartext by default. Don't know where you're pulling that from.

Federated standards have problems with spam and rolling out encryption-by-default. This applies to both examples you mentioned.

Just read the thread, I am mostly on your side, I understand his point but it is weird you license your code GPL and then try to prevent derivative software to work.

This feels a bit like "bad intention". Alternatively you can choose less liberal license, and then make your derivative product from that (Chromium -> Chrome)

But.. But!

Everyone in the geek press said it's "end to end" encrypted! That must mean it's totally safe! I'm sure everyone is reading the source code and building their own clients all the time, yea? Didn't some uber hacker somewhere with a big beard say that he read all the code and it's totally fucking solid and government proof?

Surely you don't mistrust all that do you... I mean... Your seem a bit dubious. You can't be trying to say that there are people out there who are actually not buying this horseshit, that are genuinely withholding trust in these sort of 'services'?

Blasphemy! You think that there are people out there, with a basic grasp of security and cynicism, might feel offended and depressed at how easy it's been to dupe everyone like this.. Again?

Nah. I'm sure we're all totally sold on signal. Seems legit.

I mean, since all the users of such a service have pretty much zero control/visability over the code that's actually running even on their own devices which is talking to this 'service', let alone what's going on on the servers (in some N.American datacentre, probably super secure...) might raise a few eyebrows, but it doesn't really change the fact that we're talking abiut END TO END encryption that someone said was totally 'secure'. And even the media have pushed a few stories about how evil criminals are using it to evade monitoring..

No, I'm not sure I'm on your side. This is clearly totally secure and no one could possibly abuse this kind of thing..

Right?.... Right?

starts crying and loads the rifle

The lack of federation is unnerving, but the main server-less alternative I know of is PGP or maybe OTR, and PGP is way too hard for most people IMO. Also, OTR doesn't trust the fingerprint from first messages, so even that introduces an extra hoop to jump through.

For E2E? there's essentially PGP (sucks, see thread from the other day. worst user experience and questionable longterm security), OTR (most used, still annoying to have to re-establish sessions on restart, no multi-device), and OMEMO (based on signal, should be the future for XMPP). You could include most proprietary solutions like iMessage that usually miss authentication or are done unsafely.

OTR not trusting fingerprint is the default case for any authenticated standard. gnupg requires that you set the trust on a key. Signal allows it initially, warns if it changes.

For all the above though, they aren't a packaged solution that is user friendly. Conversations is a great android client, but there's sadly nothing comparable on iOS (chatsecure, but it's alpha status still). The desktop situation is hit and miss too (I was a pidgin user and moved to bitlbee for OTR, still don't have an omemo solution... though my setup doesn't need it through a TLS secured ZNC).

It's fairly new, but OMEMO was just officially published (now that there are free specs available to reference and everyone can be sure there won't be weird legal trouble later), and Conversations (an XMPP client for Android) has just started using a new Trust model (https://gultsch.de/trust.html). It's early days, but I can see this being a good compromise between security and ease of use (like Signal). We'll see.