Follow

Signal 100% can turn over user data.

1. They could dump metadata encryption keys from an unpatched SGX node.
2. The next update could silently send plaintext messages to feds.

They can't gaslight courts forever.

Centralized privacy will fail.

signal.org/bigbrother/central-

@lrvick The next update of every software (centralized or not) could silently send plaintext messages to feds. The client which encrypt the message is open source and runs on your hardware, it'll be the same with a non centralized software.

Non centralized softwares do not solve the problem of the needed trust in developper (for the app itself and all its dependancies).

@Courgette

They forbid third parties from building and distributing binaries built from published sources, or any third party clients. They explicitly refuse accountability or client diversity. It's all a SPOF.

Also pushes to Github can lag behind for months particularly in the case of the server.

They are pretty fast and loose with the term "Open Source"

@Courgette compare to -actually- decentralized software like Bitcoin or Matrix where many reputable people build and sign every release and distribute via many channels.

You also can have proof the code released is the code compiled via reproducible builds.

There are also alternative implementations for client and server.

Also no central server in either case.

Signal OTOH is intentionally a walled garden not significantly different from iMessage or WhatsApp.

@lrvick @Courgette Yes. They can also get pwned by the cops/state or simply bought. A swiss crypto company was run silently by the CIA (was it NSA?) for years, siphoning out state and commercial secrets. It may be happening to signal already and besides, how do we know the signal servers are running the published code?

@zeh @lrvick It may ​be happening on the mastodon instance you're on too. :oh_no:

More seriously, yes I think that non centralized software improve the trust on the "running the app" part. You can host your server and everything and know what version is running. And it increase the cost of massive surveillance. That's very cool. The first post was not about that (it's about trusting the code of the client).

And it's also more complicated than that. Trusting people with datas, it can really be complicated. For example a couple, they can share the same server and trust each other. But what happen during a divorce? What will have the more impact on their life? A betraying by their love one or the Signal server being runs by the CIA/NSA/WHATEVER. I think that the more you known the people, the more they can hurt you with the datas. That's the difficulty with threat models. Everyone have a different one. That's why is cool to have different way to access privacy against some threats.

I completly understand that Signal is not for you, and again, it's ok. But maybe it's very well adapt for others. And maybe it's possible to not try to scare them with problem generic enough to concern every software, centralized or not.

@Courgette @zeh I mostly talk about the server because forcing all users to put their metadata and key discovery on one server is a huge target. With federation we can move servers whenever we want.

When it comes to end to end encryption, you are right, trust in the client is the most important thing. That is where the message keys live.

This is why any E2EE service that insists you use their binary that they compiled should not be taken seriously IMO.

@lrvick @zeh On most of the federated software I known, you can't really move to another server whenever you want easly.

You can mainly create another account on another server. Like creating a new account on another messaging service. That really diffrent for me beceause for most of the people it come with a cost (communicating the new address to all of your contacts, losing some datas and so on - some time it comes with some tools to automated that, but sadly it's often not directly in the "normal" client app to make it completly transparent for the user) that make it really difficult to do it in practice. And in my exprience it force people to do it more often (because of people stopping to host their server for example).

But yes, I completly agree that non centralized software are very cool, that it make smaller target and may make global surveillance too expensive. But I'm not sure it's ready for general public, at least I known too many people that would not use it because it's far more complicated. And a solution that is usable only by a technical elite (or by people who have a lot of time to deal with the difficulties) is not a suitable option for me. But I'm really happy to see that there are a lot of improvment the last years.

@lrvick I completly understand that you don't trust Signal devs / workflow and you're more encline to trust others like Matrix's devs, and that's ok.
That do not change the fact that for me it's a matter of trust and not decentralization. Non centralized software is cool, but it do not solve the need to trust the devs of the softwares you're using.
I only pointed out that what you said in the first post is not exclusive to Signal (nor centralized software in a general) and I think there are already enough problems with Signal to be able to criticize it without using argument that concern every software.

(Yes some workflows can increase the trust we can have, but there are not exclusive to non centralized software either.)

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!