So the Fairphone OS is closed source yet. No one knows if, or when there will be an open source OS for the FP3.
1 Like
This discussion is going in for many years now. Basically they argue that centralization is good for security and usability. They want to control all distribution channels and all clients because the ecosystem is moving. So I get their arguments and so far their success has proven them right.
Iām confident that if that centralized control is misused, somebody will fork the project and try it with a different organizational style. (federated servers, independent clients)
4 Likes
Nope. The server is not free software entirely. Major development efforts need to be done for forking Signal infrastructure. Or Telegramās, BTW. They are centralized and always will be.
2 Likes
Whatās your source for this? I looked it up and there are several people in the Signal Community Forum who say the have the Server running on their own Systems. It doesnāt look trivial but nobody mentioned that there would be proprietary parts.
3 Likes
Not allowing clients to connect because of EULA while these clients do nothing wrong to your network is against the spirit of open protocols, and arguably, against the spirit of open source. Would be something if Cisco said you are not allowed to use your TCP/IP stack with our routers. However, because Signal a smaller part of the whole stack the impact is marginalized, and because it is FOSS it should be reasonably easy to fork if it is necessary (if the server code is FOSS then that would make it a lot easier; I donāt know whether it is or not).
4 Likes
It may have changed. It was the calling functions, IIRC. Iāll review the current situation, thanks for the link! 
thanks all for your responses. i was having similar questions and your answers were helpful to me.
2 Likes
To me it all looks like yet-another Russia-bashing, like the āscandalā about FaceApp: āif itās not Made in US, donāt use it (because Russia is bad -they have bears and such)ā.
WhatsApp was bought by Facebook, which is even worse than Google, but nobody seems to care (especially since they merged their databases Facebook+WhatsApp). The fact that this several-yeas-old article is brought back up now just sounds more political than technical.
I have strong reasons to believe backups are encrypted. If not by Google, at least by WhatsApp. It wouldnāt make sense to openly store such personal details in a Cloud (especially with the EU Personal Data Protection regulation). I know from several internal sources that Google canāt read your GMails, but I didnāt hear about their Drive.
Important : Media and messages you back up arenāt protected by WhatsApp end-to-end encryption while in Google Drive.
Iām also really curious if thereās a way to verify what your āinternal sourcesā say regarding Google reading your Gmail messagesā¦ I simply cannot believe that is true. Maybe thereās some sort of protection so that only certain roles within the organization can read them, but they definitely do have access to them and scan them.
8 Likes
Thanks for the WhatsApp link, at least theyāre clear about it.
My āinternal sourcesā is family who worked there for a couple years and got internal insights about how privacy was handled at Google (and theyāre really serious about it, which is expected of course, but always good to hear itās not just PR talk), and some SRE engineers trying to recruit me.
Of course, itās not Open Source so thereās always a doubt whether itās āreally realā, but such big companies depend too much on their market shares to be caught lying about such sensitive subjectā¦
2 Likes
There is no E2EE on Gmail. GPG applies public key cryptopgraphy, but is optional and leaks metadata. Authorities can ask the information from Google, and Google will comply.
The Telegram issue has nothing to do with Russia; Iām pro Europe, not pro USA or anti Russia. If an American or European would use homebrew cryptography, while other standards are proven, the crypto community would not trust it either.
5 Likes
The point about āhomebrewedā algorithm was indeed valid at the time (Iāll edit when I find the Crypto StackExchange question about it), but it is now fully recognized, so itās now considered a fully-functional algorithm.
And Google, as any other company (or FOSS developers), has to comply with local laws, no matter what they (or we) think about it (again, Iāll edit when I find the lawsuit about the guy who did the encrypted email service Snowden was using, and was forced to give away the keys).
But thatās exactly the problem with G00gle. They know almost everything about you, so they are able to hand over your entire life to [pick your favourite US secret agency]. However if said agency goes to the Signal foundation with a warrant, all they can get is the register date and the last time the user was online. So while they are still under US juristiction, thatās not really an issue, because you canāt give information away that you donāt have.
7 Likes
āFully recognizedā? What is that supposed to mean? Do you have a link which backs this up?
Yes, I know about the lawsuit, it was Lavabit [1]. The guy who ran it made mistakes regarding cryptography though. He shouldāve at least put every e-mail box on a different public key, and he did not use E2EE at all (e-mail, by design, does not).
2 Likes
Itās in the articleās update:
Update 8/31/2019: After publication of this article Telegramās creators implemented several changes that are recognized by qualified cryptographers as a vast improvement to its encryption scheme. Since 2017, for example, the MTProto protocol has been recognized as IND-CCA secure.
I would like to read more about which āqualified cryptographersā said that, what they said exactly, and a link to the analysis. The links at this webpage
Link to the very same statement on the bottom which contains no details whatsoever.
The same Wikipedia page also contains criticism about the biased cryptography contents:
2 Likes
I have been programming and running (as SAAS) secure instant messaging systems for heathcare during 12 years, I have been (and still am) member of the XMPP standards foundation for even longer and I have seen over half a dozen of protocols for e2e encryption and many more implementations. (And I am presenting on conferences about my experiences). Some observations on IM security:
- Without a clear and explicit idea what you want to secure against, it is totally useless to talk about āsecurityā. Protection against a big silicon valley company that wants to profile you to sell advertisements takes different security measures then protection against reconnaissance by a secret service (āfishing netā) and that takes different measures then protecting against targeted attacks by secret services (e.g. human rights activists). And that takes again different measures then when outages in the network (intended or unintended) are your biggest security threat (e.g. emergency services, coordination in case of an disaster or extreme violence against protestors) and that takes totally different measures then protecting victims of domestic violence. I was surprised to find out that Telegram is extreme popular in Albania becauseā¦ it protects against unsolicited messages. Each situation takes different security, so stop talking about āTHE security ofā.
- Leaking metadata is a huge and underestimated problem. In many situations metadata leaks are fatal (sometimes literally). End to end encryption protocols donāt protect against metadata leaks and sometimes even cause metadata leaks on their own. Almost every implementation of end to end encryption I am aware of, fails here. Because of the failure to protect the metadata, almost every implementation doesnāt protect the end users against the threats they expect to be protected against. (But those impementations do protect the server operators against being raided by the police.) Systems that do have proper metadata protection are: Briar, Katzenpost and Cwtch (all experimental and with issues on their own).
- Good protocols and algorithms are usually killed by implementation choices. When implementing security measures, it is very easy to take a shortcut that kills it. Verifying keys (necessary to get most schemes secure) is usually the first victim because that is an utterly clumsy process for end users. Most implementations fail there, up to the point of implementations of good protocols using public traceable identifiers as secret. Doing everything right is extremely hard. The idea that a good protocol or algorithm equals security is a huge fallacy.
Having said that all, my preferred choice for my personal and business communication on android is the XMPP client Conversations (https://f-droid.org/en/packages/eu.siacs.conversations/) in combination with a self hosted XMPP server, in my case Prosody (https://prosody.im/). But you can of course use Conversations in combination with an other XMPP server or with a hosted XMPP service too (resulting in a different security profile).
If Fairphone wishes to recommend an IM solution, I would vote for Conversations.
8 Likes
@Winfried
The Austrian Fairphoners usedvXMPP (t
In the form of Kontalk two years ago, but we stopped because the app was nit that good.
What do you think of matrix? Iām only judging it from an end user perspective, but I think itās much less of a hassle to use than XMPP.
@Stanzi Yes, up to Conversations, there was no XMPP android client I was really happy with. And on IOS I still am not really happy with the available clients. I would say: give Conversations a try, it really ticks all the boxes.
When comparing to Matrix: I am a bit biased, because I am deep in the XMPP community, but it is hard to compare a protocol with a complete ecosystem and many applications like XMPP to an chat application like Matrix. It is like asking: how does the whole railway system compare to a Volkswagen? Matrix is much less of a hassle because it is a single application and server with a single codebase, intended for a single use and inventing its own protocol. That makes it much easier indeed to create an uniform user experience. And if that ticks all the boxes for you, go for it.
Some aspects of the protocol of Matrix I really like, some I donāt. But in the end it feels to me like yet an other silo.
3 Likes
My 2 cents:
- Signal server software is open source, Telegram isnāt. Thatās the main reason I just Signal and not Telegram.
- Briar is a decentralized implementation of the Signal protocol. However, last time I tested it (one year and a half ago) battery life wasnāt good at all. No idea how it evolved and whoās the team behind it. I would be very interested if someone can tell more about it, it looks promising.
1 Like