Most active commenters
  • corty(3)

←back to thread

242 points raybb | 11 comments | | HN request time: 1.036s | source | bottom
1. cmckn ◴[] No.26717119[source]
Eh, I don't think open source necessarily implies open development. Being able to look at and modify the source code of the software I use is the bar for "open source" for me; I don't expect every organization to do all their development out in the open. Seems like this code was made available while it was still relevant, so I don't think anyone is really at fault here.
replies(2): >>26717316 #>>26717662 #
2. corty ◴[] No.26717316[source]
For security software like Signal it does. When there is a lag in publishing server source code, the running version isn't what the public can inspect, but an old one that is no longer valid.

And it produces the appearance that they have something to hide, like the need to sanitize the source and get rid of something. Maybe it is just embarrassing WIP stuff, maybe a backdoor.

replies(1): >>26717394 #
3. fr2null ◴[] No.26717394[source]
I don't think it does, at least not for the security reasons you name.

If you are self-hosting a server, you may not have the latest and greatest features, but all the code you are running is open-source, so no sneaky backdoors (well, no more sneaky backdoors than the ones in the open source code).

If you are not self hosting, than it really doesn't matter if the server source code is open or not. There is not a single guarantee that they are actually running the that code on their server.

(For client code this is a different story of course, but we're talking about server source code)

replies(1): >>26717588 #
4. corty ◴[] No.26717588{3}[source]
In a strict sense, you are completely right. But nonetheless people are recommending Signal because the client implementation looks good and is somewhat verifiable (absent appstore evilness and ignoring the lag between update and verification). The server implementation however is only based on trust in the people running the servers. And there, openness about the code at least gives a few hints about what is going on there, enabling me to trust at least a little more than not-at-all.
replies(1): >>26717895 #
5. alerighi ◴[] No.26717662[source]
If I can't get a Signal server running myself, or if I can't compile the Signal client and install it on my phone, what's the point of being open source?

They could release a version of the server codebase that is not the production one, and who knows? They could put on the Google Play Store/Apple App Store a version of the client compiled from different sources (and mobile builds are not reproducible), and who knows?

Also the main benefit of FOSS is the possibility to take the source code, modify it, implement new functionality, fork it, and so on. And Signal is against that. So to me it's like a proprietary software.

Telegram on the other hand it doesn't provide an open source server, but the clients are 100% open, you can compile a client from source, modify a client, make third party clients that implements the Telegram protocol with the official libraries. All of that it's useful not only for improving existing clients, but for automating stuff, there are libraries for basically every programming language to interact with Telegram. That to me means being open source, and what distinguish Telegram from all the other applications.

replies(1): >>26717826 #
6. rOOb85 ◴[] No.26717826[source]
Both the server code and client code are open source. You're absolutely free to take them, modifly them, and do whatever you want with them. You're free to make your own fork and create your own chat service.

However, signal won't (and had not obligation to) provide your forks infrastructure. It costs money and time to maintain servers and they don't want 3rd party projects leeching their resources.

Again, your free to take their open source code and modify it and stand up your own infrastructure. If you do, you'll end up with your own chat service.

replies(1): >>26718071 #
7. rOOb85 ◴[] No.26717895{4}[source]
> The server implementation however is only based on trust in the people running the servers.

They literally chose a zero server trust model when designing the protocol. NSA could be running modified signal servers and it wouldn't make a difference. Your messages would still be safe since all the magic happens on the clients. The servers just route the encrypted data, it's all just 1's and 0's to them.

> And there, openness about the code at least gives a few hints about what is going on there, enabling me to trust at least a little more than not-at-all.

Do we even know if signal was running updated server code in production? Maybe they have been running the same code that was on github this whole time.

replies(1): >>26717990 #
8. corty ◴[] No.26717990{5}[source]
> Your messages would still be safe

Only the message contents. Everything else, like time, identities, communication networks is still at risk. What you are saying is very misleading since you completely neglect to mention the importance of all that non-content metadata.

9. saurik ◴[] No.26718071{3}[source]
I feel like you missed the point of this discussion: the server code in fact hasn't been open source for the past year, and so one couldn't make a fork of it.
replies(2): >>26718771 #>>26719656 #
10. cmckn ◴[] No.26718771{4}[source]
I wouldn't say that, they just didn't provide open access to their feature branches before they were merged (or "production-ready", however you want to put it).
11. tablespoon ◴[] No.26719656{4}[source]
> I feel like you missed the point of this discussion: the server code in fact hasn't been open source for the past year, and so one couldn't make a fork of it.

That seems to be overstating things. The server source in fact was always available, but there's nothing about open source that says a developer has to push their changes out on a particular schedule.

Also, it's supposed to be E2E encrypted, so I think the source that's really important is the client.