[toggle]

> BitTorrent Sync remains the most secure and private way to to move data between two or more devices.

That very first sentence will always be false as long as it isn't open source. (Even the protocol isn't publicly documented, last I checked.) I'm not an open-source purist, but the way they always promote as being the most secure, private option out there while completely ignoring that fact is frustrating.

I haven't tried using it, but Pulse[0] appears to be an open source replacement for BitTorrent Sync. I figure it's relevant to this thread.

[0]: https://ind.ie/pulse/

EDIT: ef4 mentioned Syncthing in his comment. Pulse was forked from Syncthing. I think they're still compatible with each other at the moment. Nice explanation at https://discourse.syncthing.net/t/syncthing-is-still-syncthi....

[trickz]

How would open sourcing it make it more secure? I mean, I understand that doing so would let you look at the code, and maybe even have others find and plug security holes, but your statement seems to imply that closed source is less secure by default, unless I'm missing something.

[mkonecny]

Doesn't necessarily make it more secure, but will increase the confidence that it is the most secure through peer review. Any company will say their products are secure/the best etc. - proof is what makes those claims legit.

[tedunangst]

I think 2014 should be the year we finally retire the millions of eyeballs meme. Open sourcing something does not magically cause people to review it.

[click170]

No, but it does make it possible for those few who do. And that's a few more than would have reviewed it if it was closed source.

It's not perfect, but IMO this is one of the best parts of Open Source, I can audit it if I want to. Closed Source strips me of that option.

Edit: Clarification.

[rich90usa]

> I can audit it if I want to. Closed Source strips me of that option.

Closed source does not strip you of the ability to audit.

In the case of BitTorrent Sync you can use Wireshark to inspect the network traffic yourself. BitTorrent even goes so far as to purposefully use plaintext for the usage statistics it reports back so that someone could cross-verify with Wireshark. Besides Wireshark there's all sorts of tools for instrumenting, debugging, or decompiling Sync that would also fall within the realm of auditing.

As other commenters have noted, it is not exactly trivial to verify that a binary for some open source software was produced by the same open source code you audited. This leaves you with having to compile from source everything – which seems only an order of magnitude or so less annoying than Wireshark-ing or IDA-ing everything.

Perhaps a better approach to handling the security concerns of open vs. closed source software would be to take a more active approach to locking down what we run. Lets operate with the working assumption that whatever we run is hostile instead of having blind trust in open source. Lets use firewalls, containerization, selinux, etc. to essentially configure whitelists for what we allow of the software we run.

For someone that doesn't trust BitTorrent Sync because it's not open source consider locking it down. Use a firewall to only allow connections to known peers, isolate it from other processes, and restrict filesystem access. Trade some usability for security.

The kinds of things y'all are concerned about with BitTorrent Sync are the same things we should be just as concerned about for what we just apt-get'd; closed source vs. open source doesn't make a lick of difference in that respect.

[wglb]

I can audit it if I want to But seriously--do you? Or others that you know working in the field?

[click170]

Yes I have, several times.

Sometimes it's to find out what the heck is the cause of a particular behavior in a program, sometimes it's to know for sure that the program isn't trying to do anything that I recognize as malicious in a security sensitive environment, other times it's to see exactly how a game is calculating whether or not my bullet has hit the enemy (server side calculation is more difficult to fake than client side).

Would you honestly chose a black-box solution for a business critical need, knowing that it could stop working at any time and won't let you know for sure that the code is secure by auditing it (or paying a trusted security professional to do so for you)?

I get the impression that the anti many eyes sentiment comes largely from non-programmers, am I wrong about that?

[stormbrew]

Or 2014 should be the year that it's confirmed that open sourcing something can lead to people finding bugs in it. It's kind of bizarre to me that people finding bugs in open source software and being able to both patch it and release patches of it themselves indicates a failure of open source. It's not as if the closed source security software of the world fared any better this year, and I'd still rather be able to get a patch from Debian right away than wait for Microsoft to get off their ass and release one.

