I trust Moxie more than governments or companies, so this really makes me happy. If you've read things on his website (http://www.thoughtcrime.org) you'll know how important remaining secure from the government is to him. This is a huge step in the right direction. I'd also like to congratulate WhatsApp on their decision, I have a lot more respect for them now.
Congrats Moxie and team. You guys are doing a great thing for humanity.
Absolutely agreed. I didn't see this one coming - WhatsApp have earned a very poor reputation for security in the past. But this is an unexpectedly very good choice, and a very solid step forward.
As closed-source, I still couldn't recommend WhatsApp above Signal/TextSecure, but this means that the squillions of WhatsApp users out there right now will hopefully get strong protection and probably won't even notice - and that's fantastic.
Makes me wonder if perhaps other clients for the TextSecure protocol are viable, maybe even possibly standardisable (although please let's not start going design-by-committee on it, don't allow any changes that haven't been security-reviewed). A desktop TextSecure client is something I would like to have right now.
Especially curious what happens if you properly plug together TextSecure, a DHT (or two), and a mixnet like Tor. (Are you listening, Project Tox?)
It would be ideal, but let's face reality. If they stay separate, there's a chance Whatsapp, Hangouts and let's say Skype (long stretch here, especially after Microsoft worked so hard to make it wiretappable back in 2009 [1]) would all adopt this solid and secure protocol. But if they have to interop, they'd never agree to it. Google even removed XMPP support so Microsoft can't build Gtalk support into Outlook/Skype (among other reasons).
XMPP support is alive and well. I don't know why microsoft didn't integrate it, but that's another matter (it may be argued that the google video chat never truly worked on open standards, and rather than implement a "broken" IM they just preferred to leave it out )
Anyhow, the only real reason to stay separate would be to compete with each other, with the slim chance to push the competition out of the market (at every services' users expense), and I agree how this has come to be a sad reality
Google Hangouts does not support XMPP federation, meaning the ability to connect people on Google Hangouts to people that are not on Google Hangouts.
Ironically, in May 2013 at Google I/O it was Larry Page that was expressing his dissatisfaction with the state of the industry for the lack of interoperability with messaging, lambasting Microsoft. But then just after Microsoft announced their support of XMPP in Outlook.com, Google announces Hangouts.
I guess that was provided as an excuse for dropping XMPP support. Well, welcome to the club Google, now you're part of the problem.
Google Hangouts does not support federated communications. This means that users on XMPP-compatible networks cannot communicate with Google Hangouts users.
All you can do for now is to connect to Google Hangouts with an XMPP client, which doesn't mean much, doesn't work so well and given that Hangouts is explicit in its lack of support for XMPP, we don't know for how long this will last.
This is somewhat complicated. I'm sure Moxie would agree with me that the trust and glorification of individuals in the context of cryptography is ridiculous. Open algorithms and protocols make trust obsolete. Please ignore webs-of-trust for a second — I'm talking mostly about end-to-end encryption. I'm not saying you shouldn't or can't trust people, but I'm quite happy that it's optional.
I don't mind a healthy distrust in governments either, but it's hard to ignore that WhatsApp, Apple and Google are US companies bound to US laws. In other words, while end-to-end cryptography protects you against dragnet surveillance it certainly doesn't solve any of the other, and arguably much bigger, problems we're facing.
When it comes to respect for WhatsApp I'm still undecided. A huge win for WhatsApp is that they actually have a business model, but on the other side they took a decentralised system (XMPP/Jabber) and centralised it.
Effectively what we have here is XMPP/Jabber with TextSecure on top of it instead of XMPP/Jabber with OTR on top of it, which has been around for quite some time now. Maybe that's not terribly impressive but it's great to see big companies join the privacy-by-design camp.
>Effectively what we have here is XMPP/Jabber with TextSecure on top of it instead of XMPP/Jabber with OTR on top of it, which has been around for quite some time now. Maybe that's not terribly impressive but it's great to see big companies join the privacy-by-design camp.
The TextSecure protocol, based on the Axolotl Rachet, is a significant improvement on OTR, both in terms of cryptographic capability and usability.
Have carrier attacks from the baseband been seen in the wild?
By comparison, application-based encryption of messages addresses a bunch of real threats. The NSA is not the only threat; malicious wifi operators, for example.
"Fake cell towers" are rampant across America and operate without warrants. Thats why the police are trying to hard [0] to protect their existence. There is a new project today announced to track all the IMSI catchers around America: https://www.indiegogo.com/p/1016404
These tend to be used to track locations of people but they can also be used to intercept SMS and mobile internet traffic.
They're vectors for layer-2 attacks. The (valid) implication is that you don't have to assume Verizon is colluding with NSA to be concerned about attacks on the baseband.
Good point. But at the same time, a secure, bug free baseband won't save you from a fake cell tower that's intercepting and recording your text messages.
Yes, but a secure, bug free open baseband would, since the first use cases that would be addressed is verification of towers, not blindly camping to the strongest signal, and monitoring your cipher strength.
With an open baseband you could do much more useful and sophisticated firewalling and ACL of your interaction with the cellular network.
As it stands now, you just camp to the strongest signal and do whatever it tells you - including download and run arbitrary java apps to run on your sim card (probably without your knowledge).
German police and intel agencies sent 440,000 sms type0/stealth attacks to trace phones last year, FBI sent an OTA to a suspects internet stick to broadcast his location, and something shady is going on at airports according to Cryptophone GSMK who's radio 'firewall' goes off whenever you get near an airport. Besides that Samsung backdoor found by Replicant Mod that has access to /data and /sdcard haven't heard of other directed attacks yet.
Of course google can install whatever they want on your device if given a NSL including a modified WhatsApp that sends in plaintext straight to the police everything you type but haven't heard of that yet either.
Since Facebook makes money harvesting data wonder if WhatsApp grabs advertising keywords first then sends via textsecure layer.
How would you see a baseband attack in the wild without access to the baseband? It is a circular problem. The main issue is "we just don't know," the baseband is unverifiable from a security standpoint.
good luck detecting baseband attacks in the wild. i hope you've got a transceiver with you and a rainbow table for cracking the A5/1 etc on your cell link.
@nsxwolf because surprisingly the baseband is actually the main processor in most modern designs, the application processor (your quad core snapdragon or whatever) is a slave to the baseband and receives events and data it
Partly because, historically (e.g. on feature phones), the GSM baseband serves as the primary processor (with real-time responsiveness requirements), with "applications" as a subordinate function. The concept of GSM being "just" a modem peripheral is a more recent development, coming more from the laptop arena; pushing that model down into phones (especially cheap phones) will take work.
Even on top of that, the concept of not trusting your peripherals is a recent one as well. Ideally, all hardware peripherals would have no more permissions than they need; for instance, no ability to DMA except to specific pre-arranged regions. In practice, most systems don't actually set up that level of security.
Is this true of say, the iPhone? It seems like a wifi iPad or iPod Touch is exactly the same as an iPhone, but without the baseband. If the baseband were a peripheral of the A8 SoC, this would seem like a trivial difference. But it seems if that's not the case, the iPad A8 would have considerable architectural differences compared to the iPhone one.
It's less true in some modern smartphones (disclaimer: not an expert on the iOS/iDevice architecture in particular), but a shocking amount of code still ends up on the baseband, and the baseband still has as much trust as the kernel. For example, the baseband processor often serves as an offloading engine for power efficiency reasons, to avoid waking up the main processor; thus, the baseband processor might have direct access to the audio hardware, so that phonecall audio doesn't need to wake up the host CPU.
Ok. I do go a bit overboard sometimes with the rants about closed baseband firmware.
But it needs to be stressed that these kind of things are not the magic fix for mobile phone comms that people think they are.
A lot of use cases in our current world involve state owned telecom entities and Joe-Arab-Spring-Six-Pack should not be confused into thinking this solves that problem.
I pointed this out in a comment a few days ago, but the era in handset design when basebands were unilaterally trusted is over. I believe modern Qualcomm basebands are firewalled off from the rest of the device using MMUs, they do not have the ability to do DMA and their firmware is significantly hardened using techniques like ASLR, stack canaries and even using a proprietary VLIW instruction set that is barely documented.
Handset makers and carriers all have strong financial incentives to harden the basebands against hacks because they don't want people unlocking their phones, which was often being done by exploiting bugs in basebands. Also, they need the airwaves to have integrity and mobile protocols are all based on the assumption of trusted endpoints that don't violate the rules. Now that DIY GSM base stations have become a reality, carriers face a nightmare scenario of someone running a buggy or malicoius "tower" that infects basebands of any phones that enters into range and starts them doing some kind of horrible attack against the carrier infrastructure. E.g. you can imagine an extortion attempt that works this way. It's in their best interests for their devices to behave predictably and be controlled only be themselves.
ARM TrustZone. It controls access to various hardware. Other software, including the kernel and baseband isn't supposed to be able to even observe its state. There's a base set of functions which handset vendors can add to. Of course, it has vulnerabilities too.
I haven't heard of any process hardening going on though. Do you have a source for that? I want to learn more about it.
Sure, but getting an IOMMU right on a complicated platform that didn't historically lean on IOMMUs is different than "the IOMMU is backdoored".
Why this isn't just a nit is, if you believe (say) VT-d is backdoored, a lack of IVT research projects isn't evidence of the absence of backdoors. Presumably, if the NSA is serious enough to backdoor Intel chipsets, they'll do it in a manner that a couple of independent security researchers can't black-box.
While there is no doubt you are correct that a baseband attack is possible, it's a much, much harder task for a Telco to get control of your baseband, start poking around in it and reading your private messages via this channel. Has there been any released code that exploits this?
They easily have the technology now to read all your SMS and capture all the data you send. If you can crypt this, you're much better off from a privacy and security perspective than if you don't.
That's what's important about this announcement.
Your BIOS might be spying on your, or your hard disk, or your wifi card, your video card.
This offers good, strong protection for a lot of the attacks your data can be subject to. Not every attack, but the majority.
That is very true and often overlooked. You get Google and SELinux enabled and security domains and such and all is good except for that fact that there is this little brick stuck on on the motherboard running proprietary code, accessing any memory on the phone and talking to the outside world.
Maybe it makes sense for non-baseband enabled devices, tablets, phones with baseband chips disabled somehow (physically).
Or something like a Nexus 7 and then something like Portal. I (perhaps unwisely) mostly trust USB between two devices I control, and even wifi between two devices I control. If I can put the baseband shit on a USB stick plugged into Portal and then use wifi or usb to my tablet, I'm a lot happier.
Somewhat, but not entirely, ameliorated if one were to somehow ensure the baseband and other open components don't share RAM. This is how the Neo900 plans to attack this problem.[1]
Well, asop/cyanogen on a tablet w/o gsm/4g should be pretty safe. About as safe as computing gets these days... now with play services, you obviously add a backdoor to an otherwise reasonably trustworthy system...
Not only is this huge by itself (600 million users with E2E encrypted messages by default), but I'm hoping this will put a big pressure on Google, Microsoft and others to adopt TextSecure's protocol (or something very similar), too.
This is how you deliver strong security to the masses. Not by convincing all your friends to adopt some weird and obscure chat app with the only benefit that it's "more secure" (most won't care), but by getting large service providers to adopt it and push it to hundreds of million of users without them even noticing.
Oh, and I assume that if Whatsapp adopted it, Facebook Chat isn't too far behind...right?
"This is how you deliver strong security to the masses."
You cannot deliver strong security on a mobile phone platform. The carrier owns you. In fact, the carrier owns you doubly over because it can control "your" computer via two pathways - with the baseband and the SIM card - both of which you have no control over.
You cannot be secure on a device that a third party can interact with at the level of DMA. Further, while I keep adding a caveat about some phones whose SOC involves a baseband that is more akin to a USB modem, in terms of architecture, it turns out that even these "less terrible" SOC designs still have kind-of-sort-of ways to attain full control by the baseband over the AP.
It really is that bad. You gain no protection from the carrier or a state actor that can influence the carrier, and certainly no protection from a rogue cellsite that can instruct your baseband (or your SIM) to manipulate main memory arbitrarily.
Highly unlikely seeing as Facebook uses the content of your messages to market ads to you, build up a profile of you, identify you and identify trends (links, keywords).
The fact that Facebook owns WhatsApp makes this announcement a big surprise as I think they profit far more with unencrypted messages (although WhatsApp was just delivering, not storing them supposedly).
I have never seen an ad on Facebook that was obviously targeted based on my chats, in fact, targeting ads based on my chats would be a pointless, money-losing approach for them as I never talk about commercially relevant things with my friends.
The ads I see on Facebook currently are for SSL certificates (guess what I bought recently), BGP routing optimisation products (not sure why), and TransferWise (I used them once). In short, lots of remarketing and something presumably targeted at one of the news sources I get in my feed e.g. slashdot.
These are all pretty nerdy yet also pretty reasonable ads. Ads targeted based on my chats would mostly revolve around .... well, not sure. At best, nights out or local cinemas. I doubt there's much profit in that.
It's possible to build a more complete picture of someone's interests based on what they share privately via Facebook chat.
It's also public knowledge that they've been parsing messages for links to then 'like' the appropriate pages inside Facebook.
Rather than debate about how much profit there could be in it, which is entirely down to what the user talks about, I think it is important to realise the potential here even if it not fully realised at this point it time.
Also remember that they are keeping chat history indefinitely in HBase clusters (because they are 'sentimental') so as your habits and interests change over time this will become invaluable data to marketers who want to understand consumer behaviour.
I think it's great that WhatsApp are implementing end-to-end encryption but their now immediate connection with Facebook doesn't sit well with me. Perhaps I'm an idiot, but it doesn't take long to realise that there are perhaps competing interests at play here.
The main reason why you won't see end-to-end encryption for Facebook is that the messages are also available through the Facebook web site in addition to Facebook Messenger app. Which means that the Facebook servers need to store the key to display the messages.
Since this doesn't seem to be ready to be fully announced yet, I checked last week and Open WhisperSystems is still looking for iOS developers to help. Moxie mentioned on twitter that security and crypto experience is not required, but they are looking for f/t devs not just p/t help.
Also they have a browser extension that could use some help from front-end devs:
They talked to Moxie about it, so it doesn't look like a hoax. More like it wasn't supposed be announced yet.
It goes without saying that this would be a big deal. And it would explain a lot of the slow movement w.r.t. an iOS client. Although The Verge wasn't sure if and when the encryption would be available on iOS. And WhatsApp is closed source software, something that's unlikely to change, which really isn't what we want from a secure messenger. So I might keep Text Secure installed for the time being.
But still. OTR (and the enhanced/modified version of it TextSecure is using) is probably the easiest to use way to communicate in a reasonably secure fashion, and it'd would be fantastic to see it used by hundreds of millions of users all of a sudden -- even if it's sitting on top of insecure mobile operating systems and untrusted-yet-privileged hardware.
>> But still. OTR (and the enhanced/modified version of it TextSecure is using) is probably the easiest to use way to communicate in a reasonably secure fashion, and it'd would be fantastic to see it used by hundreds of millions of users all of a sudden -- even if it's sitting on top of insecure mobile operating systems and untrusted-yet-privileged hardware.
Have you had issues getting OTR to connect sometimes?
Myself and about 5 friends have been using OTR with ChatSecure on the phone and pidgin on the desktop. Sometimes the OTR connection just doesn't engage, and we suspect it's because there are multiple instances of the chat client signed in and it like "crosses the streams" or something. CryptoCat has similar issues. Is there a perscribed way of using OTR that won't give us these problems?
TextSecure hasn't given us any problems yet ... though, we never see the encrypted text messages in our SMS, even when we use textsecure over google voice. Does TextSecure just bypass actual SMS channels?
That's a common problem when using OTR with the same account in a multi-device environment. It is fixed by the introduction of instance tags in libotr 4.x [0]. You should check the versions of libotr used by all your clients - if they are all libotr 4.0+, you shouldn't have these problems.
A simple workaround is to use a different account for each device (e.g. me@jabber.com, me+mobile@jabber.com).
TextSecure's developers recognize that a good multi-device experience is essential to provide a comparable experience to other messaging apps. Their approach is different from OTR's, and is described here [0].
OTR with Pidgin was pretty solid when I used it (I don't, anymore). But OTR doesn't deal well with mobile connections, something that the changes Text Secure introduces to the protocol address. I still have had occasional, non-reproducible hiccups with Text Secure. AFAIK Text Secure only falls back to SMS if there's no data available, and they're considering removing SMS support entirely in an upcoming version ([0], I say good riddance).
I don't know how well, if at all, either of them deal with multiple simultaneous logins. XMPP (Jabber) doesn't have a great answer for it (ie. there may be support in the protocol or a protocol extension, but implementation support is terrible). Which is a shame because it's very desirable from a user perspective; both just being able to receive incoming messages on multiple devices as well as the next level of synchronising message session history across devices. Clearly the latter is way easier if you're willing to store the history on the server.
"[...] and our roadmap for our own products remains unchanged."
What is that roadmap? TextSecure for iOS is stalled...
Awesome for Moxie and team, his is huge news. But the world still needs a cross platform, open source, end-to-end encrypted platform... It's just too important to trust Facebook with.
it might be fair to say that it's taken longer to release than the devs anticipated or hoped. but the good news is that anyone here can contribute to the code and help to change that!
But wait... Didn't Facebook Inc; Buy whats app for 19 billion? So does this mean Whisper Systems is working with 'facebook' on this...? Maybe i'm wrong...
If this is true and has no strings (backdoors) attached this is huge. This means end-to-end encryption for messages from more than half a billion people and an incredible privacy win compared to SMS usage. Brought to you by facebook.
I do not think there are likely to be backdoors: Moxie just wouldn't allow it without walking away and saying something loudly. He is not on the NSA's Christmas list. :)
If the application isn't open-source how can he check though?
They can show a version without the backdoor to him and build the binary with the backdoor.
Or there could be vulnerabilities elsewhere (not in Moxie's) code.
I don't think you can claim no backdoors unless you have the full application under your control, and have it audited.
Trusting one person simply because they're cool, with the privacy of 600M users, is pretty foolish. Even if everything you say is true, and Moxie signs off on the implementation, nothing prevents men in black suits turning up the day he leaves and suggesting they introduce a subtle bug.
Meanwhile, XMPP OTR and SRTP on SIP have been around for a decade. Too bad half a billion people are using a proprietary non-ineroperable chat mechanism with no idea what WhatsApp is logging and with no assurance of the continued availability of the service.
WhatsApp, Hangouts, Skype, etc are all cancer on interpersonal communications by trying to make it a profit center. They destroy user freedom, they severely limit communication, and they do it while making you think its worth your money when you could host your own XMPP server and delegate with an entire network of chat servers.
And no, I do not mean your grandmother should host an XMPP server.
Facebook gets props for using XMPP in its messaging implementation, even if they crippled it by not letting users message outside Facebooks network.
Disclaimer: I'm hosting my own 'friends and family' XMPP server, XMPP clients are the only mobile IM apps I use. In the shelf next to me I have an outdated 'Programming Jabber' book. I want XMPP to be the solution.
If I compare the XMPP feature set with what people around me are doing with WhatsApp though..
- Without optional features (stream resumption?) you have flaky connections/lose messages, even today
- people tend to use WhatsApp etc to send inline media, be it pictures or videos. How would you do that with XMPP, without controlling the client (I run pidgin. Might be on bitlbee?).
- Having more than one device? Tablet and phone? You probably now want carbons (works reasonably well with some rough edges, but some clients don't support them) and likely would like to see your message history on both clients (-> a shared archive).
If the last point, security issues notwithstanding, makes sense/seems plausible, XMPP doesn't seem to offer a decent solution right now. MAM [1] seems to be the answer, but is experimental and .. well - there's no support for it yet.
Yes, I would love to see a world in which XMPP succeeds. But right now it's not practical as far as I can tell.
Why do all of these services insist on you giving them your mobile number? Even Telegram, which claims to be the all giving god of encryption and privacy, insists on having it no matter what. It's a massive barrier to entry which I'm not willing to cross, and I'm sure other people aren't either.
If it's a mobile app, people are generally used to it using the mobile number. For the average nontechnical user it reduces barriers to entry as you don't have to create yet another account with username/password, and it can be used for address book import (which I agree isn't very private!)
My understanding of the perspective of the authorities on encryption in messaging is that it doesn't matter what you say, it matters who you say it to and when; additionally, it matters whether you're speaking cryptically or not.
Whatsapp requires a telephone number as it uses that for your ID. Same with RedPhone. TextSecure (android) can certainly be used without registering -you just miss out on the push-via-data service.
It's not arbitrary. It simplifies things for users a lot. No usernames or passwords to remember. Many telcos link your phone number to your identity which you cannot really lose, so therefore also no chance of losing your WhatsApp account. Also, more importantly, solves the contact discovery/social network problem by letting you reuse the phones address book.
You'll find that many people are very reluctant to give up that sort of information about themselves though, whether it be for privacy or because they don't like being incessantly spammed. I understand it existing as an option, maybe even a default, but to make it to the only method of authentication seems insane. Sure, many users will deem that the benefit of using the application overwhelms any negative implications, but it would be nicer if they weren't forced to make that tradeoff in the first place.
I'm not against the option existing, I'm against it being the only option.
>You'll find that many people are very reluctant to give up that sort of information about themselves though
Erm. I suspect you don't realise that WhatsApp has over half a billion users. It's as large as the major webmail services and nearly as large as Facebook itself. Society has reached consensus on this issue very fast - phone numbers as your identity work well, and any app that wants to be accepted by the market has to work this way exclusively.
> Erm. I suspect you don't realise that WhatsApp has over half a billion users.
I'm well aware.
Just because something has given up this information doesn't mean they approve of being asked, just that they evaluated that the positives outweigh the negatives. If I put out snail pellets to save my lettuces it doesn't mean I enjoy the death of any animal, it just means that I value the outcome of healthy lettuces more than living mollusks.
> any app that wants to be accepted by the market has to work this way exclusively
I see nothing that suggests this, outside of a successful app despite it. Maybe they'd have more users if they didn't have such an asinine policy. We don't (and probably can't) know for sure.
What percentage of potential WhatsApp users is "many"? I'd suggest it's more like a minimal amount, otherwise why do you think WhatsApp gave up greater market share?
As a person who doesn't even own a mobile phone at all I support you wholeheartedly. How am i supposed to use anonymous messenger giving him my real phone number!
I recently tried WhatsApp alternatives that provided end-to-end encryption on Android (I use TextSecure, but only 1% of my contacts do). Wickr was the best, but a little too paranoid for daily use. WhatsApp has a better UI and sends messages faster. I would love to trust that their end-to-end encryption is legit, and WhisperSystems being involved helps, but.. seems I'm still skeptical.
Steve Gibson did a pretty detailed analysis of Telegram on Security Now #444, recorded 25 Feb 2014. He concluded that Telegram's security was inadequate and recommended Threema as an alternative.
Thanks for the link to the security-now show, good stuff and does a good job of explaining the reservations in the crypto community around Telegram. I'm now looking at other options.
I do like that Telegram launched with an API, but ya, it sounds like security isn't something that can be trusted. Thanks for the informative link.
I need convincing. Facebook can't monetize end-to-end encryption, and WhatsApp doesn't ask before uploading my contacts. Encryption from the client to the server is a start, but there's not enough here to make me use it.
> I need convincing. Facebook can't monetize end-to-end encryption,
Completely right. Facebook paid $19Bn for whatsapp. How is not being able to keyword-search messages going to help them cover some of that cost? It sounds great but doesn't add up.
Well, no. As pointed out elsewhere in this thread, if Whisper Systems doesn't own the whole app, then the Whatsapp code might include code (that they "forget" to show Moxie) that phones home to the Zuckerberg mansion/windowless black buildings in Virgina.
TextSecure uses the OTR protocol [1,2], which itself uses Diffie-Hellman key exchange [3] to allow the communicating devices to agree on a shared key without the key being transmitted over the channel [4].
OTR actually uses "ephemeral" Diffie-Hellman [5], where a new shared key is generated for each session. This provides forward security by guaranteeing that a key compromise in the future won't render past messages decryptable.
You're right and I was wrong. The TextSecure protocol was originally based on OTR, but I hadn't appreciated the degree of divergence from it required by their introduction of asynchronous ephemeral key negotiation.
The submitted link (https://whispersystems.org/blog/whatsapp/) is 404. Also, at this time, the Whisper Systems blog doesn't actually show a blog entry referencing WhatsApp.
huh, it worked for me just a minute ago. Wonder if they just took it down? (edit: looks like it's back up now)
Here's the text of the page I got:
At Open Whisper Systems, our goal is to make private communication simple. For the past three years, we’ve been developing a modern, open source, strong encryption protocol [1] for asynchronous messaging systems, designed to make seamless end-to-end encrypted messaging possible.
Today we’re excited to publicly announce a partnership with WhatsApp, the most popular messaging app in the world, to incorporate the TextSecure protocol into their clients and provide end-to-end encryption for their users by default.
Your messages may already be encrypted
The most recent WhatsApp Android client release includes support for the TextSecure encryption protocol, and billions of encrypted messages are being exchanged daily. The WhatsApp Android client does not yet support encrypted messaging for group chat or media messages, but we’ll be rolling out support for those next, in addition to support for more client platforms. We’ll also be surfacing options for key verification in clients as the protocol integrations are completed.
WhatsApp runs on an incredible number of mobile platforms, so full deployment will be an incremental process as we add TextSecure protocol support into each WhatsApp client platform. We have a ways to go until all mobile platforms are fully supported, but we are moving quickly towards a world where all WhatsApp users will get end-to-end encryption by default.
This is still the beginning
We’re continuing to develop the TextSecure app [2], and our roadmap for our own products remains unchanged. We’ve been working with WhatsApp for the past half year, and have learned a lot through the process of deploying the TextSecure protocol at the scale of hundreds of millions of users. We’re excited to incorporate what we’ve learned from this integration into our future design decisions, and to bring this experience to bear on integrations that we do with other companies and products in the future.
We believe that by continuing to advance the state of the art for frictionless private communication with open source software, open protocols, and simple libraries, we’ll have additional opportunities to support mass adoption of end-to-end encryption.
WhatsApp deserves enormous praise for devoting considerable time and effort to this project. Even though we’re still at the beginning of the rollout, we believe this already represents the largest deployment of end-to-end encrypted communication in history. Brian Acton and the WhatsApp engineering team has been amazing to work with. Their devotion to the project as well as their thoroughness in getting this done are inspiring in a world where so many other companies are focused on surveillance instead of privacy.
Get involved!
If you’d like to participate in Open Whisper Systems, there are still a few more days to apply to Winter Of Code [3], our retreat in Hawaii this January. Or check out our Android [4], iOS [5], and browser [6] clients on GitHub to join in on development.
If you’d like to donate to Open Whisper Systems, we accept Bitcoin donations [7] that are automatically paid out to each merged PR via BitHub [8]. You can also make tax-deductible donations by credit card through the Freedom Of The Press Foundation here [9].
This is a huge improvement and I'm very glad that WhatsApp is going this route.
However, from my point of view, TextSecure isn't there yet. The ideal solution should be decentralized, like XMPP. That makes gathering meta data so much harder.
You're going to be pretty unhappy (or pretty uninformed) if every time a subject matter expert in security starts a project, you have to discount everything they say about everything in the space their project is in.
Yes, I'm going to go ahead and say "zero conflict of interest". Also: he's simply correct. If you'd like to rebut what he said about Telegram, actually rebut it.
Don't be insulted because there is a conflict of interest. Remember: "The presence of a conflict of interest is independent of the occurrence of impropriety." Some truly awesome people have had conflicts of interest and it's still appropriate to note them. Freely admitting a conflict of interest can in fact enhance your reputation.
Sorry for the misclicked downvote (to the post I'm replying to).
It is very plausible (from my rando perspective) thatq moxie's reaction was greater than it would have been for some other badly done security. But it's also plausible that it's just frustrating to be working on something and then seeing a well-funded attempt to obliterate any good that you might be doing. Which is what Telegram was. Is it a "conflict of interest", if your interests are for secure messaging to become widely used, to attack those which are, thanks to their ineptitude and funding, a plausible threat to your goal? Taking the words "conflict of interest" literally, yes, but it's not an ulterior interest the way the phrase is usually applied.
Telegram was also doing a really good job of pushing buttons, going off about how they had Math PhD's.
Edit: Hold on, you're saying there was a conflict of interest, in the past, because he's working with WhatsApp now? Do you have any personal knowledge of the timeline here?
> You have down voted me to the bottom of hacker news
People can not down vote replies to their comments. People have a single downvote. If you see more than one downvote then more than one person is down voting you.
Since you've quoted my whole comment in a comment lateral to it rather than a response, I've again deleted mine. Readers can see what I wrote in yours. I stand by everything I said.
Congrats Moxie and team. You guys are doing a great thing for humanity.