Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Unfortunately, even if they DID specifically list out all the security measures that they used, someone would still complain because it isn't completely open source. The previous company I worked for not only had legitimate encryption for anything private we received from the user (e.g.: email passwords) so that nobody at the company could ever read them, but also had some (if I remember correctly) good documentation on the site listing out exactly what we were doing. The founder of the company even commented with the specific technical details when our product was linked to on HN, and people still weren't happy.

While I sympathize with what you're saying, nothing is going to make people who actually care happy with whatever security a company puts in place. Unless that company releases their source code for everyone to see. Which I would hope most people would be reasonable enough to realize why that's usually impractical. (see the previous HN post about the guy who shut down his business and was debating open sourcing his entire codebase, and all the problems he would have had to tackle to do so)



No, much larger than the issue of open-source is that we already have dozens of major communication protocols that are not based on open standards or that do federation (one implies the another).

XMPP does OTR for example. And you know, the cool thing about an open standard is that it can have many clients. Throw federation in the mix and then many people will actually find it desirable.

Otherwise it's just a matter of being new and shiny. Because other than that, I don't understand how this new messenger competes with Hangouts, Skype, FB's Messenger, WhatsApp, Viber, iMessages, FaceTime, Snapchat, Y! Messenger, Lync, HipChat, Slack, IRC in general, or plain old calls and SMS messages, which are pretty cheap lately in Europe (at least in my country). Note that I enumerated about a dozen of popular alternatives.

I expect new entries to brag about something more than UI. Because my phone has the best UI ever - I just call somebody and that somebody responds because everybody has a phone number. I want to see open standards, federation and encryption, because otherwise new entries are useless for me.

So another proprietary walled garden that promises to keep my conversations secure, cross their hearts? No thanks.


XMPP and OTR are not workable for mobile devices. The protocol structure assumes a consistent background connection that doesn't get killed, something that is relatively cheap to do on the laptops and desktops it was designed for, but is expensive battery wise for mobile devices.

Go download an OTR client for iOS, like cryptocat and notice how it pings you after 10 minutes that you have to re-open the app to keep on receiving messages! It's because iOS does not allow you to keep an app running in the background indefinately for battery reasons. This is required for the XMPP / OTR model to work.

You need a protocol of some sort that would work properly with mobile, and I think textsecure is it.


OTR kind of sucks, partly because of what you mentioned.

I'm trying to introduce the Axolotl ratchet (behind TextSecure's security) into XMPP:

https://github.com/rakoo/goax

The Axolotl ratchet provides true asynchronicity so you don't need to keep the link open forever. You don't even need the other party to be up; the message can be stored on either server and forwarded when the recipient connects, and the recipient will only decrypt the message at this moment. This is what we need.


You can develop an xmpp client for IOS that does not ping you every 10 minutes (or ever). You have to register the socket used for XMPP for VOIP purposes and IOS will happily comply with that. Been there, done that


This still isn't power-efficient. On phones you should be using push notifications instead of holding a socket open.


There are already FOSS replacements for Skype, such as Tox. The fact is that if every line of code can't be inspected then the software can't be considered secure, and we're forced to put blind faith in a faceless corporation, which is understandably not acceptable for many people. I don't really care if you think this is "practical" or not. That's simply the reality of the situation. Proprietary == insecure.

If a company is unable to profit off of making FOSS software then they can go ahead and keep it closed source, but they should not be claiming that their software is secure when their claims cannot be verified. That's simply dishonest, and only proves the critics right about their trustworthiness.


I would argue that, theoretically, proprietary can be secure. A code base can be made secure by highly experienced engineers who are paid to make the code secure. You might never be able to see the code, but it could still be secure. The problem is that you can never actual verify how secure the proprietary solution is. So whether or not it is secure, you don't trust it. (there are even some interesting arguments to be made about the security of any solution that deals with some kind of user input. my previous boss stipulated that the only way to have a truly secure email client is to have some third-party, verified library that takes all the input, and spits out encrypted data to whatever program deals with email servers, without the program dealing with email servers ever seeing that input in plain text form because who knows what it might do with it)

