OFFICIAL SFOSX Signal client

Applications
#17

I don’t know why you would quote me but then edit what I actually wrote. You might want to provide some (credible) sources for that outrageous first claim. Also, the ‘someone in this thread’ is the person who knows a lot more about Signal than any of the other people (including myself, of course) who commented combined, and it would be worth actually reading what he’s saying rather than spreading far-out conspiracy theories. Signal is more than just Moxie, and @rubdos is not just creating a third party Signal client (which the Signal developers are very much aware of ), he’s collaborating with the Signal developers to make it easier for third party clients to build upon work already done by Signal.

How much ‘openness’ are you looking for, exactly? All of the source code is available and published under a free license, and they even do reproducible builds, making it possible to verify that the code distributed in their binaries is in fact the same code that you can see on their Github pages.

1 Like
#18

Hey @olf

Just FYI, Whisperfish is being developed with full awareness of what you say.

First point: the client source code has always been public. It’s the server source code that’s been hidden away for way too long, and that’s finally been made public some weeks ago again. Of course, we’ll have to see whether they can keep that up now.
Development in the open is being worked on, and it’s much better since you probably last checked.
Like @nthn already hinted, I am in contact with Jordan Rose (from Signal) about collaborating to get as much code as possible upstream.

Re legal action, we’re aware of that, and I have written quite extensively about it in the past. The fact that I’m working together with Jordan doesn’t really change that statement, except for the fact that they are aware of our existence, and that they seem to tolerate us.

Re federation: I tend to agree with Moxie, and that actually makes me sad. Federation helps in distributing power, but it’s actually terribly difficult to have the privacy properties that they have right now in a federated setting. Actually, I should write a master thesis topic about that for a future student, but I’m afraid it’s more of a PhD-kinda-thing.

Re promises, they are quite old. The excuse there (and it’s just an excuse) is that it’s difficult to implement these things right and privately. However, they did implement these things a few months ago, and the only lacking thing is the actual exposure on the server (in terms of API) and on the UI. It’s coming, and I expect it before the end of 2021.

7 Likes
#19

Open source for client/server is not the same as open governance and open development for the protocol. Many things are open source these days (e.g. Android), and while that’s nice, it still is one company holding all the marbles.

Regarding privacy: even if it’s true that Signals privacy really is great, it still can have access to a ton of metadata. A Matrix-provider might have even more metadata, but it cannot have metadata on the entire network. I run my own server, which I share with family. I’m pretty sure no one has access to the metadata but me.

Also, Matrix is working on fully decentralized P2P communication.

#20

Well, being from Switzerland may not mean that much after what happened to Crypto AG

1 Like
#21

… which @olf also mentioned, and to which I responded …

EDIT: I’d like to stress again that I’m not claiming that Signal Messenger LLC has become holy since three weeks. My point is that the situation is way better than what is generally portrayed by fans of Threema et al.

3 Likes
#22

What are we fighting about again? Who’s right and who’s wrong? Whose views are the absurdest? Who’s got the better arguments? Who’s better at misinterpreting the posts if the other?

How does that answer or help the OP? How does that contribute any valuable information, help gaining new insights on the matter?

All questions originally asked (why no official Signal client) have been answered. Stop throwing sand at each other, please.

7 Likes
#23

Well, matrix is federated which is a completely different kettle of fish. AND matrix uses some of marlinspikes algos (albeit OLM and co. are derivative, they are derivative!).

I’m not sure if or how the fediverse will ever get a foothold, but then, the world wide web was once ‘boundless’ :wink:

And you’re right about the FUD. Even if you don’t trust Moxie (never trust a sailor, dude, oh irony!) it’s all happening in the open.

#24

OH, maybe I’m out of sync. I’m working on a matrix deployment (and mattermost, sigh) and am running into other problems (matrix clients rarely implementing end to end crypto properly). And at the end of the day, the people I service ALL use signal.

We do, however also have XMPP with OTR which is quite good. The problem is that I cant’ (even with QT > 5.12) support all clients (mac os, anyone!!!). Does anyone know of a slack like interface that rests on XMPP???

This is a plea!? I’m running a bunch of parallel infra and am starting to believe I’m simply going to fail to improve users lives (workflows). The mainstream will simply run teams/slack/mattermost and ROLL over us.

It’s kind of sad. I’ve been doing messaging support (among many other things) for 20 years and we’re not really any further … personally being fine with XMPP (or irc) doesn’t cut it with the amount of staff I have to support.

#25

Who does your identity management? matrix.org?

#26

2 posts were merged into an existing topic: Matrix and Sailfish

#27

@rubdos, many thanks for this answer.
It was helpful for me to understand some aspects better.

#29

???
E.g., federation would make it impossible to “ban” client apps, to threaten people etc.

But “Yes”, in un-federated networks, there is way too much power at a single point: the central node.

#30

Federation can be dangerous vis. privacy. The journalists I work with i keep away from federated systems for certain communication streams because federation opens up attack vectors. And leaks information.

In one context it’s a leak. In another, it’s a connection. At small enough scale, centralized means free. C’est la vie!

1 Like
#31

