Hacker News Reader

Comment by MrAwesome | Hacker News Reader

Several years ago, when I worked at FB, I ran into a similar bug on an early internal version of a Messenger rewrite. Sent pictures to one chat, showed up in another.

My bug report on it kicked off an absolute maelstrom of dev activity and investigation. High level engineers showed up in the comments. Lots of immediate followup. The severity was clearly understood and resolving it was clearly prioritized.

I exclusively use Signal now, but the discrepancy between what I see here and what I saw there is pretty disheartening. This kind of bug is not only a massive privacy risk, but it also massively erodes user confidence and trust.

View on HN

They've just posted an update saying that the issue was fixed on July 21. It's certainly good that it's fixed...

But that's still over 7 months before it was fixed, including a 2 month period where people were still bumping the issue asking for help with no response from maintainers (afterwards, the issue went quiet until ~2 weeks ago). And there was at least one other issue on the same problem a few months later that received no response [1].

I understand the team is probably understaffed given the vast number of open issues (1300+) they have, many with no response, and I can sympathize with the challenges of being a small team developing an app used by millions, but they probably need to figure out a better way to triage...

[1] https://github.com/signalapp/Signal-Android/issues/11137

It was fixed a long time and only closed recently, see the message from the dev.

No, the dev writes on GitHub that "this issue was fixed in 5.17 (which hit 100% production on 7/21)". Releases show 5.17.0 was released on July 15. They've also linked the commits that fix the bug - the fixes were committed 10 days ago.

I don't think Signal has many devs[0] and if you look at the contributors[1] you can see that Grayson is pretty much the only dev for the Android app. So seeing a second dev get involved is probably them freaking out.

[0] Personally I believe this is a big bump in the road for Signal and is why a lot of people are frustrated. About promises about things like usernames (it is no longer early 2021), channels, and everything else. A few devs can only do so much. A dozen (maybe 2 dozen?) devs can still only do so much. How do you compete with other platforms like Telegram that has hundreds of employees or WhatsApp with far more than that?

[1] https://github.com/signalapp/Signal-Android/graphs/contribut...

Bug report is eight months old now. I don't think they're freaking out much.

But the issue is fixed. Forgetting to close a bug report is different than not fixing the bug

True, but the issue was fixed in 5.17, which was released only 10 days ago [1]. For an issue opened December last year, that's still quite a lot of time before a fix could be found.

[1] https://github.com/signalapp/Signal-Android/commit/a47448b6c...

Try fixing a rare bug quicker without constant user metrics.

Yes, indeed.

This kind of bug is an argument for having metrics.

I'm not convinced. The bug is rare and requires a specific set of circumstances that not many people are going to perform. That is not an argument to collect metrics, or in other words, change the entire paradigm of Signal (no collection of Metadata). It does propose an argument for more audits, more eyes, and more care. But we do not expect Signal to be perfect, as no software is. Systematic failure, on the other hand, creates worry about Signal. But not individual.

> I'm not convinced. The bug is rare and requires a specific set of circumstances that not many people are going to perform.

I don't think you would say the exact same thing if this happened to closed-source apps like WhatsApp or Discord and open-source apps like Telegram or Element. All of these apps have funding behind them and lots of resources to urgently address security issues when reported or discovered.

The same goes for Signal and they knew about this issue and left this open and unfixed for months. They have $60M in funding, fully open-source, full time engineers working on it and the priority was a secret cryptocurrency project over a critical security issue.

No matter how 'rare' the bug was is pointless. There is no excuse for not prioritising for critical security issues and leaving them unfixed for months as these issues risk ruining their main selling point on privacy and security.

> It does propose an argument for more audits, more eyes, and more care.

Yet despite having a string of audits, it seems the priority for Signal was 'cryptocurrencies' last year and creating a new coin to be listed on an exchange for that purpose, instead of fixing this 7 month old critical issue that they knew about.

> I don't think you would say the exact same thing if this happened to closed-source apps like WhatsApp or Discord

You're right. Because I judge a project backed by a company worth hundreds of billions of dollars and with hundreds of developers differently than I judge a company with a few tens of millions and only a dozen developers. I'm not sure why any sane person would judge these with the same metric. 15 devs just can't do what 1500 can. I'm not sure why you think differently.

> Because I judge a project backed by a company worth hundreds of billions of dollars and with hundreds of developers differently than I judge a company with a few tens of millions and only a dozen developers.

Any project that can at least afford a string of external audits and proudly advertises on multiple claims of high quality security and privacy should be held to very high standards, especially if they are serious projects in security and privacy and are not toy or pet projects.

Hence this, I would expect all Signal engineers to be the best in their field and qualified in both of these standards to justify the compensation price and uphold these claims for Signal. The same goes for any serious secure messaging platform prioritising security and privacy.

The harsh reality is that serious projects and competitors with bold claims of security and privacy all get treated the same. No exceptions or passes. Otherwise it can't be considered a serious project or even recommended to users if they don't prioritise and fix critical issues urgently.

