I appreciate that this was a difficult and rare bug, but for an app that sells itself as 'secure', it feels like this isn't acceptable.
How can users be assured that this type of issue won't occur again?
How can users be assured that this type of issue won't occur again?
I dream of a world where commercial software is held to the same standards as even the lowest quality commercial hardware.
If that's too much to ask, then they really ought to be more public and forthcoming about the fact that Signal is not actually private or secure.
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.
--
If you produce a product that claims to be secure, the onus is on you to back up those claims.
Off the top my my head there are many ways to implement measures that can help to encourage security going forward.
One of the benefits of coding in the open, and ascribing to opens standards and protocols is transparency and the ability for all to interrogate the code.
Can that work? It's obviously partly also down to the culture of the product team. As another poster in this thread has highlighted, the commit messages are terse and not as helpful as they could be. Perhaps more openness re. intention would help.
Also, why are we finding out about this bug over 7 months after it was reported? Transparency regarding vulnerabilities needs to be at the forefront of the products communications if the team really are serious about security.
In terms of isolating bugs; what kind of testing is in place. TDD, functional testing, beta testing?
There are so many avenues which _could_ be discussed in relation to my initial question.
Your response, is unfortunately not providing anything helpful.
They already do all of those things. https://github.com/signalapp/Signal-Android
These actions betray trust, and trust is Signal's entire reason for being.
The situation is far more complicated than your link to the GitHub repo would indicate.
If they do, they're either incompetent, lying, or building something enormously expensive yet completely impractical for most if not all real world uses.
Part of it is cost/benefit ratio for the extra effort, part of it is market demands, part of it is lack of technology, part of it is unavoidable stuff like the halting problem.
It's also worth remembering that Signal is developed by a non-profit with a total of 36 staff members (if Wikipedia is correct). That means they have fewer developers, and even fewer Android developers.
If you think it's so easy, be your own change and do it, and then we can judge the results.
> If 36 people and $100 million in funding is not enough to make a messaging app that doesn't suck, what _is_ required and why is it more than that?
You're assuming there's a solution of a certain form to get you what you want, but maybe it's your assumption that's wrong.
I mean, there are formally verified systems that might be like what you're asking, but they're both 1) very expensive, 2) extremely feature poor.
We need to be open and honest about the possibility that our code may act in ways we don't foresee.
Not hitting a bug is not the same as not having a bug. I'd bet money that whatever system you're talking about has bugs. Plus, the system may be far simpler than you assume.
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.
They don't like forks using their servers, but it's the users who connect to their servers, not the fork publisher. Those users are permitted to connect via the TOS, which is independent from the GPL.
This is the problem in my mind. Open source in words, but not spirit.
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...
The openness or otherwise of the code has literally nothing to do with the terms of use of any service being run.
The product _is_ the network. By restricting access to the network, access to the product is also curtailed.
So what's your point? Do you think everyone should have a right to connect to their servers however they like, and the service operator can't exert any control over that?
Signal is not federated, as an explicit design decision.
The source code for the server and the client are both free software.
If this isn't true, I'd be very interested to learn more.
Winston S Churchill, 11 November 1947
I agree that in practice, a lot of people are going to use their phones for relatively sensitive conversations, and in practice, Signal remains the best choice for doing so. But there are a few real threat models where the options aren't Signal vs. SMS / Google Chat / Discord / etc., the options are Signal vs. nothing. For instance, you could be a journalist deciding whether to ask clarifying questions to a government whistleblower via Signal or meet up with them in a park. You could be an activist/demonstrator under a repressive regime deciding whether to coordinate some action this weekend via Signal or hold off on it entirely and tactically preserve your freedom. And so forth.
For those people, if (and to be clear this is a big "if," while this issue is one serious piece of evidence it is nonetheless inconclusive) Signal isn't trustworthy, it doesn't matter if Signal is the least-bad of the options.
(Also, it's not like Signal is the only e2e messenger around. There's iMessage/FaceTime, for instance. Churchill's claim was that the abstract idea of democracy was good, not that any concrete implementation like the British government was good.)
Apple suffered negative publicity from the 2014 iCloud photo leaks, even though those were "just" phishing and not a vulnerability/bug in the strict sense. Tim Cook had to give statements to the media, and in fact Apple stepped up its phishing protection by pushing two-factor authentication and notifying users about additional iCloud logins.
I don't think this is fair. Most of the solution to this is "not having them at all." That's not a good solution and still doesn't solve your problem since you can still be listened to.
> There's iMessage/FaceTime, for instance.
Which also has gotten in trouble recently with Pegasus as there was a 0-click exploit in iMessage. Honestly, that is a far more serious issue than the one here. That being said, I still trust iMessage and that the devs are doing the best that they can. I just recognize that security is difficult and will always be a cat and mouse game. There is no such thing as perfect security.
Take Reality Winner, for instance (the mechanics of that case were entirely unrelated to secure messengers, but it makes a relevant example overall). The effect on the world of her whistleblowing seems to have been minimal, and the cost to her was significant. Was it worthwhile? If she had been told the risks of the government identifying her were higher and decided not to leak anything, wouldn't that have been a better outcome?
I'm not saying there's perfect security. Vulnerable users absolutely need to be making risk assessments and deciding what they're comfortable with, and we should be clear nothing is risk-free. I'm just saying my sense of Signal's risk, in absolute terms, is higher than it was before I learned about this, and that matters to vulnerable users, not just the fact that it probably remains the lowest-risk messenger of the various options.
I agree with you overall, and the Pegasus exploit does reflect badly on Apple (and probably should reflect more badly on them than seems to be happening).
For the average person, I do not believe this is true. For the non-average person, I believe you are correct but most of these people are aware and should be constantly trained.
I'm not saying you're wrong, I'm saying that there are two different conversations to be had and we need to know which one we're having. To me it looks like Signal is about as good as you get without loads of complication and for what it is meant to do.
> he Pegasus exploit does reflect badly on Apple
And same with this on Signal. I do believe we should hold these companies to high standards. But the point I'm trying to make is that these also aren't reasons to abandon the platforms completely (as many users are suggesting here). That's throwing the baby out with the bathwater.
It's a little weird that Signal is both the "baseline security that everyone should have" product (a la HTTPS or WPA2) and the "you are literally hiding from the government" product. Of course, the target market for the latter, when you are not another government yourself, is by definition mostly illegal activity (whether or not the laws are justifiable), so it makes sense that there isn't a good product just for that.
In this particular case, it also complicates things that people who are literally hiding from the government also have normal ordinary conversations with lots of people, and it helps things for those ordinary conversations to happen on Signal, but this bug is particularly bad if you do that.
(I'm also not really sure where, say, people buying recreational drugs fit on the "average"/"non-average" axis. Is it a reasonable precaution to not text incriminating information to your drug dealer over Signal? It feels like it shouldn't be necessary, but I can see the argument for it.)
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.
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.
I'm going to tack onto this and suggest that signal drastically slow down the pace of feature development. They don't have the same profit motivations other companies have. The messaging market, at least in its current state, is largely known. These both give Signal an advantage in that they can slow down and harden the product while baking security into their DevOps practices as a first class citizen.
Tl;dr: signal needs to slow down.