Edit: I just got banned from their IRC for stating this opinion here.
It's hard to argue with that given that Tox is still in alpha, and this is generally a good idea for any software you use if you have reasons to believe that an adversary is trying to exploit your computer.
Your claims ring true for vast majority of new, COMSEC schemes. Far as Tox, this is what I found on their GitHub page: "Current build status: build failing." I'll add that NSA and malware authors have 0-days on the platforms the tool will likely run on. It will be bypassed like all others on such platforms.
Of all Tox clients, uTox is written in C, using its own UI framework that directly interfaces with X11 and WinAPI. This makes the code itself a mess. The reasoning behind this is that it's somewhat of a meme on /g/ that anything but pure C code is "bloat". I tried contributing a bit last year, did some work on copy/pasting inline images, and found a remote code execution vuln. Then I got fed up with how terribly confusing the codebase was for something so simple. I'm not a professional programmer or anything, just a student, but it seems like it's the same for everyone else in the project.
As a developer of a Tox client (qTox), I personally use a combination of static analysis (Coverity, CppCheck, Clang's scan-build) as well as dynamic analysis (notably the various *Sanitizers) to complement use of modern automatic memory management. But clearly as the many browser vulnerabilities found ever year show, bugs in large projects are a reality and there is no silver bullet, regardless of how sophisticated the current methods might be.
I think that we should absolutely strive for fuzzing, analysis, testing and general security, not in the illusion that software will be perfect, but with the goal of preventing, catching, and fixing bugs before they become an actual in-the-wild threat.
[0] https://www.schneier.com/essays/archives/1997/01/why_cryptog...
I'm not saying this to be mean. I've written lots of bad bugs myself. Humans are fallible-- that's why we have guards on saws, count pills twice in the pharmacy, and use modern languages when we're not in a sandbox.
As for the main tool I use to find bugs, it's asan (the clang address sanitizer) which is much more useful than static analysis for finding actual bugs.
Of course the main thing I do to try to prevent bugs is reread the code again and again which is what catches pretty much everything.
It's open source so anyone can run their favourite tool on it,
That way you get decentralized messaging and don't need to trust their crypto.
What it really needs is some way of having a roaming profile though. Currently you have to have multiple accounts, one for each device. So my friends list has a lot of duplicates depending on whether they're on their work computer, at home, on their phone, etc...
I'm not actually that fussed about the encryption side of things. I'm far more happy with the lack of reliance on centralised servers. You don't need an account somewhere to get it up and running, you just send a message to a friend and compare secrets to authenticate.
(Threema actually recommends a workaround: "Just create a groupchat for each of your contacts with all your devices in it and always use that")
I'm actually prototyping a similar distributed messaging app using remotestorage.io to try to tackle this issue of profile roaming and persistence. In theory it should allow profiles to live in the cloud (in any backend supported by remotestorage, such as Dropbox, Google Drive, and ofc remotestorage servers) and be sync'd automatically across devices to enable features like roaming profiles and simultaneous logins in a distributed manner.
In practice, however, there is still a number of complications such as the need to secure the data being stored from storage providers (remotestorage itself doesn't offer encryption natively), and coordinating communications between accounts with multiple devices (network endpoints) to minimize network inefficiencies. I'm mostly done with the former and steadily making progress toward the latter, so I feel this could be something to consider for the Tox team as well.
It needs to have some easy way of merging profiles cross-device. Maybe if a friend authenticates two profiles as the same person it will merge them if you agree to it. Or something along those lines anyway.
"Future of Instant Messaging"
It's been a while since I read anything about them but last I heard, the crypto was fairly solid and the only problems were one of reliability and user experience; that being said, I'm no expert and we won't know until it gets popular enough to deserve an audit from someone important.
- No push notifications of any kind, meaning mobile devices have to keep a connection open (kill their batteries) or poll for updates (and get the message later).
- No multiple device support, so I can't use my phone _and_ my desktop. I have to pick.
It'll be great when it's been polished up and completed a bit more but it's not there yet.
I would think a new service should support video chat before comparing itself to Skype, but no. (I am actually seeking an open-source alternative to Skype that supports video conferencing: I know of audio clients/services, but not about video)
First off, the App Store agreement explicitly prohibit users to further distribute any software which is distributed through the store. This makes any "copyleft" licenses a no-deal in there since distribution is a defining attribute of those licenses.
Second, as a matter of policy, Apple forbids developers to put any GPL software in the store.
If you would dare to break the App Store agreement and the apple policy for developer, then at that point GPLv3 TiVoization clause would indeed make it further legally difficult. I would however be more concerned about being chased by apple's lawyers, so as a general advice I would be careful and make sure that any licensed software you upload is compatible with both the agreement and policy. It doesn't matter if it is permissive, copyleft, or closed source.