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)

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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)

Why would encryption ever be "optional"?

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.

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

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

link please?

Specifically, the replies of the submitter in the comments

Saying "we use encryption" isn't any good; this isn't 1996. People need to have the details available if they want them (a little "More Information" link going to a page showing their actual security model, list of ciphers and modes of operation, etc. would do).

So either you trust them to do a good job or you don't. Whether someone in marketing knows the name of your favorite encryption doesn't really change that.

I'm much more likely to trust if various indicators suggest they're being sane, reasonable and knowledgeable.

Bottomline: You either trust them or you don't.

One reason for them not sharing the details could be that they want the potential hackers to keep guessing rather than making their life easier (No encrytion is foolproof)

That's not true at all. Trust isn't blind faith. Their choice of algorithm, and other factors they can disclose tells a lot about their understanding.

"One reason for them not sharing the details could be that they want the potential hackers to keep guessing rather than making their life easier (No encrytion is foolproof)"

This is security by obscurity, an example of a poor choice. Overall, your statement says more about your lack of understanding of software security than anything else; as their statements can about theirs.

There is no security silver bullet - a properly secured system is security by many strategies. One of those strategies may indeed be obscurity.

You could perfectly well trust that they're earnest without trusting that they're competent. If that's your position, which is resonable, given enough information you can alleviate some of the competency concerns.

That said, given the landscape they're working in, it's hard to trust any commercial entity is genuinely willing and able to keep your communications secure.

Exactly.

Transparency in how you secure your shit is basic diligence, then the user trusts that that is accurate and properly implemented. I'd never use a service that didn't do that; just as I have a firefox addon (CipherFox) that shows what cipher a site is on, so if I see, for example, RC4, I know it's secure in name only.

Obscurity may only buy you time while you fix your security problems (before someone stumbles across the mistake you've made), but if you can manage to correct flaws before they are exploited, well, that's a good thing.

That said, Wire would do better to share enough details to show that they are putting real work into security and encryption. Compare Wire's security detail with something like Crypho's: http://www.crypho.com/features.html

They're still omitting plenty of details in their implementation, but it's obvious they have a strong focus on security. Wire doesn't really say anything (yet).

They have features like syncing the read status of messages, so I assume their server knows about all messages and conversations (although maybe not the contents if encrypted properly).

I'd prefer a honest "We are no security experts, don't use this for critical conversations!"

They offer these 'challenges', but other than that? For me, this comment of yours would we something I'd agree with if

- Telegram would start out with a protocol that works/is 'accepted' (OTR, TextSecure)

- Would make chats encrypted by default/all the time

That'd be awesome. Given that they seem to know a bit about cross-platform development and design the result might be extremely interesting. Right now? I'm not convinced.

a) I hate the discoverability. Just because I install an app doesn't mean that my ex from ten years go should see that I'm online. Heck, my mom or aunt don't need to see me showing up in the address book either.

b) Desktop clients. Tablets with wifi only.

"It’s in our terms of use: we’re not going to look at your data and cultivate it for advertising," said Christensen. "We’re not going to put advertising in the client. My head of design would kill me! It’s more about finding the right kind of opportunities that are additive to the user experience, and that they’re motivated to pay for. We’ve found what we think are a couple of good ones."

Probably more than US laws anyway.

If they can prove one end of the conversation is not American or not in the U.S. you're recorded... but because it's so hard to do that on the fly, you're recorded anyway and they'll figure out the legal repercussions later... by hiding it, diverting the question or flat out lying about it.

It's a shame, this looks on the surface like a great product. But I agree with the point made earlier: In the age of Snowden, statements as vague as "Wire interactions are secure and we comply with European privacy laws and regulations." aren't enough for anyone to stake their security on.

The fact is, when it comes to communication security, the Government has proven themselves untrustworthy too many times for us to believe them anymore. Once could be written off as a mistake, twice, perhaps oversight wasn't good enough. But three, four, five times... the fact is, Governments have torpedoed any reasonable person's ability to trust them when it comes to looking after their privacy. So saying that you "comply with privacy laws and regulations" is no comfort. In today's political climate, if you want the trust of the people, you need to go above and beyond in the name of the people.

I hope they applied more (security-related) common sense in their apps than in their website.

I'm complaining about security implications by introducing unnecessary complexity.

I'm German and use en_US here, so for ö I'd need to compose a character manually. Which is probably what was mocked (whether that is right or wrong I do not know - I certainly cannot judge the style of writing of someone in his native language, as a foreigner myself).

You are entirely correct about needing compose to type the symbol, but I use it so rarely, that I just copy-pasted.

It's not an umlaut though, it's a different diacritic called diaeresis. It makes me feel like I'm speaking a more awesome language when I use it.

The 'not an umlaut' part doesn't seem to be relevant though, since we talk about the character composition. 'ö' is the same character both as o-umlaut and as o-diaeresis (I admit I checked if there's a different way to write the latter), so the argument is weird.

de_DE has a character 'ö' on the keyboard, if I use that as umlaut or not is a different problem.

Composing " and o (or whatever you use) produces what looks like o-umlaut to a German speaker - and my understanding was that you were 'attacked' (if you will) for going out of your way to write 'ö'. Whatever that character signifies here.

(I actually didn't know the name diaeresis, but the usage isn't uncommon here. I've driven my share of Citroën 2CVs in the past)