Live data from Hacker News

uTox – Free, Secure Instant Messaging

utox.org

21–30 of 65 posts

Re: uTox – Free, Secure Instant Messaging

#21
post #9

I wonder if we'll ever get to the point where projects start advertising what methods they use to weed out memory management bugs (i.e. static analysis, fuzzing, etc) because an adversary that can execute arbitrary code on my machine is far more intimidating than one that can eavesdrop (imo).

Speaking of that, I wonder why uTox & Tox weren't made in memory safe languages in the first place. There could be many possible reasons, so I won't bother speculating.

Just build it with asan and you will get all the safety, memory usage and slowness of a memory safe language.

Re: uTox – Free, Secure Instant Messaging

#22
post #2

Would be cool ta have FOSS iOS apps made with this.

Part of the issue is that both uTox and toxcore are GPLv3'd, which forbids "TiVoization" (and therefore makes it legally difficult to release on, say, the App Store). A more permissive license would make that more plausible.

Re: uTox – Free, Secure Instant Messaging

#23
I would use Tox and any of its clients with caution. At one point in time, your friends would be able to execute arbitrary shell commands on your PC if you were running utox and accepted a file download. Even with large security concerns like this, the lead developer believes Tox and uTox is secure because he reads the code he wrote himself (none the less git history is filled with bug fixes he clearly missed in his reading). This isn't exactly reassuring, especially coming from someone who doesn't have provable past experience in security software.

Edit: I just got banned from their IRC for stating this opinion here.

Re: uTox – Free, Secure Instant Messaging

#24
post #7

I've been using this for the last 6 months or so. Seems pretty good as a client. Stable on the comms side, although short of an audit, I'm just having faith in the security side of things. 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,…

I'm a big fan of accountless systems, but utox does need to solve the roaming profile issue. It simply cannot be used in the real world until they nut that one.

Definitely a crucial feature, but a difficult one for any truly distributed application.

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.

https://remotestorage.io/

Re: uTox – Free, Secure Instant Messaging

#25
post #9

I wonder if we'll ever get to the point where projects start advertising what methods they use to weed out memory management bugs (i.e. static analysis, fuzzing, etc) because an adversary that can execute arbitrary code on my machine is far more intimidating than one that can eavesdrop (imo).

I think that this is a very important point, and I'd like to quote Bruce Schneier in agreeing that "practical cryptography is rarely broken through the mathematics; other parts of systems are much easier to break" [0].

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

Re: uTox – Free, Secure Instant Messaging

#26

Earlier quoted context omitted.

Speaking of that, I wonder why uTox & Tox weren't made in memory safe languages in the first place. There could be many possible reasons, so I won't bother speculating.

Just build it with asan and you will get all the safety, memory usage and slowness of a memory safe language.

You'd need UBsan as well, and even that doesn't catch everything. Regarding memory usage/slowness: why not OCaml, D, or Rust?

Re: uTox – Free, Secure Instant Messaging

#27
post #23

I would use Tox and any of its clients with caution. At one point in time, your friends would be able to execute arbitrary shell commands on your PC if you were running utox and accepted a file download. Even with large security concerns like this, the lead developer believes Tox and uTox is secure because he reads the code he wrote himself (none the less git history is filled with bug fixes he clearly missed in his…

Still sour you got rejected for Summer of Code?

Re: uTox – Free, Secure Instant Messaging

#29

Earlier quoted context omitted.

Just build it with asan and you will get all the safety, memory usage and slowness of a memory safe language.

You'd need UBsan as well, and even that doesn't catch everything. Regarding memory usage/slowness: why not OCaml, D, or Rust?

Rust only recently hit 1.0, so it's pretty obvious why somebody would not have built their software using that.
Post reply on HN