Follow

Centralised messenger Signal has just announced that they are making part of their server software closed source. They claim it is to fight spam, but by using closed source they make it impossible for outsiders to verify the truth. This is worrying.

We really, really need a fully open, decentralised alternative to Signal.

There are several alternatives being developed, please support them:

➡️ @snikket_im

➡️ @xmpp

➡️ @matrix

➡️ @delta

➡️ @briar

➡️ @Jami

Signal, dangers of centralisation 

The main issue with Signal is what is its end game?

Let's say they want to become a mainstream messenger service, like a privacy-friendly alternative to Whatsapp.

Let's say they got hundreds of millions or even billions of users.

At that point, the network effect would be VERY strong and Signal users would be pretty locked into using it, come what may.

And then... Signal would be a very tempting target for acquisition by Facebook/Google/Amazon etc.

(1/X)

Signal, dangers of centralisation 

Signal is owned by a non-profit, the Signal Foundation, which is headed by Whatsapp creator Brian Acton.

If Facebook/Google/Amazon offers Signal Foundation, for example, $20 billion to Signal either as a purchase or a "donation" or some kind of partnership agreement, what happens next?

We don't know.

What we do know is most Signal users would be stuck the same way most Whatsapp users were when its privacy was degraded.

Centralisation is dangerous.

(2/2)

@FediFollows @snikket_im @xmpp @matrix @delta @briar @Jami It is unfortunate to see this occur, but I am optimistic that a more decentralized model with several different clients may be a good idea. Youtuber 'Mental Outlaw' has a good video discussing Signal's encounter with the FBI, as well as how Signal forks could help.

@FediFollows @snikket_im @xmpp @matrix @delta @briar @Jami I see an ideal future in using unified standards with multiple decentralized clients. Matrix seems like a good framework for this, with independent servers able to talk to each other in a way that.can federate them the same way Mastodon does. I would hope that Signal reconsiders, but we can't be too reliant on only one service.

@Trimble_tech

All of the alternatives listed are decentralised, none of them lock you into a single network like Signal does.

@FediFollows Personally, I think for future implementations we should focus on approaches such as Briar, Jami, maybe SSB, Matrix P2P or Tox (that do not depend on particular servers). Jane Doe will not be able to run a server of their own or know someone trustworthy, so there will always be the need to trust a server hosted by "someone else". For this setup, FLOSS doesn't make things better at all because, open or not, you never know whether the code ...

@Trimble_tech

@z428 @Trimble_tech

You're able to talk to me on ActivityPub because Mastodon made it more user-friendly to sign up, with consistently branded instances, and a good on-boarding site that gets widespread media coverage.

@snikket_im aims to do the same for XMPP.

XMPP at the moment has a working system but a really messy and inconsistent public appearance. There's no proper onboarding, signing up is scary, instances look scary, no recommended servers etc.

@FediFollows Did by chance we ever consider that maybe Signal, Threema, ... are operating on a threat model completely different to what XMPP or federated services try to address? XMPP in example is pretty much *not* zero-knowledge, hasn't avoidance of metadata baked in, ... . Last time I checked, even XMPP with OMEMO had unencrypted sender and recipient information in its messages. Compare that to Signal and sealed-sender. And so on ... 😶

@Trimble_tech @snikket_im

@z428 @Trimble_tech @snikket_im

Signal being centralised is a major problem. Popular centralised services are a magnet for acquisitions by bad actors, because the network effect traps users on the network.

This is what happened to Whatsapp, it used to have better privacy but then it was sold to Facebook by its two creators, including Brian Acton who became a billionaire.

Brian Acton is the guy who bankrolled Signal's development, and is head of the Signal Foundation which owns Signal.

@z428 @Trimble_tech @snikket_im

I am not saying Acton is acting in bad faith, it's impossible for me to know.

But by setting up Signal like this, it's making it more difficult for outsiders to verify his intentions, and making it more difficult for Signal's users to leave should something go wrong.

@FediFollows But "it's impossible to know" nails it for virtually everyone operating any service: You never _know_ whether all actors act in good faith. You always either have to trust them, or you can opt for solutions that don't require that kind of trust and dependency. I'd prefer the latter, which would boil down to servers being "just" dumb transports meeting two requirements: (a) The server and/or any of its operators mustn't know who I am, who I am ...

@Trimble_tech @snikket_im

Signal, privacy discussion 

@z428 @Trimble_tech @snikket_im

Yes, but with popular decentralised services like email or telephones, if bad faith actors are exposed people can migrate to other instances. They may (or may not) have to let their contacts know about their new address/number, but it's do-able.