@poetaster, this is an interesting statement:
“[…] federation opens up attack vectors. And leaks information.”
I would have ignored it, if it would not be from somebody with profound technical knowledge.

Can you please point out the fundamental mechanisms which make “federated systems automatically resulting in attack vectors and information leaks, which centralised systems do not have.” in your opinion.

I would then try to map these arguments to XMPP with OMEMO (and / or Matrix), to see if they apply.

#32

With any federated system, like XMPP or matrix you have, in addition to client to server communication, server to server communication. As with mail systems that may at different times support different levels of encryption (or none at all) connecting these is always a hazard.

That alone is one large attack vector.

For some periods of time systems may be out of sync (one matrix server, written in GO is ahead of one on a newer kernel while another matrix server implemented in python is running on an older kernel …).

Sometimes, to permit people to communicate, you have to drop the level of encryption you support for certain server 2 server connections. I’ve been forced to do this with XMPP in the past although it’s thankfully happening less and less.

With mail it’s still a crapshoot. Right NOW I’m not allowing any non-encrypted communication on one of my mail servers. That’s an exception.

With XMPP clients we have had an end to end encryption mechanism in ORT (off the record) for some years that could be used on all operating systems (well, not sure about SFOS?!). The attack surface against ORT, however, is a lot more open when you federate XMPP (or matrix for that matter) simply because an attacker can begin with probes that would not be possile if the XMPP server was only a central service for a limited group of clients.

Federation also requires a larger code base. Server 2 server functionality adds complexity increases the risks…

yada, yada, yada :slight_smile:

But, I honestly don’t know how far matrix has come with libolm and their take on the signal crypto :open_mouth:

#33

Fair point, as federation by definition means that you are open to connections other than authenticated clients as well. Still, I have more problems with centralized services which handle all communication. You don’t have an option to choose a provider in a more trustworthy location, or host it yourself with extra hardening / firewalls if you like.

I don’t know enough about the matter if a centralized service is a pro or a con for intelligence services. If you’re on a small provider on a federated network, there’s less “noise” on the line. At the same time, it might be easier to fly under the radar in a federated network. Matrix uses default https, and afaik only https.

Regarding intelligence services: just a week or two ago, both Dutch general and military intelligence services were slapped on the wrist again by the oversight committee for overreach of their methods. That oversight committee is only there because of a referendum on a law which extended the allowed methods used by the intelligence services - the outcome of the referendum was against the law, after which the law was slightly modified to include a oversight committee. (After that referendum, the government passed a law ending the right of referendum. :roll_eyes:) My point: even in functioning democracies, intelligence services seem to ignore the law as they please.

1 Like
#34

Of course, I’m talking about a scenario where you have a choice of provider. Actually, I’m talking about being responsible for the infrastructure.

For me this thread has been helpful since I only realized while testing and communicating here that the federation identity requirement was ‘now’ optional. When I first ran tests for our staff, this was not the case (2 years ago).

So, I would definately say matrix as a server / protocol is a great way to go. The only problem at the moment is clients.

We will not use the electron clients (the browser based ones) since those are a nightmare to audit.

In sfos I’m only (thanks rubdos!) using signal since none of the matrix clients do the crypto. Oh, and I’m using xmpp (but only for non essential dialog).

Although I doubt I’ll find the time if I keep this (ahem) up, I’d like to port https://github.com/mirukana/mirage for SFOS … it’s really nicely designed and does proper end2end …

And of course the BND here in Germany (and all the other services) when not igoring the law are being empowered by the so-called ‘chrisitan’ democrats. It’s a bit odd at the moment. Luckily, the services are understaffed and tend to use hired guns. And those are all well know quantities!

#35

Oh, I see, this is all historic “yada, yada, yada”. ;\
Side note: XMPP-OTR is not really usable, outdated, and also has non-optimal security properties.

It only makes sense to compare modern protocols, providing E2E-encryption based on the “double ratchet” cryptographic scheme, i.e. XMPP-OMEMO (about 10 years old) and the Matrix protocol (newer, but fundamentally the same).
Some protocols of centralised services also use the “double ratchet” cryptographic scheme, e.g. Signal.

Yes, the metadata of communications is still distributed over many servers.
But that is the case for the centralised services too, as they only appear to be a single (logical) server (address): All bigger players distribute their servers geographically for load-balancing and fail-safety.

P.S.: If you are looking for a trustworthy, modern chat system with multiple, well working, FLOSS client and server implementations (plural for both!), there is only one: XMPP (“Jabber”).
You might want to take a look at the XMPP-clients Conversations (Android), Dino (GTK, Unix/Linux), Gajim (Windows, MacOS, Linux), etc. and the XMPP-servers ejabberd and prosody. For sure there are many more, but most of them are not in a production-ready state (as you already experienced with the Matrix client and server).
Plus there is a lot of documentation, many running servers to host one’s account, a large community and the biggest user base of all non-centralised chat-solutions.

1 Like
#36

The way you wrote this makes it sound like Signal is just doing what everyone else is doing, whereas what is really going on is that everyone else is adapting Signal’s cryptography to their own specific needs.

3 Likes
#37

Bingo. I tried to make that point but you did so more elegantly!

1 Like