On the other hand as well, open source most certainly does not mean secure. I don't even have to argue to make this point, I merely have to point out Heartbleed or Shellshock.


Yes, proprietary can be secure. But my question to you is why bother?

As a business model open-source arrangements such as Red Hat or the countless Hadoop services show that you don't really need to lock down the source code to create a successful business around it.

With communications software, the costs a closed-sourced software with magical trust-us crypto getting fully compromised is incredibly high. If people can't trust their basic tools to be private, nor be able to verify it, than they can't assume any conversation they have is private. That's a scary world IMO.

This is particularly true for broken encryption more than the presence of memory exploitation such as Heartbleed or Shellshock.


I don't even have to argue to make this point, I merely have to point out Heartbleed or Shellshock.

The reason both were found and had the absurd propaganda campaigns behind them as they did that are the only reason you can even name them to begin with, is precisely because the underlying software was free.

On the other hand, let's name drop another vulnerability and its exploit: SMBRelay. Took 7 years after it was made public to introduce an incomplete and partial fix. Still exploitable to this day, 13 years later.


So what it boils down to, is that both open source and closed source software can have bugs lingering in them for years that go unnoticed and/or unfixed.


While you can argue that some piece of open source software can be more insecure than a proprietary alternative, auditing a piece of software requires access to the source code and that is mandatory. And with open source everybody can audit with no restrictions. Yes, OpenSSH is a piece of shit, but how do you think it was discovered, from 2 independent parties no less.

Then there's another effect that I like - after the initial patch was released, the story went public, we got notified immediately, then we could discuss about what caused it and see the actual commits and who did it. Such a catastrophe can sink a company, therefore you never see such post mortems for proprietary stuff. And yes, even I as a developer cannot audit software for security, but the point is that I could hire somebody else to do that for me, like the Finnish company that discovered Heartbleed.

So yeah, there is no concrete proof that proprietary stuff is less or more secure than open source, but the point is that we'll never know, because nobody can know how secure something is without looking at the source code.


OpenSSH or OpenSSL? I thought OpenSSH was pretty solid, forgetting the fact that configuring it isn't as straightforeward as one would hope.


Sorry, I meant OpenSSL. It was a typo.


Yes, in theory it is possible. However even 100% secure proprietary software must be assumed to be insecure, because we're still running on blind faith, which is patently stupid for anyone who requires security.


You run OpenBSD, don't you? (To be fair, their approach since the 90s seems a lot more reasonable now)


No, my views are not based on my own needs or paranoia. As a security-oriented software developer I recognize that software that claims to be secure needs to deliver, because people like Snowden, Assange et al. may be relying on it some day.


I don't think it's as black and white as all that. This reads like the equivalent claim the NSA makes along the lines of, "if you have nothing to hide, why can't we record every facet of every communication and store it forever?" Business relationships run on trust. Claiming your software is secure when it is to the best of your knowledge is not dishonest.


That's a false dichotomy. Not wanting personal conversations recorded is called discretion, a form of wisdom. Not wanting technical details of a product published is primarily a way to gain a competitive advantage, either against other businesses or against potential threats.


You're making the baseless (and some might say naive) assumption that it is secure to the best of their knowledge. If they really wanted to build trust then they would prove it and leave no doubt in people's minds.


"Dear citizen, you're asking us to make the baseless assumption that you're innocent until proven guilty, if you really want to build trust you'll let us monitor you 24/7 and leave no doubt in our mind."

You're making an assumption of guilt. The fact that something isn't open source doesn't inherently make it insecure.


It doesn't make it trustworthy either. When speaking of encryption algorithms, not publishing a new algorithm for peer reviewing is unthinkable. This is also not about judgment - I do consider people to be innocent until proven guilty, but do you trust people you don't know with issues that could harm you? Besides companies are not people, we are taking about a commercial entity here that wants to sell something. And people get to vote with their wallet and opinions, depending on their needs and I see nothing wrong with that.