With popular centralised services, the person running them could say they're removing all encryption, and most people would still have to use that centralised service due to the network effect.

Signal, privacy discussion 

@FediFollows Well... in a way yes. In terms of telephony, I see a lot of fuzz at least over here (Germany) to make sure you can keep your phone number when choosing a different provider which seems absolutely crucial for good reasons. And e-mail.... well, e-mail. If I browse my address book, GMail, Apple Mail and other heavyweights by far dominate the list of those who still bother using e-mail. E-mail, in a way, seems failed ...

@Trimble_tech @snikket_im

Signal, privacy discussion 

@FediFollows ... decentralisation exemplified. That second reason is very well valid, but then again: Network effect happens on a protocol level too. And there's not always a bad thing in this. Just looking at encryption: Signal then and now *forces* their users to update the clients (or lock them out otherwise) if there are any flaws considered severe enough to not be tolerated. Try that with a federated open environment, with ...

@Trimble_tech @snikket_im

Signal, privacy discussion 

@FediFollows ... clients and servers (part-time) maintained by different individuals. It's difficult. 😉

@Trimble_tech @snikket_im

@FediFollows ... talking to, which kind of message content I'm transferring, which groups I'm part of and so forth. So far, I see both Matrix and XMPP doing rather bad at this (see web.archive.org/web/2020090518 in example). And (b) switching instances, in case my admin or its organization decides to behave shady, is sold out, ... , needs to be much cheaper than it is now - without me losing contacts, groups, communication history, ..., and much more important, without ...

@Trimble_tech @snikket_im

@z428
As for the issues you raise around trust in server operators, there are a few paths to take:

1) the Snikket way: encourage smaller servers, run by people the users know and trust in a specific social context (e.g. family member)

2) Use a pseudonymous account on a public server via Tor/I2P/etc.

3) Use something "serverless" like Briar, and accept the limitations of such a design.

Which of these is best depends strongly on your specific use and threat model.

@FediFollows @Trimble_tech

@snikket_im Glad to see account portability is becoming a thing in this world. From where I stand, (1) and (2) are okay but not (yet?) able to cater to a reasonably large group of users, a group of users large enough to really make a difference compared to the proprietary silos. Most folks in my environment don't know someone who could handle running a trustworthy smaller server, and I personally would be capable of doing so yet stay away from it because in ...

@FediFollows @Trimble_tech

@snikket_im ... order to replace WhatsApp or Signal this would require a considerable amount of continued work and still bear the risk of, say, being target of an attack, of surveillance targetting my infrastructure at a lower level, or of being blocked by other instances for whichever reasons. But that's just a personal view, more important indeed is what I see about specific use and threat model, that's why pretty often I feel very bad seeing XMPP as a ...

@FediFollows @Trimble_tech

@snikket_im ... suggestion to replace Signal or Threema. It's a good tool for some purposes, but it tries to solve a totally different problem in my opinion. 😉

@FediFollows @Trimble_tech

@FediFollows ... my contacts losing contact with me without even noticing. I don't really see this possible or implemented in any of the "federated" messengers at the moment, even in Mastodon (which isn't a messenger and rather good at "user-friendly federation") user accounts are tightly coupled with particular instances and essentialls "lost" if an instance, say, goes down overnight or is taken over by some undesirable actor.

@Trimble_tech @snikket_im

@z428
We've been working on (b) at docs.modernxmpp.org/projects/p

There's still some work to do, but by the end of the year we aim to complete the majority of the remaining tasks to make migration trivial for users.

Based on our findings, almost all servers shut down with some advance notice. However using the tools and data formats we've been working on, you can also pre-emptively back up your data.
@FediFollows @Trimble_tech

@FediFollows I'm not about to defend centralised approaches or stuff using shady funding, that's why in most cases I still prefer Threema. But: In a way and for certain threats, XMPP also is "centralised", just at a smaller scale. If your instance starts acting shady and you don't notice, you're lost. If your instance goes down overnight, you're out of reach for your contacts. Not even @Trimble_tech @snikket_im - 1/2

talking about spam, unsolicited instances, ... or admins becoming an interesting target if someone huge enough wants to spy on some particular user. I only really see P2P approaches solving these problems at the moment, if leaving Signal or Threema aside because they're centralised in some way.

@Trimble_tech @snikket_im @FediFollows - 2/2

@juleLe Yeah, quicksy is pretty good at what it does. My problem with these tools, however: Neither XMPP nor e-mail (deltachat) have been built with security in mind as a first-class citizen. In both cases, server-sided metadata, unencrypted transport metadata, ... are issues. We too often seem to fall back to these old tools because techies like them and are comfortable using these, rather than focussing on crafting up-to-date tools to fix these flaws.

