C-toxcore: Remove mention of #426 from the readme

[tox-user]

I believe we should remove the mention of issue https://github.com/TokTok/c-toxcore/issues/426 from the readme. After reading the discussion it seems to me that the goal of some of the commenters was to scare people off from using Tox and to discourage the developers. The "security issue" that it mentions in reality is not as big as some people there pretend it is. I believe that it's important to be transparent about security issues in Tox, but this is not the right way to do it. When your private key is stolen it's over for you. You are owned and there is nothing you can do about it. When that happens you have much bigger problems to worry about than what https://github.com/TokTok/c-toxcore/issues/426 describes. We already have a big, scary warning in the readme and that should be enough. If anyone thinks that we should inform the users about what can happen when their private key is stolen, we should instead add it to FAQ on tox.chat or do it in some other way that is clear and doesn't contribute to spreading FUD.

[sudden6]

I agree that #426 is mostly people wanting to talk bad about Tox, but their key point is valid, Tox is not using a well researched key exchange protocol. Since this is only work in progress to change, I think it's only fair for users to give them all the research we have against our protocol.

[SkyzohKey]

Having a big disclaimer like this one is not benefical to Tox at all. Users are scared and keep using Skype. Developers see this and think ''OK it's full a flaw, I will contribute to anything else''. Please get rid of that asap

[Diadlo]

Better mislead?

[SkyzohKey]

Better inform instead of scaring.

[Diadlo]

I don't see any scaring in the current disclaimer

[SkyzohKey]

The big red/yellow with WARNING is scary.

[tox-user]

I am not against the disclaimer. I think it is there for a reason and if we want to get rid of it, we should make Tox secure first. The warning is scary, but it has to be there.

@sudden6
The issue doesn't contain a lot of useful information (unless I missed something) and contains a lot of questionable opinions that try to show Tox in a bad light. Perhaps we should take the important information (if there is any) from there and present it somewhere without all of those negative comments. We already have disclaimers on the website and in the readme saying that Tox is experimental! I just think we should remove this one issue from the readme and instead focus only on constructive criticism. The issue I mentioned doesn't seem like a good source of information and some of it is not true anymore.

Here are a few quotes:

You're currently shipping an instant messaging application advertised as secure and end-to-end encrypted (most users won't know the difference), where a bored hacker found a crypto vulnerability by simply scrolling over your code.

By all means, continue to develop software and expand your experience and education, in private. But publicly releasing and promoting software with known fundamental insecurities is irresponsible and reckless.

I don't know about you, but I haven't heard of any known fundamental insecurities that Tox has. If you do know any please let me know so that I could stop using it immediately.

We have a largely undocumented, untested, and not well-understood code base of about 19 ksloc (C).
Thus, any change we make has the potential to make Tox less secure, running counter to our goal.

Is this one still true?

[SkyzohKey]

I'm OK with @tox-user opinion :)

[sudden6]

I just think we should remove this one issue from the readme and instead focus only on constructive criticism.

Ok, it came across as if you wanted to remove that warning :) I think summarizing this thread to a few sentences would make sense.

I haven't heard of any known fundamental insecurities that Tox

I think that's partly because no research exist, partly because Tox is hopefully not fundamentally broken :)

The one issue in the comment thread is mainly about there existing a well researched handshake pattern and Tox using it's own one with the flaw about impersonation.

[sonOfRa]

Absolutely not. The issues that Jason points out in that thread are real, and tox shouldn't be susceptible against KCI. And we should be open about these things, and potential users should see them. It is important to be honest and open about what we do, and acknowledging problems like this is part of that. Trying to bury them by simply not mentioning them on the readme is very dishonest in my opinion. Our goal should not be to "get users", our goal should be to provide a secure chat solution. At the current time, while tox communication is likely confidential and authentic, there are the above issues, and we should never ever bury this kind of thing.

Burying and dishonest discussion about cryptography leads us where Telegram currently is. They pretend to be secure, they flaunt their math phds, and they keep claiming it's secure because noone beats their ridiculous bug bounties. We should strive to achieve a significantly higher standard than this.

Also, I strongly disagree that #426 is people wanting to "talk bad" about tox. They're pointing out the issue that tox is designed by amateur cryptographers, has not received any audit, and has vulnerabilities that can be defended against. I know (not personally, but from other interactions with them, and having observed other things they do in the crypto world) that these people are very honest and concerned about security. We should value people like them, instead of portraying them in a bad light.

[zoff99]

@sonOfRa there may be a solution soon, implementing NOISE protocol into Tox.

[tox-user]

@sonOfRa

Trying to bury them by simply not mentioning them on the readme is very dishonest in my opinion

I have a feeling you didn't read my posts carefully :). As I said multiple times: I don't want to hide anything. Those issues should be disclosed, but this isn't the right way to do this. That discussion will most likely lead new users to believe that Tox is much more insecure than it really is. It will mislead them. It describes a problem that was already known and makes a disproportionately big deal out of it. Sure, it would be nice if Tox protected from this, but a lack of such feature doesn't make Tox insecure.

[sonOfRa]

I've read your statements carefully.

The GitHub README displaying this warning and a link to known issues is how this should be disclosed. Hell, I think we shouldn't even offer downloads the way we do on tox.chat because we're lulling people in a false sense of security by not mentioning #426 anywhere on there. Our goal shouldn't be to attract any users at this point.

That discussion will most likely lead new users to believe that Tox is much more insecure than it really is.

Yes but the thing here is: We ourselves do not know how secure Tox actually is. We have no audit. We have no threat model. We know about the susceptibility to KCI. From this point of view, Tox doesn't actually have that great a record. And if that dissuades users from using Tox, good. I can only reiterate: We shouldn't try to attract users at this point.

[tox-user]

Why should we post #426 everywhere? What important information does it contain that everyone should know before they start using Tox and that isn't said elsewhere?

[SkyzohKey]

The goal IS to attract new users / potential contributors. If you scare contributors before they start contributing, Tox is gonna die. I'm not asking to remove the disclaimer, but remove that ugly yellow+red+big image. Most people just look at the image and close the page. :/

[zoff99]

@sonOfRa there are some devs that don't want a security audit of Tox

[SkyzohKey]

@zoff99 I'm for a security audit but for this we need to find money and scarying people isn't going to help..

[zoff99]

@nurupo no, really. no joke.