6 ms·

If they don't release the source, like BitTorrent Sync, they might as well just ditch this whole thing right now.

Karunamon 13y ago
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.
- egeozcan 13y ago
  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!
  - ajross 13y ago
    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 open. It's just a poor product decision on the part of BitTorrent.
    - egeozcan 13y ago
      You are right. I see a lot of companies that do well with the support model though. What's their business model with this as it is today anyway?
      - wmf 13y ago
        Only enterprise companies can survive on the support business model; it doesn't work for consumer or SMB because they just won't buy support contracts (I'm not counting scams).
    - chimeracoder 13y ago
      > 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. This is where the distinction between "free" (as in freedom) and "open source" is helpful. You can, hypothetically, release the source code of a project under a license that prohibits compilation of that source code (or, prohibits running anything other than the paid binary of the source code). This would allow people to view and theoretically vet the code; they just can run it (legally) without paying for it. Not that I would like to encourage such behavior, or think that it's valuable. But it's an important distinction to remember.
      - nwh 13y ago
        There would be no assurance that the binary is compiled from the source though.
        sturadnidge 13y ago
        And even if it were, http://cm.bell-labs.com/who/ken/trust.html http://cm.bell-labs.com/who/ken/trust.html
        natschil 13y ago
        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.
        jlgaddis 13y ago
        Do we really need to keep posting this link anytime someone says something that has anything to do with building something from source?
      - ajross 13y ago
        > release the source code of a project under a license that prohibits compilation of that source code Such a license would qualify for neither "open source" nor "free software" under the relevant official definitions though. Yes, it would be reviewable for bugs and probably preferrable to a blob. But without the ability to verify the complication you'd have no assurance that the proprietary code was actually built with the reviewed source. Basically this would just be a stunt.
    - taway2012 13y ago
      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.
      - tokenizerrr 13y ago
        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.
        x0054 13y ago
        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?
        makomk 13y ago
        The transport layer is running on the same computer at the same trust level as the encryption layer, which means it can intercept the unencrypted data. Even if the developer's 100% honest it's easy for them to accidentally create a remote code execution vulnerability that allows an attacker to do this.
    - mnutt 13y ago
      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.
- saurik 13y ago
  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 source code can also be obfuscated, if the source code looks "too weird" we probably aren't going to trust it either, and it is also possible to hide a bunch of behaviors across wide areas of "open" "clear" code (so nothing looks "too weird" at any given place in the code). To be very explicit about this, as I think this is a very subtle problem that people tend to totally misunderstand: if I wanted to distribute a chat program and have it be "evil" I would not distribute a binary with hidden behavior (if nothing else, when you find this code in my binary I'm pretty damn well screwed ;P): I'd instead distribute an open source program that involved a threaded work queue for handling multiple socket connections to peers and which had a few very subtle use-after-free race conditions that would only come up under nearly impossible timing scenarios that I knew how to trigger and exploit, giving me complete control of your client whenever I wanted. These are the kinds of bugs people use to attack open source "secure" web browsers like Chrome year after year at Pwn2Own because people are simply bad at concurrency. In this sense, I'd thereby trust a closed source web browser that had no threads or which was implemented in a type-safe garbage collected language (executed on a simply-engineered runtime from someone separate that I trusted, which could also be closed source for all I care) a lot more than I'd trust Chrome. I'd even probably have an easier time understanding what it is doing disassembling it than reading Chrome's code. (To be clear, such a browser doesn't exist: probably you should use Chrome.)
  - hendzen 13y ago
    Actually, there has been some recent research [0] in cryptography that shows it is possible to produce binaries that are obfuscated in such a way such that they are computationally infeasible to deobfuscate (see the linked reference for a formal definition of indistinguishability obfuscation). [0] - http://eprint.iacr.org/2013/451.pdf http://eprint.iacr.org/2013/451.pdf
    - 13y ago
- darklajid 13y ago
  I think that's missing a major point (I'm kind of agreeing with you/considering that required for 'secure', I'm not on Saurik's side of the debate): Open source means it's not going away. I won't, ever again, buy into a network that I cannot keep alive. Which is one of the reasons I don't use Whatsapp and actively prevent my family from using it. No G+. Leaving GTalk (Sorry, 'Hangout'). BTSync? Nope, unusable. BTChat? Same. Even if some highly trusted party would explain to me that BTChat is the most secure network, period: As long as I don't see the means to keep that thing alive it is just another potential trap.
jewel 13y ago
I feel the same way. I've been working on an open source clone of btsync because I don't feel like closed-source products can be trusted. I've just documented the protocol so far, so there's no working code yet, but it's at https://github.com/jewel/clearskies https://github.com/jewel/clearskies.
- killerpopiller 13y ago
  that would be great, good luck