@FediFollows @Trimble_tech @snikket_im

@FediFollows ... you see is the code a server actually runs, let alone knowing the server is "secured" properly. Plus, it greatly seems about different (and maybe orthogonal) requirements. Take Element One "bridging" Signal: Cool from a perspective of not being forced into a particular network anymore. But doesn't that kill E2EE in Signal, given my Signal "end" isn't my local client anymore but some bridge operated by "someon" on some server implemented by "someone"?

@Trimble_tech

@FediFollows @snikket_im @xmpp @matrix @delta @briar @Jami You should also add @session to the list. It's quite a popular decentralized messengers that has both Android and iOS support and they are currently working on onion-routed calls, which will make them a really good Signal alternative

@FediFollows I don't think so. I mean, it doesn't affect E2EE and it's not like they made any existing software proprietary. Also, their explanation is quite understandable. All in all it's not such a big deal in my opinion.

@datenschutzratgeber Agree. Plus, comparing Signal (which, same as Threema or Briar) focusses on zero-trust/knowledge servers and avoiding metadata altogether) to something like Matrix or XMPP (where, at least by default, there's no shortage of metadata piling up on various servers in a federated environment) seems ... difficult.

@FediFollows

took a ~year to get an update in the git repo

knew this was coming

@Mia @FediFollows Yeah, they were running closed source code for a good 10+ months last year even if you give them the benefit of the doubt.

It's never been anything other than a marketing ploy

@FediFollows You're definitely entitled to your opinion, but I think you're taking this a bit far.

There are benefits to centralization and definite downsides to the P2P model. Everything else is open, especially the encryption-related stuff, and the reasoning is valid. The product itself is very good and usable for regular people. Just something to consider.

@FediFollows @snikket_im @xmpp @matrix @delta @briar @Jami
Matrix is a good alternative for all the messengers whether that be Whatsapp, Telegram or Signal

@SteveKLord @FediFollows @session session isn't actually decentralized or federated, it's just centralized with extra steps. At least it was last time I looked at it.

@mvgorcum They certainly bill themselves as decentralized and use those nodes to create that but I'll keep an eye it to see if you're right. For that matter, Matrix isn't exactly as decentralized as they claim either . hackea.org/notas/matrix.html

@SteveKLord this post is outdated, and itself also largely FUD, most notably the link with Israel is an unfair association. Otherwise it is a fairly bad summary of a research paper by someone who was kicked out for being an unproductive community member.

There were some valid points in said research, which have been addressed and fixed, and since then a lot of improvements have been made for a more private ecosystem.
If you would like to discuss point by point feel free to ask

@SteveKLord because the whole project has long since separated from amdocs, and it has always been a project made in the UK and France, by French and English people.

@selea @FediFollows @session session isn't actually decentralized or federated, it's just centralized with extra steps. At least it was last time I looked at it.

@FediFollows are there any free xmpp hosts/providers that are secure AND don't look really sketchy when you open the web page to register?
I think that's a huge stumbling block in getting people to use xmpp.

matrix is pretty cool but can be slow and not super reliable to receive messages on mobile.

I will be looking into the other projects you mentioned.

1/2

@kevin

That's exactly what @snikket_im is for, to provide consistent software, apps and branding across an XMPP federated network. (Sort of like Mastodon did for ActivityPub).

@FediFollows
I still think signal is better than whatsapp and the other alternatives and it has the benefit of some polish that makes it easier for people to want to install and actually use.

Afaik, e2e encryption is done on the client side so the server code doesn't matter as much. though I don't really know how they are going to filter spam if the "can't tell what's inside the message".

2/2

@FediFollows @snikket_im @xmpp @matrix @delta @briar @Jami "by using closed source they make it impossible for outsiders to verify the truth" -> Well, in a centralized service you couldn't verify they are running the source they release anyway. Nothing of value was lost in practice.

@FediFollows

Duckduckgo does the same too by the way, they also use a proprietary software on their servers.

re: Signal, dangers of centralisation 

@FediFollows

in this status, each and every country will ask , by the rule of law, to have LIBoxes inside their systems, to be able to read communications. Like they do in the access network.

Only a network made of tons of little servers may be safe. Too much work for the govt.

Signal, dangers of centralisation 

@FediFollows
Exactly!!

Signal, dangers of centralisation 

Sign in to participate in the conversation
Mastodon

This is a brand new server run by the main developers of the project as a spin-off of mastodon.social 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!