Hi there, Signal-Android developer here. I updated the issue to reflect this, but this bug has been fixed. I was tracking it on a separate issue, and had forgotten to close this one.
We do, in fact, take issues like this very seriously. This bug was extraordinarily rare, and because we have no metrics/remote log collection, there was an initial period where we had to spend time adding logging and collecting user-submitted logs to try to track it down. As soon as we were able to pick up a scent, it was all we worked on, and we were able to get a fix out very quickly.
> This bug was extraordinarily rare, and because we have no metrics/remote log collection, there was an initial period where we had to spend time adding logging and collecting user-submitted logs to try to track it down.
Without telemetry, can you actually back up the claim that this issue was extremely rare?
Some details on how this assumption was made would be nice, but I think it's pretty obvious that any developer involved in a project can make a reasonable assumption of how rare a bug is depending on the technical details on what is required for the bug to happen. For example, if we say for the sake of argument that a hypothetical bug requires you to have more than ten contacts of the exact same name and these also need to share the same country and area code, one can make the assumption this use case is very rare without knowing the exact number of users that this applies to, just based on common sense regarding how the application is normally used.
edit: The linked github issue says:
> The TL;DR is that if someone had conversation trimming on, it could create a rare situation where a database ID was re-used in a way that could result in this behavior. It was very difficult to track down, with earlier phases involving getting additional logging into builds. Once we had some more information, it did in fact become our top priority, a fix was made, and we got it out as quickly and as safely as possible. The fix itself should make it so that database issues like the one that caused this bug can't happen again.
Even with telemetry, would you be able to back up the claim that that the issue was rare? All too often, people add telemetry to something in an attempt to try to find things like this, but they end up leaking things elsewhere and not accounting for them. Bad statistics are more dangerous than no statistics, and all that.
Can you provide a link to the commit that fixes it?
Shouldn't there have been an announcement to inform users what has been leaked and under which circumstances?
How can user A send an image to user B that neither of them took? Isn't everything end-2-end encrypted? Then how can unencrypted data from user C end up on the device of user B?
The former updates how recipients (or really threads, I suppose) are merged (the issue occurred when trimming threads) and the latter changes the way how thread ids are generated (now automatically incremented). Together they should prevent unrelated recipients (threads) from being merged.
From the explanation [0], this looks like the commit [1].
I do have to say though, the commit messages are very barren and barely any reference an issue directly. My guess is that they develop on private branches with an internal issue tracker and decide not to reference issues as that would be confusing. It would help a bunch if they referenced the public issues and made it clear which issues they're working on. They don't seem to use Github Projects [2].
All in all, the communication / transparency of the project is lacking - even though I'm glad they're providing something usable. Hopefully Matrix will be able to provide something as easily usable as well.
What does it mean for it to "not be acceptable?" Accepting or not accepting the bug is not an option on the table. It happened. The options you have open to you are to use or not use the freely provided software, or donate or not donate to the foundation providing it. Users cannot be assured that future bugs will not occur. That is an assurance that is not available with most consumer software, and certainly not with software delivered for free by a not-for-profit.
> How can users be assured that this type of issue won't occur again?
By not using software.
And I mean software in general, not this software in particular. You're basically asking for assurance that they won't have any more bugs, but no one can actually provide such an assurance in the real world.
Users are not entitled to a guarantee that this will never happen again, because Signal is free and open source software provided free of charge and without warranty.
The Android app is GPL licensed. The license clearly states:
> For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software.
If you feel let down by open source software, you have many options available to you to make that software more reliable.
‘Many forms of secure messaging systems have been tried, and will be tried in this world of sin and woe. No one pretends that Signal is perfect or all-wise. Indeed it has been said that Signal is the worst messaging except for all those other forms that have been developed from time to time…’
Probably by installing some hardened memory on your phone to prevent cosmic bitflips or the such.
Unless you are going to go to NASA lengths of hardware reliability, you can't really hope much for the software that has to deal with the issues of... how many different android phones are there?
From the explanation of the bug on github it seems to me like this is a client-side database issue and nothing was actually leaked.
Database ids were reused so random images that were previously received were displayed in newly received messages.
Is this correct? If it is then it's probably worth mentioning.
My understanding is that the database issue caused your client to send pictures A, B and C to person X, when you were trying to send picture C to person X (where A and B are pictures that were previously sent to someone else).
Question: do you guys have a software or product security team? I suggested the roles to workwithus @ Signal on 5/18/2018 and have never seen a public follow-up in the form of career postings.
Asking because such a team may be best equipped to serve as both the support and internal accountability function for such while minimizing business conflicts when engineering is facing challenges integrating security into DevOps natively.
At this point, it's probably warranted; the last time I asked was when Signal was seeing its spree of XSS defects in the desktop app. If Signal has one, a simple "yes" will suffice, but without a reply, I have to assume not.
Given Signal's raison d'être, I would think nearly their entire team is the "security team".
I'm not being entirely facetious either - security is the USP of the product, I really would expect security knowledge and a feeling of responsibility for the product's security to be pervasive throughout the whole team.
I find this quite concerning and am really wondering if there are any privacy advantages to Signal if these things happen.
Could you say something on:
1. Have any defend in depth measures been applied in the Android and other clients to make sure this issue does not happen again? E.g., an additional check when sending/encrypting a message to make sure it is absolutely meant for the person it is being send to?
2. Why did it take 8 months to fix this if some users could reproduce it consistently?
One thing I wonder is: how could this happen at all? Considering the E2E Encryption in place, I would expect the incorrect recipient simply wouldn't be able to decode the image considering they never have exchanged keys with the sender?
Not a signal developer, but I would imagine it would be fairly simple that the same bug also encrypted the message with the eventual receiver’s key (as opposed to the intended receiver’s key). Resulting in a message which the eventual receiver could decrypt but not the intended receiver.
> I remember before Jellybean Android, sending SMS would break up my message and send it to multiple people, and the Android alarm clock would drift by hours.
So how could this happen? Because software is hard.
Not mentioning in this comment when the issue was fixed--two weeks ago in the code and days ago in production--is extremely dishonest. I have been contacted by literally everyone I have sent this to saying something akin to "dude says it was fixed quickly but they just didn't close the issue" despite my message with the link saying (exactly) "<- issue opened on december 3rd and only fixed last week", making me have to again point out "closed today, but only fixed in production last week" (fixed in the code two weeks ago, but that doesn't matter much)... at which point they are forced to do a double take and suddenly care.
I have worked on high-impact open source software--the iOS jailbreak ecosystem, writing some of the most core software for it, such as the mechanisms which support runtime code modification and which install the userland--with a much smaller team than Signal, and when you run into serious issues you need to disclose them, and you need to be super honest about the post-mortem. You shouldn't just kind of sweep the issue under the rug in the hope you can fix it before someone notices or it affects enough people to become a PR problem.
(On what is maybe a side note of my thesis here for a moment, but for completeness on the related issue of why I am so dissatisfied with these PR-like responses: you say it is "extremely rare", but not so rare that tons of people aren't reporting the issue happening at least to people they know; this is being used here as an excuse for why it was hard to find and fix, but is then being taken by some as "oh it was also unimportant": issues have to be additionally weighted by their impact, and this bug was clearly critical.)
The equivalent of this sort of thing I have run into is "there is like a one in a hundred thousand chance that you will experience catastrophic data loss from using my software", and I took those issues very seriously, as when you have tens of millions of users that's still a non-negligible number of people in the absolute: I considered every single person who would lose something like their camera roll on their phone to be a crushing defeat that I should internalize and take super personally, as I know the feeling of loss of important information and have enough empathy to assign it to my users.
(Hell: one time I actually hired someone to spend a bunch of time going back and building a tool that would take videos recorded by Cycorder (my video recorder for the original iPhone) that had been damaged by a bug I found in one version of the app that had led to some videos being misrecorded and lost--in a way that I think was even more random than "merely" if the power ran out while recording?--and repair them, to send to the almost no people who had taken videos of their family they realized only after an event weren't playable. This is different, of course, as this was after the fact, but a demonstration of the empathy I feel developers should have for their users: if I can do it with the tiny resources I had... anyone can do it.)
When you find reports of such an issue, you carefully track every single one of them down... but you also have a small time box, past which you need to disclose the issue to everyone: you put a large message on the download link of the product or update the homepage of the app to explain your status finding the issue and asking for help with leads, as it is important that people know that if this could affect them they can mitigate... maybe they don't send photos to anyone they couldn't afford sending to someone wrong, they use a different tool, or they switch to running Signal on iOS.
This doesn't seem to have happened? Hell: if anything, this issue seems to have been sufficiently boring to you that you didn't even close it the second you fixed it or keep people abreast in the issue on GitHub of when they could expect the fix you committed to roll into production. This is both an unacceptable communication style and level of empathy for a product trying to be as important as Signal (though sadly not terribly surprising on either count... it is this same lack of empathy that springs up when Signal has database corruption issues or lacks export tooling or spends its time undermining the wrong opponents or throws in a cryptocurrency--which I should want to celebrate as I am in that space!!--built on DRM tooling and without any warning or thought as to what it means for the one open source secure messenger... sigh).
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.
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...
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?
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 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.
> [..] his Signal randomly sending images to me that he didn't intend to, even without initiating the addition of any attachments on the GUI... he even sees one of my messages displayed on his side with a random image attached to it, as if i have sent that image to him, even though that image is not even present on my phone.
Though it looks like the issue was finally closed minutes ago:
> Hi there, sorry, this issue was fixed in 5.17 (which hit 100% production on 7/21). There was another issue tracking this and it looks like I forgot to close this one.
Still, that's a lot of time for such a bug to exist!
> I've also recently had a probably unrelated issue where my mic was still audible to the other party after I hung up the call.
That one there is a cataclysmic security land mine. Absolutely unacceptable.
That was the last straw after [0]. I don't think I can recommend Signal at this time.
To Downvoters: So these bugs are all fine then? They are not security issues then? Not only having images being sent to the wrong contacts but also having the microphone still on after ending the call and being audible to the other party? That's fine right?
If this happened on any other messaging app, I would expect a massive outcry and urgency to fix these critical issues.
Yes. Signal's only selling point is privacy. Both of these bugs are huge privacy breaches that kill its value proposition.
Which type of privacy breach is more likely to have tangible and direct negative effects on an average user's life - a nation state storing their communications in a database, Facebook graphing their contacts and using them for friend recommendations, or their friends/family/boss/acquaintances being sent random private photos from their phone and audio of private conversations they have in their home, without them knowing?
One of the main worries with companies having access to your unencrypted private data is that no matter how careful they are with it, it can still end up in the wrong hands. Signal is directly sending your data into the wrong hands.
News: The EU Commission told its staff to start using @signalapp to chat to friends and contacts. The move is part of an effort to fix the holes in EU cybersecurity. Story (for Pros for now) https://twitter.com/bendrath/status/1230455295018766337
Why on Earth are people downvoting you? This is an absolute dealbreaker for any messaging app, much less one whose raison d'etre is privacy and secure messaging.
Stopped doing calls on Signal after my Android contacts started telling me that they see active calls minutes after I successfully hung up from my side (iOS). Not to mention the countless UX bugs.
I’m back on WhatsApp and not telling anyone anymore to move to Signal or any app whatsoever. I’m done.
While I suppose the protocol is not at fault and it's a UI and client bug it's still a huge problem.
Just today I was thinking ”it's been weeks since they moved the GIF button to a different place but there's still the old button at the old place and when you click on it there's a pop-up "wrong, the button is somewhere else now"”.
Why even keep the old button in the old place ?
And it led me to thinking "what else could be wrong/buggy in the UI and the UX that is not obvious to them ?".
So I should have written: And it led me to thinking "what else could be wrong/buggy in the UI and the UX that they haven't had time to catch and fix yet ?".
> Just today I was thinking ”it's been weeks since they moved the GIF button to a different place but there's still the old button at the old place and when you click on it there's a pop-up "wrong, the button is somewhere else now"”.
That's actually a UX FEATURE. Google Maps did exactly the same thing when they reorganized and move the toggle between maps/satelite/traffic layers.
The answer is pretty straightforward: Users get used to a certain UX. If you do a reorganization (to introduce new features, to improve performance, whatever), and move a button, a meaningful percentage of your users won't read the blog post, the release notes, or hunt for a new "Intuitive" location for the feature. They'll just assume you removed the feature and either panic or get mad.
Leaving the old button in the old place is actually kind of a clever way to "Deprecate" a UX feature.
Yep, this was the intent. It's a relatively common pattern. We kept it that way for a few releases so people could see it, and we removed the button in the latest release.
I agree. Am an app dev myself and the weird maps relayout of gestures got me dozens of times... Can't imagine how condused my mum or some not phone-savy person is.
It has certainly not trained me to reach for the new way since it was introduced considering I strangely still reach for the usual and visible old way every time despite being treated with "lol, no". But I may be the exception.
Yeah, I actually like this UI feature. I would have been very frustrated if they had just changed it over on Google Maps. I use Timeline all the time and it was important to me.
This underscores why it’s important to allow third party clients to connect. When only the first-party client is allowed, the failings of its UI drag down the core, too — it doesn’t matter how good the core is if it’s permanently mated to a half-baked UI.
With this party clients, you don’t avoid this. The failings of a third party client will still reflect on the whole of the core product as well. Articles would still talk about a bug like this breathing a Signal issue, even if limited to a third party app.
Additionally, I find it quite a stretch to call the app “half-baked”. I think it’s pretty great.
And when third parties can connect, the protocol can't evolve because every change becomes "good to simplement" but it takes an enormous amount of time, resources And influence to change to "mandatory to implement". As always it's a delicate balance between security And ease of use, and Signal has always been up front in favoring the former.
This is the same app that only 6 months ago had an outage lasting more than a full day[0] - an outage that to my knowledge remains unexplained. The protocol is one thing but these clowns are obviously not careful or reliable engineers.
Have you ever experienced millions of new users starting on your service in the space of a few days?
Predicting the future is hard.
Calling a team "clowns" because they didn't make the right guesses when they did capacity planning and had a day with downtime as a result of meteoric growth seems unfair to me.
I love Signal and have advocated for its use. But I have to say that this issue is trust-breaking.
I lovingly forgive the occasional bug or unpolished feature and I understand that the team behind Signal are human and that programming is hard. But sending messages to the wrong people is very high on the list of things a messenger should never ever ever do!
Having an issue like this remain open for 7.5 months hints at a systemic issue, which is probably be related to Signal being underfunded/understaffed. But regardless of the reason and of everyone's good intentions, the fact remains that similar issues can and probably will happen again, and may again take months to fix.
Bug reported 2020-12-04, fixed release tagged 2021-07-15 (if I'm identifying the commit correctly, same day the fix is merged, which one would hope for a high-priority bug like that). That's technically 7.3 months, not 7.5, true, but ...
Signal has been adding lots of silly social media like features lately, not surprising that they are messing up the core value prop. I’m shopping for a new encrypted messenger. They used to say every program expands in scope until it can read email, now every app expands until you can add Snapchat filters to your selfies.
Matrix is a solid replacement. Element isn't as easy to use but it's coming along. Quality-of-life features normal users expect like stickers, gifs, etc. are woefully lacking, but the important stuff (y'know, actual messaging) is solid.
The most important thing to me is if Element screws up like Signal and starts pushing a shitcoin, I can swap clients without affecting my network.
It’s not enough for signal to work for tech people. You have to be able to convince your family and friends to use it, it’s a network effects problem. They are adding features so that ordinary people can have private communications
How does delta deal with new chats, fallback and other standard email client stuff? Does it allow mixing encrypted and unencrypted messages? What happens if I use an alternative mail client, will I still be able to read email from people after the project dies and the clients stop working?
I don't think people will appreciate it when I suddenly start using email as a standard communications method, but it's worth a shot. The client looks like a copy of Telegram (a good thing, in my opinion) and everyone already has email, so I'm willing to give it a shot I guess. I'm currently on the Matrix camp but it's not like that's a protocol many non techs use in the real world.
I'm just wary of using email for this because of all of the previous failures to secure email, like PGP, S/MIME and variations thereof.
I really like the idea of delta chat, except that I cannot bring myself to allow it access to my full imap mailbox. And most providers do not offer a way to scope access to only selected folders.
It's necessary if you want to attract the mainstream users, who could not care less for e2e security but values stickers, filters and stories above all else.
I hate the new ability to add emoji responses to message chat bubbles. It has turned my conversations (especially group ones) into a Facebook like experience where everyone expects a cry face emoji or heart on everything they say. It gives me that same feeling of dread I used to get when I had a Facebook. I just want to send and receive text messages, not be engaged constantly to my phone.
Cool, my contacts can keep using their gmail account and leak all communication metadata to Google without me having any say on that if I want to talk to them. Where can I sign up?
I used it and found it excellent, fully featured (chat/voice/video), use phone or email as identifier, and supported on all devices (iOS, Android, Mac, Win, Linux).
I don't understand why it didn't take off - seems like a modern version of Betamax/VHS to me.
Several years ago I had this same issue occur in Facebook Messenger. I was using a pretty slow outdated device even for the time. I went to take a picture to send with the in-app camera. I actually pressed send before the picture rendered on my screen and somehow what was sent was not the picture I took, but a picture of some man's forehead who neither of us had ever seen before. It seemed like a pretty huge bug that could be a serious problem if anyone could reliably recreate it, which I could not. I went about trying to report it but ran into so many problems and broken links searching for Facebook's bug reporting that I gave up. Here's hoping it's been fixed, though I haven't used Messenger for at least a few years now anyway.
Signal is becoming a joke that we should reconsider using, and now has dangerous bugs that is at the edge of compromising people's privacy.
Has this app/service really been audited properly?
We now need to consider serious alternatives that we should get behind like Element [0] or Session [1] but I am open to user friendly alternatives other than Signal (at worst even Quill [2] or Delta Chat [3]).
And yet there are serious bugs like this that slip through the net, a simple benchmark of any chat app should not be showing other people's messages like what Signal is doing.
I would expect that an app that has repetitive audits would have resulted in this bug being fixed already.
How is Quill Chat that's proprietary and not E2EE a serious alternative?
Element's UX is behind Signal but at least the encryption is E2EE by default.
Session is a Signal fork with bad metadata protection: There's 60 entities owning Loki nodes, and top three players own 80% of nodes.
Delta chat leaks metadata to email providers, and PGP has no forward secrecy or deniability.
Element is the only one that's even remotely fixing the issue.
The issue here was client side, and no architectural design, not even hardware system can prevent the "wrong contact receives plaintext message" vulnerability categorically.
The fix is now in place, and I'll eat my shorts if they don't have a unit test in place to detect reintroduction of this issue.
Readit News
We do, in fact, take issues like this very seriously. This bug was extraordinarily rare, and because we have no metrics/remote log collection, there was an initial period where we had to spend time adding logging and collecting user-submitted logs to try to track it down. As soon as we were able to pick up a scent, it was all we worked on, and we were able to get a fix out very quickly.
Without telemetry, can you actually back up the claim that this issue was extremely rare?
edit: The linked github issue says:
> The TL;DR is that if someone had conversation trimming on, it could create a rare situation where a database ID was re-used in a way that could result in this behavior. It was very difficult to track down, with earlier phases involving getting additional logging into builds. Once we had some more information, it did in fact become our top priority, a fix was made, and we got it out as quickly and as safely as possible. The fix itself should make it so that database issues like the one that caused this bug can't happen again.
Shouldn't there have been an announcement to inform users what has been leaked and under which circumstances?
How can user A send an image to user B that neither of them took? Isn't everything end-2-end encrypted? Then how can unencrypted data from user C end up on the device of user B?
If I understand the issue [0] correctly, these two commits should be the fix:
https://github.com/signalapp/Signal-Android/commit/e90fa05d6...
https://github.com/signalapp/Signal-Android/commit/b9657208f...
The former updates how recipients (or really threads, I suppose) are merged (the issue occurred when trimming threads) and the latter changes the way how thread ids are generated (now automatically incremented). Together they should prevent unrelated recipients (threads) from being merged.
[0]: https://github.com/signalapp/Signal-Android/issues/10247#iss...
I do have to say though, the commit messages are very barren and barely any reference an issue directly. My guess is that they develop on private branches with an internal issue tracker and decide not to reference issues as that would be confusing. It would help a bunch if they referenced the public issues and made it clear which issues they're working on. They don't seem to use Github Projects [2].
All in all, the communication / transparency of the project is lacking - even though I'm glad they're providing something usable. Hopefully Matrix will be able to provide something as easily usable as well.
[0]: https://github.com/signalapp/Signal-Android/issues/10247#iss...
[1]: https://github.com/signalapp/Signal-Android/commit/83086a5a2...
[2]: https://github.com/signalapp/Signal-Android/projects
and no PR from OP in the opensource part of the server https://github.com/signalapp/Signal-Server/pulls?q=is%3Apr+i...
How can users be assured that this type of issue won't occur again?
By not using software.
And I mean software in general, not this software in particular. You're basically asking for assurance that they won't have any more bugs, but no one can actually provide such an assurance in the real world.
The Android app is GPL licensed. The license clearly states:
> For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software.
If you feel let down by open source software, you have many options available to you to make that software more reliable.
Winston S Churchill, 11 November 1947
Unless you are going to go to NASA lengths of hardware reliability, you can't really hope much for the software that has to deal with the issues of... how many different android phones are there?
Actually, this very type of issue (sending messages to wrong recipients due to stale/invalid database entries) has occured previously.
https://github.com/signalapp/Signal-Android/issues/7909
By writing code defensively. Despite the other comments, it's possible.
The key is to be redundant: for example, off-by-one errors are very common when accessing an set of indexed items by number.
Yet you can split the set (e.g. an array) in multiple ones to make it more unlikely that you pick the wrong item (e.g. picture vs users).
You can also "tag" the outgoing image with some attributes, e.g. the recipient and a sent/not-sent flag.
You can cross-check and stop if something is inconsistent. Many other things are possible e.g. to protect from RAM bit flips.
It's not a matter of language or tooling, it's a matter of mindset.
Dead Comment
Is this correct? If it is then it's probably worth mentioning.
I'm not sure if 8 months can be categorized as fast... The issue was posted on Dec 4, 2020, and the fix (5.17) was released on July 21.
Also, sounds like quite a big issue considering that Signal is all about privacy...
"As soon as we were able to pick up a scent, it was all we worked on, and we were able to get a fix out very quickly."
Asking because such a team may be best equipped to serve as both the support and internal accountability function for such while minimizing business conflicts when engineering is facing challenges integrating security into DevOps natively.
At this point, it's probably warranted; the last time I asked was when Signal was seeing its spree of XSS defects in the desktop app. If Signal has one, a simple "yes" will suffice, but without a reply, I have to assume not.
I'm not being entirely facetious either - security is the USP of the product, I really would expect security knowledge and a feeling of responsibility for the product's security to be pervasive throughout the whole team.
Is 6 months really what Signal considers quick for a bug that leaks private data?
"As soon as we were able to pick up a scent, it was all we worked on, and we were able to get a fix out very quickly."
Could you say something on:
1. Have any defend in depth measures been applied in the Android and other clients to make sure this issue does not happen again? E.g., an additional check when sending/encrypting a message to make sure it is absolutely meant for the person it is being send to? 2. Why did it take 8 months to fix this if some users could reproduce it consistently?
> I remember before Jellybean Android, sending SMS would break up my message and send it to multiple people, and the Android alarm clock would drift by hours.
So how could this happen? Because software is hard.
I have worked on high-impact open source software--the iOS jailbreak ecosystem, writing some of the most core software for it, such as the mechanisms which support runtime code modification and which install the userland--with a much smaller team than Signal, and when you run into serious issues you need to disclose them, and you need to be super honest about the post-mortem. You shouldn't just kind of sweep the issue under the rug in the hope you can fix it before someone notices or it affects enough people to become a PR problem.
(On what is maybe a side note of my thesis here for a moment, but for completeness on the related issue of why I am so dissatisfied with these PR-like responses: you say it is "extremely rare", but not so rare that tons of people aren't reporting the issue happening at least to people they know; this is being used here as an excuse for why it was hard to find and fix, but is then being taken by some as "oh it was also unimportant": issues have to be additionally weighted by their impact, and this bug was clearly critical.)
The equivalent of this sort of thing I have run into is "there is like a one in a hundred thousand chance that you will experience catastrophic data loss from using my software", and I took those issues very seriously, as when you have tens of millions of users that's still a non-negligible number of people in the absolute: I considered every single person who would lose something like their camera roll on their phone to be a crushing defeat that I should internalize and take super personally, as I know the feeling of loss of important information and have enough empathy to assign it to my users.
(Hell: one time I actually hired someone to spend a bunch of time going back and building a tool that would take videos recorded by Cycorder (my video recorder for the original iPhone) that had been damaged by a bug I found in one version of the app that had led to some videos being misrecorded and lost--in a way that I think was even more random than "merely" if the power ran out while recording?--and repair them, to send to the almost no people who had taken videos of their family they realized only after an event weren't playable. This is different, of course, as this was after the fact, but a demonstration of the empathy I feel developers should have for their users: if I can do it with the tiny resources I had... anyone can do it.)
When you find reports of such an issue, you carefully track every single one of them down... but you also have a small time box, past which you need to disclose the issue to everyone: you put a large message on the download link of the product or update the homepage of the app to explain your status finding the issue and asking for help with leads, as it is important that people know that if this could affect them they can mitigate... maybe they don't send photos to anyone they couldn't afford sending to someone wrong, they use a different tool, or they switch to running Signal on iOS.
This doesn't seem to have happened? Hell: if anything, this issue seems to have been sufficiently boring to you that you didn't even close it the second you fixed it or keep people abreast in the issue on GitHub of when they could expect the fix you committed to roll into production. This is both an unacceptable communication style and level of empathy for a product trying to be as important as Signal (though sadly not terribly surprising on either count... it is this same lack of empathy that springs up when Signal has database corruption issues or lacks export tooling or spends its time undermining the wrong opponents or throws in a cryptocurrency--which I should want to celebrate as I am in that space!!--built on DRM tooling and without any warning or thought as to what it means for the one open source secure messenger... sigh).
Do you mind linking to that issue? Thanks!
Deleted Comment
Dead Comment
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.
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
[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...
Signal is not secure because they have limited resource and cannot invest in an area with Security adequately.
No "apps" are ever good.
https://github.com/signalapp/Signal-Android/issues/10247#iss...
Yikes.
> [..] I've also recently had a probably unrelated issue where my mic was still audible to the other party after I hung up the call.
https://github.com/signalapp/Signal-Android/issues/10247#iss...
Double yikes.
Triple yikes.
Though it looks like the issue was finally closed minutes ago:
> Hi there, sorry, this issue was fixed in 5.17 (which hit 100% production on 7/21). There was another issue tracking this and it looks like I forgot to close this one.
Still, that's a lot of time for such a bug to exist!
That one there is a cataclysmic security land mine. Absolutely unacceptable.
That was the last straw after [0]. I don't think I can recommend Signal at this time.
To Downvoters: So these bugs are all fine then? They are not security issues then? Not only having images being sent to the wrong contacts but also having the microphone still on after ending the call and being audible to the other party? That's fine right?
If this happened on any other messaging app, I would expect a massive outcry and urgency to fix these critical issues.
[0] https://news.ycombinator.com/item?id=27951076
Which type of privacy breach is more likely to have tangible and direct negative effects on an average user's life - a nation state storing their communications in a database, Facebook graphing their contacts and using them for friend recommendations, or their friends/family/boss/acquaintances being sent random private photos from their phone and audio of private conversations they have in their home, without them knowing?
One of the main worries with companies having access to your unencrypted private data is that no matter how careful they are with it, it can still end up in the wrong hands. Signal is directly sending your data into the wrong hands.
News: The EU Commission told its staff to start using @signalapp to chat to friends and contacts. The move is part of an effort to fix the holes in EU cybersecurity. Story (for Pros for now) https://twitter.com/bendrath/status/1230455295018766337
I’m back on WhatsApp and not telling anyone anymore to move to Signal or any app whatsoever. I’m done.
Unfortunately for my ubuntu 18.04 LTS and this is in no way Signal's fault (but maybe the desktop version doesn't have that bug ?):
Just today I was thinking ”it's been weeks since they moved the GIF button to a different place but there's still the old button at the old place and when you click on it there's a pop-up "wrong, the button is somewhere else now"”.
Why even keep the old button in the old place ?
And it led me to thinking "what else could be wrong/buggy in the UI and the UX that is not obvious to them ?".
edit: according to this comment https://news.ycombinator.com/item?id=27951648 there is only one dev working on the Android client ? Hats off to that person, it's incredible.
So I should have written: And it led me to thinking "what else could be wrong/buggy in the UI and the UX that they haven't had time to catch and fix yet ?".
That's actually a UX FEATURE. Google Maps did exactly the same thing when they reorganized and move the toggle between maps/satelite/traffic layers.
The answer is pretty straightforward: Users get used to a certain UX. If you do a reorganization (to introduce new features, to improve performance, whatever), and move a button, a meaningful percentage of your users won't read the blog post, the release notes, or hunt for a new "Intuitive" location for the feature. They'll just assume you removed the feature and either panic or get mad.
Leaving the old button in the old place is actually kind of a clever way to "Deprecate" a UX feature.
That would drive me demented in 5 minutes.
It underscores why open standards and protocols are essential for a more secure world.
Additionally, I find it quite a stretch to call the app “half-baked”. I think it’s pretty great.
[0] https://www.theverge.com/2021/1/17/22235707/signal-back-app-...
Predicting the future is hard.
Calling a team "clowns" because they didn't make the right guesses when they did capacity planning and had a day with downtime as a result of meteoric growth seems unfair to me.
I lovingly forgive the occasional bug or unpolished feature and I understand that the team behind Signal are human and that programming is hard. But sending messages to the wrong people is very high on the list of things a messenger should never ever ever do!
Having an issue like this remain open for 7.5 months hints at a systemic issue, which is probably be related to Signal being underfunded/understaffed. But regardless of the reason and of everyone's good intentions, the fact remains that similar issues can and probably will happen again, and may again take months to fix.
The most important thing to me is if Element screws up like Signal and starts pushing a shitcoin, I can swap clients without affecting my network.
I think Signal (in its current form and direction) is a gone case but so is Matrix.
Matrix is anyway chasing Slack not WhatsApp. I think that’s a smart move.
It used to be "just install that, you will be more secure and won't notice the difference". To "you will lose all your messages".
Decentralized / federated e2e chat, running on the Internet’s most well-known, resilient, universally supported, self-hostable infrastructure: email.
I don't think people will appreciate it when I suddenly start using email as a standard communications method, but it's worth a shot. The client looks like a copy of Telegram (a good thing, in my opinion) and everyone already has email, so I'm willing to give it a shot I guess. I'm currently on the Matrix camp but it's not like that's a protocol many non techs use in the real world.
I'm just wary of using email for this because of all of the previous failures to secure email, like PGP, S/MIME and variations thereof.
Deleted Comment
But then, I myself don't end up doing it, largely because of the network effect on Signal.
I think we need to just remember to always keep 3-5 of them open so we can have some horizontal evolution.
If this is what the masses want, give it to them. Encryption only works if people use it.
However finding connections just by numbers is really a killer feature
Still dependent on proper UI engineering, like Signal failed to do.
Citation needed.
I for one would rather they spent less time on these ‘features’.
The UX is completely unpolished and at least 5 years behind Signal.
I don't understand why it didn't take off - seems like a modern version of Betamax/VHS to me.
Has this app/service really been audited properly?
We now need to consider serious alternatives that we should get behind like Element [0] or Session [1] but I am open to user friendly alternatives other than Signal (at worst even Quill [2] or Delta Chat [3]).
[0] https://element.io
[1] https://getsession.org
[2] https://quill.chat
[3] https://delta.chat
Yes, repeatedly: https://community.signalusers.org/t/wiki-overview-of-third-p...
Edit: that said, this did make me revisit a question I asked signal via their Careers portal a long while back. Reposted here: https://news.ycombinator.com/item?id=27952315
I would expect that an app that has repetitive audits would have resulted in this bug being fixed already.
Have you not seen over at Apple App Store what they’re sucking off of your phone from your Quill app?
Could you recommend a better chat app that is user friendly enough for regular people to use that is not Signal or WhatsApp and is cross platform?
Quill are at least working on E2E, not introducing a cryptocurrency like Signal and don't require your phone number.
How is Quill Chat that's proprietary and not E2EE a serious alternative?
Element's UX is behind Signal but at least the encryption is E2EE by default.
Session is a Signal fork with bad metadata protection: There's 60 entities owning Loki nodes, and top three players own 80% of nodes.
Delta chat leaks metadata to email providers, and PGP has no forward secrecy or deniability.
Element is the only one that's even remotely fixing the issue.
The issue here was client side, and no architectural design, not even hardware system can prevent the "wrong contact receives plaintext message" vulnerability categorically.
The fix is now in place, and I'll eat my shorts if they don't have a unit test in place to detect reintroduction of this issue.
Signal leaks metadata to the signal server. Deniability is useless. Forward secrecy is cool as long as you are not using more than one device.
Deleted Comment
Deleted Comment