"And people get to vote with their wallet and opinions, depending on their needs and I see nothing wrong with that."

I was thinking the same thing! But you seem to be assuming guilt and I am not. Honestly, I can see it both ways. It just seemed spurious to me to state that if we don't know it's good, it must be bad.


I'm not making any assumptions as to their motives; I have not accused them of any wrong doing. As far as I'm concerned, they might be working in good faith or they might not be. That's not good enough when it comes to security. You're incorrect with that last sentence as I and others have pointed out already.


Tox is not a Skype replacement. For example:

- Skype is "everywhere" (Windows, Windows RT, Windows Phone, OS X, iOS, Android, Linux, FreeBSD, Blackberry, XBox One) and opposed to a handful of places (Windows, Linux, OS X, Android, iOS, FreeBSD, OpenIndiana). Plus Outlook.com's Skype implementation supports most platforms with a HTML5 browser.

- Landline/cellular phone calling. Text message sending.

- Caller ID, Voicemail, etc.

- Skype Numbers (i.e. buy a landline phone number people can call your Skype via, which is insanely useful for SMBs and individuals alike).

- Tox's feature list is largely a myth. Most clients are missing major Skype features and none support all of them, see this: https://wiki.tox.im/Clients#Features

People who think Tox is a Skype replacement aren't Skype's core demographic. The landline/cellular/etc functionality is heavily used by many and nothing that claims to be a replacement can be taken seriously if it lacks that.


tox.im website is not working. Am I looking in the wrong place?


There is another option - matrix.org is a new open standard for real-time communication (with encryption) in an open, federated ecosystem.

That means you can run your own server and encrypt your own data, and the encrypted data can still be sent to other servers in the federation.

To your point about open source, if something like this can take off it needs to be fully open and transparent, without fees or central data ownership - which is why matrix.org is a non-profit organisation and the standard open source.

(disclaimer: I'm involved with matrix.org)


From the homepage: > Send and receive extensible messages with optional end-to-end encryption

Why would encryption ever be "optional"?


Because we don't want client implementers to be forced to have to jump through end-to-end crypto hoops if they don't want to. The simplest way to send a message in matrix is:

curl -XPOST -d '{"msgtype":"m.text", "body":"hello world"}' "https://matrix.wherever.com/_matrix/client/api/v1/rooms/$roo...

...and we'd like to keep it that way. But you can always insist on only ever communicating with folks who are on E2E crypto clients if you so desire.


Is that the same way I can always insist on only ever receiving PGP-encrypted e-mail?


Not quite - as PGP is a pita to use, and not a formal part of the SMTP spec. So refusing to read non-PGP would be suicide. But if it was considered table stakes to implement the crypto option of the spec, and all the decent Matrix clients out there did so and sent end-to-end encrypted by default, then it'd naturally become the default. In other words, if you gracefully upgrade chats between capable clients to be end-to-end by default, everybody wins.


If you really believe that, then I feel sorry for your users. Privacy is a public health issue: https://www.theguardian.com/technology/2013/may/21/privacy-p...

In the absence of some forcing function, the trend is for it to get worse, not better.


Back in the day it was often optional due to the additional processing that it required.


That was indeed a thing in the days before AES-NI or simply having 1.4 billion transistors on a chip.

But in my day we've been spending years fighting this sort of short-sightedness: https://www.ietf.org/mail-archive/web/rtcweb/current/msg0274...


>> the previous HN post about the guy who shut down his business and was debating open sourcing his entire codebase, and all the problems he would have had to tackle to do so

link please?


I think the poster may be referencing this submission: https://news.ycombinator.com/item?id=8641867

Specifically, the replies of the submitter in the comments


That's the one, thanks! Sorry, should have linked that in the first place.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: