4 ms·

> Has this app/service really been audited properly? Yes, repeatedly: https://community.signalusers.org/t/wiki-overview-of-third-party-security-audits/13243 ht

> Has this app/service really been audited properly? Yes, repeatedly: https://community.signalusers.org/t/wiki-overview-of-third-party-security-audits/13243 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 https://news.ycombinator.com/item?id=27952315

colesantiago 5y ago
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.
- detaro 5y ago
  At least the main audits are clearly described as auditing internal components, so it's not surprising app-level errors aren't covered by them.
  - colesantiago 5y ago
    Which this bug was left open for months while users were experiencing this privacy issue. How can I recommend a chat app that does this and claim they are a privacy based app? and also does not respond to urgent bugs in this manner?
    - detaro 5y ago
      I'm not saying you should recommend Signal, just pointing out that "there are audits, why does it have such bugs" doesn't tell the entire story.
      - colesantiago 5y ago
        > just pointing out that "there are audits, why does it have such bugs" doesn't tell the entire story. So? Isn't that the point though? Having regular audits should have caught this issue? I thought this being 'open source' this would made this even easier. Which leads me to believe a team that has $60M~ in funding is unable to fix this issue in a matter of urgency. Remember this issue was open for half a year with users noticing this, no matter how you slice this, this issue does not give me any more confidence in Signal being secure.
        maqp 5y ago
        >So? Isn't that the point though? Having regular audits should have caught this issue? I thought this being 'open source' this would made this even easier. You have it the wrong way. Testing, audits, and open source are all best practices. They should be done. None of them are guarantees of security. Open source is not guarantee of finding all bugs, it's a necessity to allow anyone to look for bugs (and backdoors). Audits can not be passed. They can only be failed. Kind of like how RNG tests can not be passed, they can only be failed. Example: Use SHAKE256 to extrude any keystream on initial value 0x00. It will not be secure, but it will pass any statistical test. >this issue does not give me any more confidence in Signal being secure. No application can actively prevent a bug like this. As an author of high assurance comms system, see what I wrote under threat model: "If hardware such as computers/optocouplers user has bought is pre-compromised to the point it actively undermines the security of the user, TFC (or any other piece of software for that matter) is unable to provide security on that hardware." This also applies to software issues that actively undermine the security of the user. So the thing is, a software bug that outputs sensitive data to wrong contact, can not be absolutely prevented. You would need a friendly MITM-guard node that runs a Google-grade image recognition algorithm that detects you're trying to output a legal document to the wrong client, or a nude to not-your-SO. Again, bugs are unavoidable, what matters is the incident response, and is Signal actively trying to protect you from everyone, including themselves. Another PoV: If you punitively fire people that get caught in social engineering pentests, you're replacing a person who now has real-life experience with social engineers, with someone who may or may not have such experience. Sure, if the person fails multiple times, it's time to let them go, but Signal's reaction is indication of a good employee who takes personal responsibility in making sure it won't happen again. I'm extremely careful about what I recommend, and I have serious trouble finding a way to agree with your assessment that just because a rare bug is open 6 months is of serious concern. It wasn't being sat on for six months. But you're very keen on giving that idea. Would you care to elaborate?
    - godelski 5y ago
      The bug wasn't open for months, the dev just forgot to close it and he's in the thread.
      - detaro 5y ago
        He forgot to close it 10 days ago.
      - colesantiago 5y ago
        Where is the original issue for this, if that is the case? Otherwise I see signal developers closing duplicates [0], towards the main issue [1] which leads me to believe it was open for months. Even if the bug was fixed at 7/21 on the original thread and this main one, this issue was still open for months. [0] https://github.com/signalapp/Signal-Android/issues/11137 https://github.com/signalapp/Signal-Android/issues/11137 [1] https://github.com/signalapp/Signal-Android/issues/10247 https://github.com/signalapp/Signal-Android/issues/10247
    - maqp 5y ago
      So what ingenious method should they have deployed to prevent all programming errors beforehand, and how should they have handled it? Advice users to fall-back to non E2EE SMS? The team deployed logging as fast as they could, successfully detected the issue as soon as it happened again, and deployed fix as fast as possible. What should they have done? If you only recommend chat apps with perfect track record, you're basically recommending chat apps with internal policy of not disclosing vulnerabilities, and ones that downplay any revealed vulnerabilities.
      - hellcow 5y ago
        I don't think anyone takes issue with the fact that the mistake was made or that it was really hard to track down. Shit happens. How you handle it is everything. No communication on it and issuing no warning to their users for a critical bug that risked user privacy in a substantial way for 7 months is unacceptable for an app that calls itself secure, full stop.
soziawa 5y ago
The protocol has been reviewed plenty of times. The rest of the app has not. At least according to your list.

colesantiago 5y ago

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.

detaro 5y ago
At least the main audits are clearly described as auditing internal components, so it's not surprising app-level errors aren't covered by them.
- colesantiago 5y ago
  Which this bug was left open for months while users were experiencing this privacy issue. How can I recommend a chat app that does this and claim they are a privacy based app? and also does not respond to urgent bugs in this manner?
  - detaro 5y ago
    I'm not saying you should recommend Signal, just pointing out that "there are audits, why does it have such bugs" doesn't tell the entire story.
    - colesantiago 5y ago
      > just pointing out that "there are audits, why does it have such bugs" doesn't tell the entire story. So? Isn't that the point though? Having regular audits should have caught this issue? I thought this being 'open source' this would made this even easier. Which leads me to believe a team that has $60M~ in funding is unable to fix this issue in a matter of urgency. Remember this issue was open for half a year with users noticing this, no matter how you slice this, this issue does not give me any more confidence in Signal being secure.
      - maqp 5y ago
        >So? Isn't that the point though? Having regular audits should have caught this issue? I thought this being 'open source' this would made this even easier. You have it the wrong way. Testing, audits, and open source are all best practices. They should be done. None of them are guarantees of security. Open source is not guarantee of finding all bugs, it's a necessity to allow anyone to look for bugs (and backdoors). Audits can not be passed. They can only be failed. Kind of like how RNG tests can not be passed, they can only be failed. Example: Use SHAKE256 to extrude any keystream on initial value 0x00. It will not be secure, but it will pass any statistical test. >this issue does not give me any more confidence in Signal being secure. No application can actively prevent a bug like this. As an author of high assurance comms system, see what I wrote under threat model: "If hardware such as computers/optocouplers user has bought is pre-compromised to the point it actively undermines the security of the user, TFC (or any other piece of software for that matter) is unable to provide security on that hardware." This also applies to software issues that actively undermine the security of the user. So the thing is, a software bug that outputs sensitive data to wrong contact, can not be absolutely prevented. You would need a friendly MITM-guard node that runs a Google-grade image recognition algorithm that detects you're trying to output a legal document to the wrong client, or a nude to not-your-SO. Again, bugs are unavoidable, what matters is the incident response, and is Signal actively trying to protect you from everyone, including themselves. Another PoV: If you punitively fire people that get caught in social engineering pentests, you're replacing a person who now has real-life experience with social engineers, with someone who may or may not have such experience. Sure, if the person fails multiple times, it's time to let them go, but Signal's reaction is indication of a good employee who takes personal responsibility in making sure it won't happen again. I'm extremely careful about what I recommend, and I have serious trouble finding a way to agree with your assessment that just because a rare bug is open 6 months is of serious concern. It wasn't being sat on for six months. But you're very keen on giving that idea. Would you care to elaborate?
  - godelski 5y ago
    The bug wasn't open for months, the dev just forgot to close it and he's in the thread.
    - detaro 5y ago
      He forgot to close it 10 days ago.
    - colesantiago 5y ago
      Where is the original issue for this, if that is the case? Otherwise I see signal developers closing duplicates [0], towards the main issue [1] which leads me to believe it was open for months. Even if the bug was fixed at 7/21 on the original thread and this main one, this issue was still open for months. [0] https://github.com/signalapp/Signal-Android/issues/11137 https://github.com/signalapp/Signal-Android/issues/11137 [1] https://github.com/signalapp/Signal-Android/issues/10247 https://github.com/signalapp/Signal-Android/issues/10247
  - maqp 5y ago
    So what ingenious method should they have deployed to prevent all programming errors beforehand, and how should they have handled it? Advice users to fall-back to non E2EE SMS? The team deployed logging as fast as they could, successfully detected the issue as soon as it happened again, and deployed fix as fast as possible. What should they have done? If you only recommend chat apps with perfect track record, you're basically recommending chat apps with internal policy of not disclosing vulnerabilities, and ones that downplay any revealed vulnerabilities.
    - hellcow 5y ago
      I don't think anyone takes issue with the fact that the mistake was made or that it was really hard to track down. Shit happens. How you handle it is everything. No communication on it and issuing no warning to their users for a critical bug that risked user privacy in a substantial way for 7 months is unacceptable for an app that calls itself secure, full stop.

soziawa 5y ago

The protocol has been reviewed plenty of times. The rest of the app has not. At least according to your list.