On a practical level there are clearly limits to the many eyeballs hypothesis. Particularly if your assumptions about it were based on the idea that every user is an 'eyeball'. It's obvious there isn't a linear relationship between the two. None of that means it isn't still better than the alternative.

[wglb]

It's kind of bizarre to me that people finding bugs in open source software and being able to both patch it and release patches of it themselves indicates a failure of open source.

The claim is not that it is a failure of open source, but that is a failure in the "many eyeballs" claim.

Looking at two fairly famous bug hunters, Juliano Rizzo and Thai Duong finding POET, BEAST and CRIME, didn't require open source to find these bugs. BEAST was identified in 2002, but wasn't taken seriously.

Not having source is not much of a speed bump for a bug finder.

This "many eyeballs" is giving us all a false sense of security.

[eps]

> This "many eyeballs" is giving us all a false sense of security.

Precisely!

This issue is further amplified by the fact that lots of people believe that "open source" means "trustworthy". If someone opens up their code, they must be good guys. This assumption is very easy to exploit. All a bad player needs to do is to distribute both the source and the binaries, but build latter from an alternative source. Just look how long it took for someone to actually try and verify that TrueCrypt binaries were in fact built from the source supplied. And that's for a security product with a massive installation base.

[stormbrew]

"Bugs can be found in closed source software" and "code will be seen by a wider variety of programmers if the source is open" are not contradictory statements. This is a false dilemma.

I agree there is an element of false sense of security, but I fail to see how the answer to that is to actively encourage our security software to be closed source.

[click170]

> Not having source is not much of a speed bump for a bug finder.

As someone who has found bugs in software thanks to having access to the source code, I call bullshit on this. I likely would not have been able to identify the bug myself without access to the source.

It is true that you can find bugs in closed source software, but it sure as hell is a lot easier when we have access to the source.

(I'm aware that code doesn't have to be Open Source for me to have access to it, but I feel that's splitting hairs.)

[JeremyNT]

Open sourcing it is requisite but not sufficient.

Step one in verifying their claims is providing the code. Step two is finding qualified people who are interested in reviewing it.

That review may never happen even if the source is available, but it's guaranteed to never happen if the source is not available.

[tedunangst]

Qualified people review closed source designs all the time.

[JeremyNT]

Sure, they could contract out with trusted third parties to review the code, but they would then need a mechanism to ensure that the binaries distributed to users matched the code that these trusted third parties were provided.

So yes, it is correct to say that it is not required that the project be made open source to corroborate their claims, but the alternative of keeping it closed source and having third parties verify every release is much more logistically challenging.

[trickz]

Yep, that's fair.

[jmathai]

Completely agree that open source is critical to making claims about security. Else you're asking people to trust you.

Not to be pedantic but the gotcha is that you can't know they're using the open source software as-is. If they run a hosted service or distribute binaries you won't know. Also with cryptography any change (diverging from the open source software) can have regressions.

[stormbrew]

The answer to this, for something like btsync, is that you shouldn't really be trusting the servers outside your control to begin with. That's the whole point of these systems as opposed to the usual cloud model where you're throwing plaintext up to a server and hoping their security model holds.

If the client software is all that's ever supposed to see plaintext, being able to see source allows you to confirm that that is (probably) the case and then compile it yourself rather than trust that they haven't thrown an extra step in that backdoors it.

[virtue3]

I thought about this a lot when trying to come up with a very secure open source email service. Is there perhaps a way to show hashes for the coded binaries/etc that are used that could actually be trusted to be correct?

It just seems like such a chicken/egg problem. Where does the actual trust come from (like holy crap web certificates seems unbelievably broken).

Ultimately it seems like it's just impossible to be 100% for sure what is running on another persons server without having access to it. Which is unfortunate.

[5293qhofeo]

Security is a poor word, but if we define it as quality (reliability, fitness for a stated purpose, logical consistency, etc), then access to source code allows peer and public review. IMHO, free software is just the scientific method (loosely) applied to programming (with a moral context). Test-driven development is an attempt to tighten up the hypothesis-implementation-analysis loop.