> I'm not sure why any sane person would judge these with the same metric.

So you're telling me that Telegram or Element are able to prioritise urgent and critical security issues much better than Signal could? Signal is a serious messaging app going with its bold claims of high quality security and privacy isn't it?

> So you're telling me that Telegram or Element are able to prioritise urgent and critical security issues much better than Signal could?

No, I'd say it is about the same actually. Telegram has a lot of hacks but HN doesn't throw a fit. Lot more serious ones too. Signal never had an issue with leaking someone's physical location to any user (read: "not a rare set of circumstances needed to reproduce"). Besides, Telegram still isn't e2e by default, doesn't have e2e groups, and has no security audits. I'm not sure why this is in the same category as Signal. As for Matrix, well it only recently enabled e2e. But the project is very small. Just because you don't know of a bug doesn't mean one doesn't exist. There's an old saying: "There's two types of software. Those with bugs and those that nobody uses." (read: "all software has bugs")

> Telegram has a lot of hacks but HN doesn't throw a fit.

It had the attention of HN. They seem to care about both Telegram and Signal's flaws. Just like you highlighting the 'security issues' in Telegram, there is no escape of highlighting Signal's 'security issues' and security researchers will do exactly the same. Once again, there are no exceptions.

> Besides, Telegram still isn't e2e by default, doesn't have e2e groups, and has no security audits. I'm not sure why this is in the same category as Signal.

I expect better from a 'secure alternative' that claims to be focusing on 'privacy and security' and that also proudly shows its list of security audits. Despite all of that, they introduce their own cryptocurrency coin just to get it listed on an exchange and used in Signal, Similar to Telegram's own cryptocurrency venture which failed. [0] Combine that with the security issues in this post which one of them taking half a year to fix and still using a phone number to login, it is no different to Telegram. They still haven't even fixed this serious security issue either. [1]

The worst part of all of this is their prioritisation on addressing these issues and went in favour of creating a cryptocurrency coin just like Telegram, which most likely explains the 7 months to address that security issue. At this point, their claim of upholding privacy and security is already damaged by all of the above.

[0] https://www.theverge.com/2018/5/2/17312046/telegram-initial-...

[1] https://github.com/signalapp/Signal-Android/issues/10247#iss...

I mean, they invested a year into covert development of a crypto wallet inside Signal. Maybe that time could have been spent better.

From the commits I only really saw Moxie adding this and he hasn't been doing as much dev work in the last few years. So I don't feel that this took much away. It's hard to tell if it is a good move or not since Telegram and WA are both adding payments to their platforms and there is a need for feature parity. But regardless, MOB probably wasn't a good fit and we've seen no update since.

My complaint is more than Signal moves far too slow. I'm not saying to move fast and break things, that's far from what I want. But I am saying maybe add a few more devs.

> But I am saying maybe add a few more devs.

Absolutely, then such an important issue probably wouldn't stay open for this long.

No, Signal does not get to play the limited resources card when they so firmly discourage 3rd parties from working on their project.

Could you explain what Signal is doing to discourage contributions?

By not allowing 3rd parties apps to coexist with official signal app. (Using same servers)

Signal placing restrictions on who can use their service has nothing to do with whether or not people can contribute to the codebase.

It does. There is less incentive to work on a Signal client fork if it can't be used to interoperate with the Signal service.

That's a bit like saying there's less incentive to work on (for example) Elasticsearch, because you can't deploy your fork on Elastic Co's official managed service. It's nonsense.

There's a difference here between Elasticsearch and Signal, namely that that network effect is a very important factor with messaging apps.

No, contrary to common belief, coordinating with multiple client projects to release features simultaneously etc, is not easier. The number of meetings does not drop, the quality will not improve if you now have to check that multiple clients are safe. You won't magically get more eyes on your code, when people are working on their code, not yours. And at that point you now have to deal with people who think they have as much say as you have because their fork is "equally important". And trying to explain to a non-cryptographer hobbyist why some change needs to be done, or why some feature can/should not be implemented, is not speeding things up.

Nor when they've received millions in grant money.

Not true

If this is the case, then we should just say:

Signal is not secure because they have limited resource and cannot invest in an area with Security adequately.

Or perhaps we drop the pretence of anything being absolute ('secure' vs 'not secure') and have a more honest discussion about the different threats and where different products do better or worse? I'm sure Whatsapp is much better in being able to resource their security measures, yet being owned by Facebook, and being closed-source diminishes their security in other ways.

I personally trust whatsapp, great product

This happens to me all the time in Messenger. Just locally though. Like if I sent an image and delete it from the phone, the app shows some other random image instead.

The bug seems to reuse images already present on your device, not send new images to other users.

The older software probably spoke xmpp which meant people could just leave when it misbehaved. Signal has been against this from the beginning, it's against the ToS and the owner has asked devs of alternative clients to stop developing them.

No "apps" are ever good.

Reply on news.ycombinator.com