Current distribution of WhatsApp alternatives [Update]

Android_robotMany people are discussing alternatives to WhatsApp right now. Here I just track how many installations the currently discussed, crypto-enabled alternatives have according to the app store.

WhatsApp was already bad before Facebook acquired it. But at least now people woke up and are considering secure alternatives. Yes, this move could have come earlier, but I do welcome the new opportunity: its the first time wide spread encryption actually has a chance in the consumer market. So for most of the people out there the question is more “which alternative should I use” instead of “should I use one”. Right now I do not have the faintest idea which alternative with crypto support will make the break through – but you could say I am well prepare.

Screenshot installed instant messengers
Screenshot installed instant messengers

Well – that’s obviously not a long term solution. Thus, to shed some light on the various alternatives and how they stand right now, here is a quick statistical overview:

Secure Instant Messengers, state updated 2014-03-11
Name WebPage/GooglePlay installed devices Ratings Google +1
ChatSecure Website / Google Play 100 000 – 500 000 1 626 2 620
Kontalk Website / Google Play 10 000 – 50 000 237 265
surespot Website / Google Play 50 000 – 100 000 531 632
Telegram Website / Google Play 10 000 000 – 50 000 000 273 089 97 641
Threema Website / Google Play 500 000 – 1 000 000 9 368 12 594
TextSecure Website / Google Play 100 000 – 500 000 2 478 2 589

The statistics are taken from Google’s Android Play Store. I would love to include iTunes statistics, but it seems they are not provided via the web page. If you know how to gather them please drop me a note and I’ll include them here.

These numbers just help to show how fat an application is spread – it does not say anything about the quality. For example Threema is not Open Source and thus not a real alternative. So, if you want to know more details about the various options, please read appropriate reviews like the one from MissingM.


Android 4.4 now *can* sync multiple calendars via ActiveSync

Android_robotWith the release of Android 4.4 called KitKat Google made some interesting changes to their ActiveSync implementation: the code is now set up to sync more than one calender, and the first KitKat user already confirmed that new feature.

In February I described in a blogpost why Android cannot sync multiple calendars via ActiveSync. The problem was that Google did not implement the necessary parts of the ActiveSync specification in Android.

However, that seems to have changed: if you look at the current ActiveSync implementation of Android 4.4 KitKat, the source code (tag 4.4rc1) does list support for multiple calendars – and also for multiple address books:


I had no chance yet to test that on my own, but there are reports that it is indeed working:

Today i flashed a Android 4.4 Rom on my smartphone. After adding the Exchange Profile all my Calendars are there […]
I’ve uploaded a screenshot here:

Looks like Google actually listened to…erm, corporate users? At least to someone, though 😉

But: Since I have no first-hand-experience in this regard I would like to ask all of my nine readers out there if anyone has a stock KitKat running and if the could check this feature. Please test this and leave a report about your experiences in the comments. I will include it in the article.

By the way, the above mentioned source code snippet also tells quite exactly which other ActiveSync functions are not yet supported in Android:


I guess syncing tasks could come in handy in corporate environments. Combined with support for multiple task folders you could even design your own Kanban “board” that way.

Nevertheless I’d like to add that ActiveSync is no big deal for me anymore because I am very happy with a – albeit 3rd party and not yet Open Source – CalDav implementation, which can even sync multiple task folders.

Google continues CalDav support for everyone, now also adds CardDav

Android_robotYesterday Google announced that it will not restrict the CalDav access to their calendars to registered partners only, but that they will continue to provide it for everyone. Additionally, Google now offers CardDav support.

A couple of weeks ago Google announced that they would restrict CalDav access to their calendars to registered developers only. That resulted in a huge uproar among developers, users and open standards advocates and made many people wondering if Google will become a closed standards/software company in the future.

However, the pressure (and most likely the bad press and reputation) Google got worked, and they announced that the CalDav API will be continued as an API open for everyone:

In response to those requests, we are keeping the CalDAV API public.

