Hacker News new | past | comments | ask | show | jobs | submit login

I am telling you that "They also refuse to open source their server software." is false.



Signal typically delay releasing the server source code, so the latest version of the server is not open source. In one case it took them almost a year (no public commits between 20 April 2020 and 6 April 2021).

https://github.com/signalapp/Signal-Android/issues/11101#iss...

Among the official reasons given was staying ahead of spammers. In this instance it was also speculated that the payment function which they were building into the server was to remain secret.

https://github.com/signalapp/Signal-Android/issues/11101#iss...


[flagged]


Are you trying to subtly accuse chithanh of something? If so I would request that you do it explicitly instead of in a passive-agressive way.

Regardless, their post contained only factual statements relevant to the discussion. I noticed no entitlement.


If you call it a "whim" if I point out that the latest version of the Signal server is proprietary software most of the time then so be it.

Or maybe you are referring to the other commenters who were entitled to expect that the one critical task of a crypto messenger is ensuring the confidentiality of communication, which has been broken by this bug (and at least one similar bug before it, https://github.com/signalapp/Signal-Android/issues/7909 ).

You can both be grateful that Signal is free and at the same time call out shenanigans of its owners. Just saying.


[flagged]


What a buzz kill. If I understand you correctly we shouldn't have expectations or constructive criticism on stuff we don't directly pay money for. I think that's nonsense. Does this only apply to certain opinions?

You are not paying money for Signal. But by using it, and getting others to use it, you are definitely improving their position on the market by helping them become a monopoly. Money isn't everything.


> What a buzz kill. If I understand you correctly we shouldn't have expectations or constructive criticism on stuff we don't directly pay money for. I think that's nonsense. Does this only apply to certain opinions?

You can have constructive criticisms, but they have to actually be reasonable and constructive. It's not reasonable or constructive to expect their software to never have bugs (i.e. be outraged when they have one); to rag on them because they didn't fix some bug more quickly than they may have been able to; to throw around labels like "proprietary" just because they don't release something on your schedule; to be bitter that their vision is not your vision (e.g. they won't implement some client or server feature you want), etc. All of that is in this thread.

Signal, for whatever reason, seems to attract a lot of entitled complaints like the ones I enumerated. I don't know exactly why, but it probably involves some combination of contrarianism, being in popular software category, and people who want to feel better for having picked a different team.

Signal isn't perfect software for me: I really wish they had an unencrypted message export feature, for instance. But I understand that doesn't fit into their vision, and instead of bitching about it, I just have it on my todo list to write my own (and have done some preliminary work on it).

> You are not paying money for Signal. But by using it, and getting others to use it, you are definitely improving their position on the market by helping them become a monopoly. Money isn't everything.

What now? Signal is nowhere near being monopoly, and even if they were, they're a non-profit, which makes the idea far less threatening.


> It's not reasonable or constructive to expect their software to never have bugs

I think nobody demanded anything of that sort, that is just a strawman. What was actually demanded is that priority of such bugs be raised, and perhaps users be adequately warned about known defects that may compromise the confidentiality of their messages.

That Signal developers didn't have an idea what was going on for 6 months? And then it turned out to be similar to that other stale/invalid database bug where messages were sent to unintended recipients? Back then fixing only the bug at hand but not taking steps to ensure that the type of bug (wrongly matching expired message IDs to existing messages) won't happen again? Doesn't paint them in the best light.

> to throw around labels like "proprietary" just because they don't release something on your schedule

I throw around the label "proprietary" because software which doesn't come with source code is in fact, proprietary. If Signal pushes new server code to production and keep its source to themselves, calling that still "open source" requires serious mental gymnastics.

> Signal, for whatever reason, seems to attract a lot of entitled complaints like the ones I enumerated.

No, besides your strawman the other commenters were all reasonable and constructive.


> I throw around the label "proprietary" because software which doesn't come with source code is in fact, proprietary. If Signal pushes new server code to production and keep its source to themselves, calling that still "open source" requires serious mental gymnastics.

It comes with source code, just not on your time-frame. That's still open source.

And if that's unacceptable to you, just use something else.

>> Signal, for whatever reason, seems to attract a lot of entitled complaints like the ones I enumerated.

> No, besides your strawman the other commenters were all reasonable and constructive.

We're going to have to agree to disagree there.

But if you want to (for instance) implement a plan so we can be "assured that this type of issue won't occur again" in Signal (https://news.ycombinator.com/item?id=27951759), be my guest. Or maybe you could develop a fork of it and show us your vision for it (including a source release schedule that's satisfying to you, a federated protocol, and all the the other demands in ITT).


> We're going to have to agree to disagree there.

Everyone can of course have their own opinions. But they cannot have their own facts, a discussion does not work that way.

Whether one considers some statement as entitled, that is an opinion and we can disagree about this.

But whether a program is open source or not is a fact. It doesn't matter if the source code is going to be released a day or a year after the Signal server has been pushed into production, at that very moment the program is not open source. Your comment about my time-frame is irrelevant. In the github issue 11101 link I posted above is Moxie admitting to running versions of the server that are ahead of the public git repository. These are factually closed source, and you continuing to argue against that fact doesn't reflect well on you, nor the ability to have serious discussions with you.


To be pedantic, only the ones that posses the binary need the source code for something to be open source. Since they did not publish the binary and since they have the source code we could say that it is actually open source software.


No, you are utterly incorrect.

If you produce a product that people depend on — and through which, you either intentionally or inadvertently cause damage to your user base — they have every reason to be upset.

If the product is open source, the user base luckily has the option to fix the problem.

This isn't true with Signal's model.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: