A little disappointing that there's no Linux version and that clicking "Other Platforms + Betas" just takes you to the Windows download. Also it's closed source.
Just telling people this so they can save signing up if it's not for them.
BitTorrent Chat - Private instant messaging via secure, distributed technology
61–70 of 112 posts
Re: BitTorrent Chat - Private instant messaging via secure, distributed technology
#62Earlier quoted context omitted.
There would be no assurance that the binary is compiled from the source though.
And even if it were, http://cm.bell-labs.com/who/ken/trust.html
Sure, I guess. But if you don't trust your own system, it doesn't really matter whether you use their code or not. That said, "Reflections on Trusting Trust" is mentioned far too often, without people fully understanding the fact that it would be incredibly difficult, if not impossible to pull something like that off.
Re: BitTorrent Chat - Private instant messaging via secure, distributed technology
#63Earlier quoted context omitted.
In any other context I would dismiss this comment as a troll, but yeah.. Any program that passes itself off as "secure" and is closed source, in this climate, is immediately suspect.
It is possible to analyze the behavior of a program without access to the source code that makes it easy to recompile and distribute modified builds. I routinely open binary files in disassemblers to read through their behavior. Yes, it is possible to obfuscate the hell out of parts of binary code, and that would certainly throw up a red flag for me, but concentrating on the source code seems to miss the point that s…
Your argument is a bit disingenuous. You say you'd trust simple closed-source software more than complicated open-source counterparts. That's a false dichotomy. Open source X is always more easily auditable than closed source X.
I don't think many people are worried that BT will be evil. I think many more people are worried that they'll be incompetent, and it's very hard to be competent at cryptography. That's why we want the source.
Re: BitTorrent Chat - Private instant messaging via secure, distributed technology
#64Earlier quoted context omitted.
Correction its called Silent Circle, not secure circle. I'm happy to see the surge of interest and new projects, but most of the offerings are between embarrassing and pathetic. Either the concept is being exploited for marketing purposes, the individuals involved just aren't appropriately skilled at what they are doing, or there are actual nefarious purposes. (I would agree, Bitmessage, and similar schemes could pro…
Name one platform that is not "leaky".
The most promising new protocol, in my opinion, is Pond: https://pond.imperialviolet.org/
Re: BitTorrent Chat - Private instant messaging via secure, distributed technology
#65Earlier quoted context omitted.
It is possible to analyze the behavior of a program without access to the source code that makes it easy to recompile and distribute modified builds. I routinely open binary files in disassemblers to read through their behavior. Yes, it is possible to obfuscate the hell out of parts of binary code, and that would certainly throw up a red flag for me, but concentrating on the source code seems to miss the point that s…
Your argument is a bit disingenuous. You say you'd trust simple closed-source software more than complicated open-source counterparts. That's a false dichotomy. Open source X is always more easily auditable than closed source X. I don't think many people are worried that BT will be evil. I think many more people are worried that they'll be incompetent, and it's very hard to be competent at cryptography. That's why we…
Ok, then I will say your argument is a bit disingenuous, as I did not compare "open source X" to "closed source X": I am trying to show that "is it open source" is just one of many variables that you might consider while evaluating the security of a program, and I am further attempting to claim that it is not even the most important of these variables. In the real world, we are choosing between software that differ in many ways, not just one: all individual dichotomies are "false".
I mean, I could also say the argument "you can't trust closed source software for this stuff" is also "a bit disingenuous" via the analogous argument that that open vs. closed is a "false dichotomy": a single-threaded/type-safe/un-obfuscated X-source program "is always more easily auditable" than a multi-threaded/type-unsafe/obfuscated X-source program. Now, the question becomes "what variables are more important to you, and will your reactions be 'knee jerk' or rational"?
Re: BitTorrent Chat - Private instant messaging via secure, distributed technology
#66Earlier quoted context omitted.
Your argument is a bit disingenuous. You say you'd trust simple closed-source software more than complicated open-source counterparts. That's a false dichotomy. Open source X is always more easily auditable than closed source X. I don't think many people are worried that BT will be evil. I think many more people are worried that they'll be incompetent, and it's very hard to be competent at cryptography. That's why we…
Ok, then I will say your argument is a bit disingenuous, as I did not compare "open source X" to "closed source X": I am trying to show that "is it open source" is just one of many variables that you might consider while evaluating the security of a program, and I am further attempting to claim that it is not even the most important of these variables. In the real world, we are choosing between software that differ i…
Sure, it's only one variable. I disagree that it's not the most important one.
You can audit a multithreaded open source program much more easily than you can audit a single-threaded closed source program. Merely compiling it adds more obfuscation than making it needlessly, complicated will, and making it needlessly complicated will immediately raise red flags.
You don't need to analyze an open-source program to see that it's been obfuscated, and, if it claims to do anything that requires security, that would probably be enough to make you suspicious.
My ultimate point is that compiling is a form of obfuscation that has extreme plausible deniability. There's no form of obfuscation that will complicate the code of an open source program as much as compiling it will, while still looking as innocuous as compiling does.
Re: BitTorrent Chat - Private instant messaging via secure, distributed technology
#67Earlier quoted context omitted.
Exactly. "Yeah, we designed something, just trust us and hand over all your data". They don't have to make it free, just open the source!
To be fair: charging for peer-to-peer software that is freely redistributable doesn't work as a business model. You make money in open source by selling related services (e.g. github, Android) or support (Red Hat). You can't do it by licensing the product. That doesn't invalidate the point above though that in the modern world a tool like this can only be considered "secure" if the implementation(s) are completely op…
Interestingly, you can. Limewire was open source, but charged for a "pro" version. (which was also open source, with the exception of some build files)
The biggest problem with all of it was that there were a bunch of scam sites that added malware, built binaries, and bought "lime wire" keywords on google.
On the other hand, I don't think OSS is to blame for that--the scam sites could have just as easily distributed any binary.
Re: BitTorrent Chat - Private instant messaging via secure, distributed technology
#68Earlier quoted context omitted.
They can split the program into two parts. The "UI" part and the "transport" part. The UI part will be in charge of converting plaintext into ciphertext and vice versa. ciphertext will be handed off to the transport module. The transport module can remain closed source. Only the API to the transport needs to be published. People can write their own UIs.
But that would defeat the point of opening the source, the part we're interested in is the security of the transport not how that pretty UI is made.
If the UI module does encryption and decryption, and if the said encryption is good enough, why would you care if the transport layer steals your encrypted data?
Re: BitTorrent Chat - Private instant messaging via secure, distributed technology
#69Earlier quoted context omitted.
Ok, then I will say your argument is a bit disingenuous, as I did not compare "open source X" to "closed source X": I am trying to show that "is it open source" is just one of many variables that you might consider while evaluating the security of a program, and I am further attempting to claim that it is not even the most important of these variables. In the real world, we are choosing between software that differ i…
Sure, it's only one variable. I disagree that it's not the most important one. You can audit a multithreaded open source program much more easily than you can audit a single-threaded closed source program. Merely compiling it adds more obfuscation than making it needlessly, complicated will, and making it needlessly complicated will immediately raise red flags. You don't need to analyze an open-source program to see…
> You can audit a multithreaded open source program much more easily than you can audit a single-threaded closed source program.
I think this is our core disagreement, as I've been pretty clear about how I don't just accept this statement at face value given the large class of subtle bugs that can and do occur constantly in multi-threaded systems. I find reading through and finding bugs in complex binary-only buffer-management or even cryptographic systems "easy" (time consuming, but not requiring much brain function; even obfuscation just adds time and effort, it doesn't require greater intelligence); yet, I have never managed to remove every single concurrency bug from an open-source project I maintain that only actually uses threads to separate tasks like "searching" from "downloading update" (of course, I likely didn't put as much effort into it, so this doesn't prove anything of course: but I hope it makes you think), and I've seen people "much smarter than me" (working at Google and Apple) fail at doing so in systems that are "much more important" (working on Chromium and WebKit).
You might then just say that I'm probably just stupid and that a more reasonable programmer wouldn't have the same kinds of issues, but "concurrency is hard" I had assumed was a well-known issue. (And again, I think that this all becomes more more interesting to think about once you realize that a "backdoor" left by an intelligent opponent is going to be nearly indistinguishable from a "bug". At least once a year there is some obscure privilege escalation bug found in the Linux kernel: I think it is interesting to at least consider momentarily that any of those might have been a backdoor, and not a bug; the concept of what constitutes purposely malicious code updates tends to be way too narrow in my view, and leads people to only consider back doors that are easy to see when you print out the source code.)
> There's no form of obfuscation that will complicate the code of an open source program as much as compiling it will, while still looking as innocuous as compiling does.
Yeah, no: I seriously read through compiled code every day. I was doing a lot of reading through compiled code yesterday while working on figuring out why Substrate isn't working on iOS 7 for example. I am much much much more afraid of the bugs that are latent in a large multi-threaded project that has "lots of hands in the cookie jar" so-to-speak than of a simpler implementation distributed as a closed-source binary. I'm likewise more afraid of open-source projects that accept patches from large numbers of people (which means more people who might be actively /trying/ to add difficult-to-see exploitable bugs), or of projects that are implemented to run as native code versus ones that run inside of type-safe virtual machines (especially if the virtual machine is coded to a spec and I get to select the one it runs on).
Re: BitTorrent Chat - Private instant messaging via secure, distributed technology
#70Earlier quoted context omitted.
Sure, it's only one variable. I disagree that it's not the most important one. You can audit a multithreaded open source program much more easily than you can audit a single-threaded closed source program. Merely compiling it adds more obfuscation than making it needlessly, complicated will, and making it needlessly complicated will immediately raise red flags. You don't need to analyze an open-source program to see…
> You can audit a multithreaded open source program much more easily than you can audit a single-threaded closed source program. I think this is our core disagreement, as I've been pretty clear about how I don't just accept this statement at face value given the large class of subtle bugs that can and do occur constantly in multi-threaded systems. I find reading through and finding bugs in complex binary-only buffer-…
I don't think we're going to agree on this, because at this point it is a matter of degree. I find it more likely that an error will not be malicious, it will just be a honest mistake that will make the entire system less secure.
Cryptosystem security isn't the same as binary security (i.e. against exploits). You can have a very insecure binary (in the exploit sense) but still have valid, strong cryptography (e.g. in its output).
Sure, with something like this, you want the binary to also not be easily exploitable, but I think that getting the cryptography right is more important.
Given these two points (malice vs incompetence and cryptography vs security), I think it is more important for the program to be open source, even if it's complicated, than the other way around.
There aren't many expert cryptographers who are also expert reversers, sadly.