XMPP is quite power hungry, keeping an open TCP connection, otherwise it's a good protocol, but Facebook has implemented it with quite a number of ugly bugs that can make it really hard to use a decent XMPP client.

Not a chat client. An instant messaging service with several million users. They are what gives it value, not the client or servers or anything else.

>> The lack of reasonable IO (keyboard)

You know, that IO stands for Input-Output, output is quite decent on mobile phones (for a chat), keyboards are flaky, but swipe-type ones are quite OK for operating with one hand while walking or standing.

>> privacy (all sms is logged)
>> and per-msg charges from providers makes it about the least desirable option.

You seem to think that all chats are SMS. Let me tell you about this wonderful thing, called internet, that has been used to send instant messages without charge for a couple of decades now (ICQ, Odigo, MSN, IRC). Using adequate encryption scheme you can even take back your privacy.

Yeah, because hiding that behaviour and pretending to be an adult is so much healthier. People should evolve, not blame the tools that let them show who they really are.

>> end-all-be-all messaging and communication platform

You mean like Skype, Viber, Line and not so long ago MSN and ICQ. FFS, just turn on the goddamn federation. I don't care for client-server protocol, but just let people from different networks talk to each other.

Well, luckily for MS, google never released source code for their proprietary apps. All in all I see this as a positive thing. Google has been tightening it's grip on android ecosystem, trying to absorb as much of basic APIs into it's proprietary GoogleServices as possible. Maybe this will force them to open up again at least a little bit.

I think open ebook community should thank Adobe for demonstating (at the cost of their reputation and revenues) to everyone who ever did something as stupid as buying a book with Adobe's DRM, what't it's all about and all the dangers of having someone else manage your access to the content you bought right to access. Only through these actions will people learn, as they only listen when they've been hit in their wallet. Luckily, ebook reader (hardware) manufacurers will also learn the hard way, that implementing an obscure DRM scheme is more expensive in the long run (and more damaging to the brand and sales) than partnering up with a shop that not only allows you to buy the books, but even keep them after it changes the technolgy (or goes down in flames) without taking all the books with them.

All that aside - those who suffer from it, deserve it. Hopefully this lesson will be painful enough to remember not to mess with DRMed content any more.

Everybody has a right to decide. It's forcing your decision on others where we draw the line. Everyone can share their opinion regarding other people. Heck, that's called free speech (yeah, I know, you don't have that in US anymore), but stop with the attitude, please. From perspective on a global scale, from humanity as a whole to a local community - it truly is a time wasted and that could have been spent better, from individual perspective, some, I'm sure, would also agree they wasted their time, others will say they had the best time and consider it a time well spent. And yet still everyone is entitled to their opinion and it's expression.

Maybe they should have avoided lying in the first place instead of avoiding to call it what it is now?

>> Also anything that uses a public key exchange is only secure because certain reversals of transformation are 'hard'.
Nope, it's also only secure as long as you verify that the key you have in front of your eyes corresponds to the person you want it correspond to.

>> There is no universality to hard, what is hard for me may not be hard for you..

Actually you might want to refresh your memory a little bit about cryptography. To crack a decent asymmetric cypher it would take more than visible universe working as a computer for time longer than said universe exists. So, there is universality to hard.

>> I support the sentiment of these guys but your code is going to be running on a platform that is largely exploitable by most English speaking foreign governments and possibly well funded crooks.

I don't support their sentiment. If they really wanted to create a secure platform - they could. I'm pretty sure that it's not that hard to check out best practices and analyze the situation before coming up with solutions. a) The only good security - is end-to-end (i.e. data is only unencrypted on endpoints and only people wielding the keys are on the endpoints) b) You verify the keys via a secure channel to prevent tampering (I'm quite convinced NSA is not good enough to fake a live video stream with you holding up a QR code in real time and on a mass scale) c) you should be able to host your own server and have access to both client and server (because otherwise the software might actually be leaking the information).

So, with all that in mind we have people who just want to cash in a check on public outcry about privacy violation and make a quick buck exploiting mass hysteria. For example The Guardian Project are actually doing a secure open source IM, with code available for audit and allowing for end-to-end perfect-forward-secrecy (OTR) encryption and key verification. Now that is the right direction, not cloning yet another IM and telling everyone "Trust us, we're the good guys, we'll protect your privacy, unlike those other guys".

My though exactly. Even if third-party researchers cannot find any vulnerability in the protocol itself, who says there isn't a backdoor in the server part, that will reduce security to 0? Pretty sure they won't open the server part to scrutinity (even if they do, how do we verify that it's the same version running on the actual server?)

I'm pretty sure they omitted the part where users have to exchange keys over trusted channel (or at least a channel that prevents or makes it really hard to tamper with it). And this allows for a mitm attack, so all that fancy encryption is absolutely useless, since the attacker will have both keys and total control. What we need right now is not a gazillion of apps that create the illusion of privacy, but a protocol and a set of standards for federated communication channel (pretty much what XMPP is). Since many claim XMPP is not suitable for modern-day communications I would like to see more effort toward improving it (or creating something from a scratch, if it's so flawed). Because right now the only universal and secure way of communication is email with GPG or SMIME encryption slapped on top of it.

Maybe it would, but those backdoors are worth much more to NSA unpublished. As well as all the data that passes through the vulnerable services. So should you scenario come to life, it would be huge success for endusers, as many vulnerabilities would be closed.

Regarding the article: talk is cheap, show me the code. And let me host this server myself, with inter-server communication. Otherwise it's no better than hangouts, iMessage, Whatsapp, Viber and whatnot else is now trying to be the one and only messaging service. You can't even begin speaking of security if a) you can't audit the code b) you can't control the data.

Very little incentive. Which is a good thing. I don't want crappy free games, that nag me to buy content on every corner. I want the full package for the full price. Current in-app purchase business model hides all the costs in extra items so in total the price comes up to a rather high number.
Can't wait till writers implement something like that. "to read how our hero defeated the magic dragon please buy this 5-page abstract". "to get a clue about how the villain tricked the police, please buy this 2-page abstract".

It's a thing that will suck up all of the good google's services to fail miserably, as userbase that is OK with G+ is much smaller that YouTube's and GMail's userbase. And we've already got one facebook, who needs another one, google flavour? It's development is dead in the water after the launch.