forlorn 13y ago
No code no game.

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.

egeozcan 13y ago
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!
- ajross 13y ago
  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 open. It's just a poor product decision on the part of BitTorrent.
  - egeozcan 13y ago
    You are right. I see a lot of companies that do well with the support model though. What's their business model with this as it is today anyway?
    - wmf 13y ago
      Only enterprise companies can survive on the support business model; it doesn't work for consumer or SMB because they just won't buy support contracts (I'm not counting scams).
  - chimeracoder 13y ago
    > 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. This is where the distinction between "free" (as in freedom) and "open source" is helpful. You can, hypothetically, release the source code of a project under a license that prohibits compilation of that source code (or, prohibits running anything other than the paid binary of the source code). This would allow people to view and theoretically vet the code; they just can run it (legally) without paying for it. Not that I would like to encourage such behavior, or think that it's valuable. But it's an important distinction to remember.
    - nwh 13y ago
      There would be no assurance that the binary is compiled from the source though.
      - sturadnidge 13y ago
        And even if it were, http://cm.bell-labs.com/who/ken/trust.html http://cm.bell-labs.com/who/ken/trust.html
        natschil 13y ago
        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.
        jlgaddis 13y ago
        Do we really need to keep posting this link anytime someone says something that has anything to do with building something from source?
    - ajross 13y ago
      > release the source code of a project under a license that prohibits compilation of that source code Such a license would qualify for neither "open source" nor "free software" under the relevant official definitions though. Yes, it would be reviewable for bugs and probably preferrable to a blob. But without the ability to verify the complication you'd have no assurance that the proprietary code was actually built with the reviewed source. Basically this would just be a stunt.
  - taway2012 13y ago
    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.
    - tokenizerrr 13y ago
      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.
      - x0054 13y ago
        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?
        makomk 13y ago
        The transport layer is running on the same computer at the same trust level as the encryption layer, which means it can intercept the unencrypted data. Even if the developer's 100% honest it's easy for them to accidentally create a remote code execution vulnerability that allows an attacker to do this.
  - mnutt 13y ago
    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.
saurik 13y ago
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 source code can also be obfuscated, if the source code looks "too weird" we probably aren't going to trust it either, and it is also possible to hide a bunch of behaviors across wide areas of "open" "clear" code (so nothing looks "too weird" at any given place in the code). To be very explicit about this, as I think this is a very subtle problem that people tend to totally misunderstand: if I wanted to distribute a chat program and have it be "evil" I would not distribute a binary with hidden behavior (if nothing else, when you find this code in my binary I'm pretty damn well screwed ;P): I'd instead distribute an open source program that involved a threaded work queue for handling multiple socket connections to peers and which had a few very subtle use-after-free race conditions that would only come up under nearly impossible timing scenarios that I knew how to trigger and exploit, giving me complete control of your client whenever I wanted. These are the kinds of bugs people use to attack open source "secure" web browsers like Chrome year after year at Pwn2Own because people are simply bad at concurrency. In this sense, I'd thereby trust a closed source web browser that had no threads or which was implemented in a type-safe garbage collected language (executed on a simply-engineered runtime from someone separate that I trusted, which could also be closed source for all I care) a lot more than I'd trust Chrome. I'd even probably have an easier time understanding what it is doing disassembling it than reading Chrome's code. (To be clear, such a browser doesn't exist: probably you should use Chrome.)
- hendzen 13y ago
  Actually, there has been some recent research [0] in cryptography that shows it is possible to produce binaries that are obfuscated in such a way such that they are computationally infeasible to deobfuscate (see the linked reference for a formal definition of indistinguishability obfuscation). [0] - http://eprint.iacr.org/2013/451.pdf http://eprint.iacr.org/2013/451.pdf
  - 13y ago
darklajid 13y ago
I think that's missing a major point (I'm kind of agreeing with you/considering that required for 'secure', I'm not on Saurik's side of the debate): Open source means it's not going away. I won't, ever again, buy into a network that I cannot keep alive. Which is one of the reasons I don't use Whatsapp and actively prevent my family from using it. No G+. Leaving GTalk (Sorry, 'Hangout'). BTSync? Nope, unusable. BTChat? Same. Even if some highly trusted party would explain to me that BTChat is the most secure network, period: As long as I don't see the means to keep that thing alive it is just another potential trap.

jewel 13y ago

I feel the same way. I've been working on an open source clone of btsync because I don't feel like closed-source products can be trusted. I've just documented the protocol so far, so there's no working code yet, but it's at https://github.com/jewel/clearskies https://github.com/jewel/clearskies.

killerpopiller 13y ago
that would be great, good luck

forlorn 13y ago

No code no game.