And it becomes even better: CardDav support is added as well, meaning the address data can be accessed via open protocols as well:

And in the spirit of openness, today we’re also making CardDAV – an open standard for accessing contact information across the web – available to everyone for the first time.

This way CalDav and CardDav have an even better chance to become THE royalty free and open alternative to Microsoft’s ActiveSync protocol. Additionally, application developers don’t have to worry to add special code to support Google calendars and address books: they just add CalDav and CardDav support and they automatically support almost all groupware servers and services available.

This is good news and gives me back some trust in Google’s policies and priorities. There is still no CalDav or CardDav support in Android, yes – but at least the server side is better now.

[Howto] Installing Owncloud News, a self hosted RSS reader

two_glossy_cloudsOwncloud News, a RSS news reader for the self hosting cloud service Owncloud, is available in an Alpha version. That comes right at the time Google Reader is bound to see its end soon.

I must admit that I do not understand why Google decided to shut down the Google Reader service. Social media with their unstructured news areas are nice, but no match to a well structured news feed full of read and unread news. But, there are replacements, and one pretty wise choice would be to not depend on yet another web service, but to host it yourself.

In comes Owncloud: it can already host your addresses, calendars, files and musik and can be integrated with your desktop as well. Now a RSS reader app, Owncloud News was released as an Alpha version, and indeed already looks promising:


The installation is pretty smooth as well. The requirements are a running Owncloud 5 version, so 4.5 won’t do it. The installation itself basically consists of two steps: installing and activating the so called App Framework, which is supposed to be the foundation for other Owncloud apps in the future, and afterwards installing the news app itself:

# cd /var/www
# git clone
Cloning into 'appframework'...
# git clone
Cloning into 'news'...

I choose /var/www here because it is recommended in the manual and because there the appropriate user has the necessary access rights. But it could be any dir, since you only link the plugins anyway:

# ln -s /var/www/appframework /var/www/owncloud/apps
# ln -s /var/www/news /var/www/owncloud/apps

Speaking about rights, make sure the web server can write cache files:

# sudo chown -R www-data:www-data /var/www/news/cache

Afterwards, login to your owncloud, and active the plugins: first the framework, followed by the actual application. Add feeds, play around, as you will see it works pretty nice.

What is still missing right now is an Android news reader which could sync with the server. When that is available as well, Owncloud News might become *the* Google Reader descendant.

Pass – A perfect shell based password manager

920839987_135ba34fffPass is a tool to store and manage passwords and other data securely and on command line – even with built in support for Git and remote Git repositories. Thus it is a welcomed alternative for existing password managers which often require a GUI, or do not provide repository support.

What it is

Pass is a shell based password manager to store passwords and login data – or anything you want, actually. The name “the standard unix password manager” however is pretty misleading: the author wanted to stress that it only uses standard Unix tools, but failed to highlight that with a catchy name and instead just created confusion.

But the author is right with his main point: pass is in fact just gluing together already well known and tested Unix tools: the encryption of all information is ensured by GPG, passwords are queried using gpg-agent, the version control and remote repository support is done by Git, and the tool itself is written in shell code. Thus you have features you can rely on – in fact, if you want you can directly access the Git repository and the Gnupg files, you do not have to use Pass at all.

Pass stores information in simple files, which can be grouped in folders. While the main idea of Pass is to store one password in one file you can actually access each file with editors to store as many information in it as you want. Each file is encrypted with the gpg key which was defined during the initial setup of Pass. As a result the Pass database is nothing else but a folder full of other folders and gpg encrypted files:

$ ls -1 $HOME/.password-store
$ ls -1 $HOME/.password-store/business/

Pass is included in all major distributions like Fedora, Ubuntu, Debian, and so on, and thus can be installed with the usual package management tools.

How it works

If you call Pass without any further options, it just outputs the content of its password store:

