Viewing a single comment thread. View all comments

celebratedrecluse wrote (edited )

Reply to comment by crabbers in F-Droid bans fascist gab by ziq

Well, that's just one of the problems. Google isn't the only privacy adversary to be concerned with.

My main issue with the project is that Signal PM is a centralized service, targeted heavily by state actors in the country it is hosted from/the developers live in. If all the messages are going through one node, and the developers actively prevent others from setting up their own servers, and the dev team basically spun off from a silicon valley tech giant (twitter), that's a bunch of red flags. Combine that with the fact that the userbase is mostly journalists, activists/radicals, people who are legally vulnerable, lawyers, and paranoid people who the government wants to keep an eye on anyway, you have a recipe for a giant honeypot.

It's a great application, but the server end of things is really problematic. Even if they are somehow not compromised internally, there must be a whole department of American intelligence devoted to fucking with the integrity of the project. This could be avoided by decentralizing the servers, allowing people to set up and choose their own relay servers, but for various reasons they don't do that or even consider the centralized model a problem. They won't even allow the apk to be added to other repos like F-Droid. And don't even get me started on the nerfed, totally fucked "Desktop" app-- there is no good solution for running Signal on Linux, and the devs have no desire to make one either. Major red flag.

I think that from a technical perspective, an environment like Matrix is a much better solution.

edit: additionally, using the method you described Google Play Services (which runs as root) is still going to basically have access to all the data inside signal, like your messages; for example, it can log your keystrokes & audio/video input, circumventing Signal's encryption trivially. Google is passively doing this all the time in order to build its marketing profile of you. If you used a credit card or some other form of traceable digital money to pay for the phone, the phone is trackable back to your real identity by corporations & state actors. Plus, facial recognition, plus, speech recognition, plus, Google's automatic contact logging from your phone's contact app (even if you don't store them in the cloud), all adds up to a litany of different ways of getting the identity of the person using Signal, and the messages they send, and who they are talking to. So really, using a smartphone at all is going to essentially make Signal not work according to the ideal design, and the developers have made it all but mandatory to use a smartphone for the app to work...very convenient, for the surveillance state, regardless of what the intentions of the Signal devs are. The fact that they don't take these issues, and others I didn't go into, seriously....well that speaks for itself, imo


quandyalaterreux wrote

I'm sorry but the 'decentralization' argument against Signal is flawed, see this excellent blog post by m0xie on federation:


celebratedrecluse wrote (edited )

very telling that the post makes no mention of any of the specific security problems with Signal, some of which I mentioned. It merely dwells on platitudes about how email is google-centric-- meanwhile, Signal makes it intentionally very difficult to stop that very same company from swiping all the important metadata.

Contact discovery, profiles, and tying the entire identity to a phone number are also terrible ideas as far as an at-risk end user is concerned: anonymity, privacy, and plausible deniability would be at least as important as the security of the message contents, but unfortunately there are a bunch of holes in how the Signal service works now. Again, I'm not saying this is inherent to the Signal application, which appears fantastic to me. I'm speaking about the particular, "main" fork which is called Signal Private Messenger.

However, if you are mainly concerned with growing the service as fast as possible and retaining as much control over the service's parameters, then the decisions of the Signal devs begin to appear much more aligned with the priorities. However, this bizzarely replicates the logic which is critiqued in the essay you linked, by creating in practice a central social node around which all the other services orbit.

I don't accept the central premise of the blog post. Federated systems don't have to be stagnant. In Signal's case, compatibility between multiple servers could be implemented, without compromising on the security of the "official" app to "official" app communications, or even involving major changes in design. At any rate, the combination of unencrypted text messages into the Signal app, and the nature of the program's phone number based identification system, says pretty clearly that the developers aren't about to discard the federated model on a desire to increase the security/functionality of the service internally, not when it comes to large corporate actors.

To the contrary, it seems that only the smaller players are pushed out of the field: people who want to run their own servers for personal use, or even just run the application on Linux, or not use a phone number to you can see, this seems like either bad faith or bad reasoning, to a lot of anarchists. It's important to make sure that there isn't one target for state surveillance in a particular domain! If you haven't learned from all the market busts in the last 5 years, this invites the kind of attention which will ultimately compromise a project: as soon as something becomes dominant, the go-to, it paint a reticle on its chest. That's just the social and political reality, unfortunately. So my perspective is that Signal, by encouraging the development of a central node for targeting, will ultimately be found to have been seriously compromised by some state actor and used as a passive listening system to track people of interest, build a case, and then establish parallel construction.

Rather than building a single solid United Front against all these numerous & well-equipped enemies, I think it is a more effective and trustworthy to focus on creating an ecosystem where multiple projects with different priorities (privacy, anonymity, ease of use, etc) can coexist and intercommunicate under common standards that focus on security. This requires direct communication and coordination, but there's no reason why it couldn't be done if people felt is was necessary and decided to operate that way while developing their projects.

my opinion: The Signal service is designed to be very easy to use, but it has all these obvious flaws which are papered over quite thinly with buzzwords. This isn't a problem unique to Signal, and it is an incredible project and has added a lot to the FOSS community in terms of visibility and code. However, I can't help but be suspicious of all these red flags.

edit: made my post less passive aggressive, and added some further points. Sorry about the initial comment


crabbers wrote

Thanks, mate. I appreciate you taking the time to lay this all out for me.


celebratedrecluse wrote

No problem, nobody has to ask me to launch into an unsolicited tirade about opsec lol so I'm glad you got something out of it