←back to thread

It looks like Signal isn't as open source as you thought it was anymore

(www.androidpolice.com)
242 points raybb | 5 comments | 06 Apr 21 18:04 UTC | HN request time: 0s | source
Show context
rvz ◴[06 Apr 21 18:46 UTC] No.26715723[source]▶
> While it regularly publishes the code of its client apps, it hasn't updated the Github repository for its server for almost a year.

Last commit was 5 days ago: [0]

As for not playing nice with third-party clients, I can give you that point.

[0] https://github.com/signalapp/Signal-Server/commit/365ad3a4f8...

replies(2): >>26715765 #>>26715780 #
tptacek ◴[06 Apr 21 18:50 UTC] No.26715780[source]▶
It's practically a principle of the Signal project to discourage third-party clients. Signal's security work is done, for obvious reasons, mostly clientside. If you have a diversity of clients, you're stuck with the lowest common denominator of mainstream clients. Without them, you can roll out any feature you want to.
replies(5): >>26715968 #>>26716208 #>>26717121 #>>26717165 #>>26717562 #
1. korethr ◴[06 Apr 21 19:22 UTC] No.26716208[source]▶
While I can understand not wanting a diversity of clients for the support headache that could rapidly become, I don't fully agree that a diversity of clients forces them to be stuck at a lowest common denominator. What prevents them from making the breaking changes necessary for security and features, and letting the devs of 3rd party clients successfully conform or not?

I see it as something like mandating minimum version of TLS or cipher suite. The security flaws of TLS version <1.2 have been documented for some time now. I've had to tell customers more than once we are disallowing use of older insecure protocols to access my employer's services.

Or am I misunderstanding you and actually happen to be agreeing?

replies(4): >>26716312 #>>26716320 #>>26717135 #>>26718212 #
2. tptacek ◴[06 Apr 21 19:30 UTC] No.26716312[source]▶
You can't just have security features not implemented on some clients; you have to actively break them. The simplest thing you can do there, versioning the protocol to indicate compliance, is easy for developers to work around. Users will stick with the client that has their preferred UX (really, in practice, they're going to stick with whatever the first client they got working is, because users hate installing stuff). It's a total mess.

I can't blame the Signal project for wanting to avoid it entirely. You can of course disagree!

3. zamadatix ◴[06 Apr 21 19:30 UTC] No.26716320[source]▶
> What prevents them from making the breaking changes necessary for security and features, and letting the devs of 3rd party clients successfully conform or not?

This _is_ the support headache, not a workaround for some other straw man support headache.

4. IshKebab ◴[06 Apr 21 20:41 UTC] No.26717135[source]▶
The problem is you can never make protocol breaking changes or add mandatory features. You might think "well just do it anyway and ignore people who complain about third party clients breaking" but in reality you can't ignore them. You end up with lowest common denominator. You end up with IRC basically.

Look at what happened when that Python crypto package added Rust support and broke some obscure platforms that nobody uses and were never supported. Geek outrage!

5. rodgerd ◴[06 Apr 21 22:32 UTC] No.26718212[source]▶
Then you get something analogous to the PGP problem, where you have so many options that it only takes one misunderstanding to compromise your communications.