$ pass
Password Store
|-- business
|   |--
|   |--
|   `--
|-- commerce
|   `-- amazon
|-- financial
|   |--
|   `--

The file type ending “gpg” is not shown here to not confuse users (I guess).

Showing the content of a file is straight forward:

$ pass business/
login:  example
pass:   password

Adding new entries can be done with the command pass insert $FOLDER/$FILENAME. But it might be more convenient to just use the default editor to edit a new file: pass edit $FOLDER/$FILENAME. That way multi line information can be added more easily.

However, the real strength of Pass is that after each change – like adding a new password – git-add and git-commit are called: the new file is automatically committed to a local git repository:

$ pass edit business/
[master 4c09c76] Added password for business/ using /usr/bin/vim.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 business/

As a result all changes are automatically under version control and can be reverted. But it gets better: Pass forwards arbitrary options and commands to Git itself. Thus it is possible to access the full functionality of Git – and to push the files to an online repository:

$ pass git push
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 823 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
   aa2aff7..2011296  master -> master

That way the password store can be shared with any remote Git repository – and thus can be re-used by other clients, given that they have the proper GPG key.

Missing pieces

As shown above Pass is almost perfect if you need a way to manage passwords (or any other data at all) on command line level, including repository and encryption support.

But while Pass replaced all my other password managers literally in a few minutes there is still one big feature I miss: the support for GUI tools! It would be nice if Pass support could be included in the major Desktop Environments and major GUI programs used in the Linux desktop world:

  • KDE’s Kwallet
  • Gnome’s Keyring
  • Android
  • Firefox
  • Chrome/Chromium

To summarize it: Pass is great, but would be even better if it could server as a backend for the usual GUI tools and desktop environments. There is already an experimental iOS client, so there is at least hope for an Android client…

Google & ActiveSync, Microsoft & CalDav: Pure irony

Android_robotToday Microsoft announced plans to implement CalDav and CardDav support in Windows Phone. That will enable users to still sync with Google services once these shut down their ActiveSync support in Summer. That is highly ironic and almost ridiculous, since Google itself does not support CalDav and CardDav in Android.

It all started with Google’s Winter cleaning: Google announced a couple of weeks ago that their services will soon be no longer offer an ActiveSync interface. That means: all client devices accessing Google’s services via ActiveSync need to switch to some other way of synching. Btw., read carefully: this has nothing to do with Android. Not at all! Also, iPhones don’t have to bother because they can simply switch to CalDav and CardDav which is natively supported in iOS. However, id does affect users of Microsoft’s Windows Phone. They only had ActiveSync as an option.

Now Microsoft announced they are going to implement CardDav and CalDav support in their Windows Phone. So that users can happily sync their Windows Phones with Google services.

And here comes the irony: Google itself does not support CalDav nor CardDav on client side. Google’s Android operating system does not offer it, not at all! Google only supports its own, proprietary sync way used in the Google apps, and has support for ActiveSync, albeit pretty limited support.

So, to summarize: Google forces others to use open standards which they do not support themselves.

While it is good that Microsoft is forced to implement open standards, Google’s acting nevertheless looks ridiculous, that is just sad. I wish Google would have the guts to just add CardDav and CalDav support and have a party with the people fighting for open standards. I mean, how bad would it look like if a Microsoft operating system would support open standards better than a Google operating system?

Short Tip: Generate SSL/TLS fingerprints to verify web page certificates

When you try to connect to a web server which has a certificate signed by an unknown root ca, you can compare the TLS/SSL fingerprint of the server with the one of the certificate. For example, if you use your Android phone to securely connect to your own server the phone might not have the root ca of your TLS certificate and thus presents you the fingerprint for you to verify.

Thus, beforehand you have to calculate the TLS fingerprint of the server certificate. This can be done with a single command:

# openssl x509 -noout -fingerprint -in /etc/pki/tls/certs/ 
SHA1 Fingerprint=84:C2:9D:59:47:23:A6:38:22:C0:0B:39:6D:A8:BB:D8:0B:7B:EA:09