3 ms·

> 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.

> 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.

lwhi 5y ago
I disagree. If that really is the choice, they should drop the secure moniker without further debate. -- 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.
- asdfasgasdgasdg 5y ago
  > 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. They already do all of those things. https://github.com/signalapp/Signal-Android https://github.com/signalapp/Signal-Android
  - hellcow 5y ago
    In word but not in spirit. They stopped updating their repo for an entire year while integrating a crypto shitcoin in secret. These actions betray trust, and trust is Signal's entire reason for being.
  - lwhi 5y ago
    You need to reread my post. The situation is far more complicated than your link to the GitHub repo would indicate.
stathibus 5y ago
Yes, they can.
- tablespoon 5y ago
  > Yes, they can. If they do, they're either incompetent, lying, or building something enormously expensive yet completely impractical for most if not all real world uses.
  - stathibus 5y ago
    I don't understand this attitude. Where did we go wrong as a discipline where making products that actually work is such an outlandish proposition? No other consumer product industry would talk like this.
    - tablespoon 5y ago
      > I don't understand this attitude. Where did we go wrong as a discipline where making products that actually work is such an outlandish proposition? No other consumer product industry would talk like this. 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.
      - stathibus 5y ago
        This is a messaging app we're talking about here. There's nothing outrageously difficult or complex that hasn't already been done 25 years ago. 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?
        tablespoon 5y ago
        > This is a messaging app we're talking about here. There's nothing outrageously difficult or complex that hasn't already been done 25 years ago. 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.

lwhi 5y ago

I disagree. If that really is the choice, they should drop the secure moniker without further debate. -- 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.

asdfasgasdgasdg 5y ago
> 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. They already do all of those things. https://github.com/signalapp/Signal-Android https://github.com/signalapp/Signal-Android
- hellcow 5y ago
  In word but not in spirit. They stopped updating their repo for an entire year while integrating a crypto shitcoin in secret. These actions betray trust, and trust is Signal's entire reason for being.
- lwhi 5y ago
  You need to reread my post. The situation is far more complicated than your link to the GitHub repo would indicate.

stathibus 5y ago

Yes, they can.

tablespoon 5y ago
> Yes, they can. If they do, they're either incompetent, lying, or building something enormously expensive yet completely impractical for most if not all real world uses.
- stathibus 5y ago
  I don't understand this attitude. Where did we go wrong as a discipline where making products that actually work is such an outlandish proposition? No other consumer product industry would talk like this.
  - tablespoon 5y ago
    > I don't understand this attitude. Where did we go wrong as a discipline where making products that actually work is such an outlandish proposition? No other consumer product industry would talk like this. 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.
    - stathibus 5y ago
      This is a messaging app we're talking about here. There's nothing outrageously difficult or complex that hasn't already been done 25 years ago. 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?
      - tablespoon 5y ago
        > This is a messaging app we're talking about here. There's nothing outrageously difficult or complex that hasn't already been done 25 years ago. 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.