Skype is following your links – that’s proprietary for you

Yesterday it was reported that Skype, owned by Microsoft these days, seems to automatically follow each exchanged https link. Besides the fact that this is a huge security and personal rights problem in its own it again shows how important it is to not trust a proprietary system.

The problem, skin deep

Heise reported yesterday that Skype follows https links which have been exchanged in chats on a regular basis. First and foremost, this is a privacy issue: it looks like Skype, and thus Microsoft, scans your chat history and acts based on these findings on a regular base. That cannot be explained by “security measures” or anything like it and is not acceptable. My personal data are mine, and Microsoft should not have anything to do with as long as there is no need!

Second, there is the security problem: imagine you are exchanging private links, or even links containing passwords and usernames for direct access (you shouldn’t, but sometimes you have to). Microsoft does follows these links -and therefore gains full access to all data hidden there. Imagine these are sensitive data (private or business), you have no idea what Microsoft is going to do with them.

Third, there is the disturbing part: Microsoft only follows the https links, only the encrypted URLs. If this action would be a security thing, they would surely follow the http links as well. So there must be another explanation – but which one? It is disturbing to know that Microsoft has a motivation to regularly follow links to specifically secured content.

The problem, profound

While these news are shocking, the root problem is not Skype or the behavior of Microsoft – I am pretty sure that their Licence Agreement will cover such actions. And it is most likely that others like WhatsApp, Facebook Chat or whatnot do behave in similar ways. So the actual problem is handing over all your data to a company which you have no inside to. You have no idea what they are doing, you have no control about it, and you cannot even be sure that nothing bad is done with it. Also, most vendors try to lock you in with your service, so that switching away from them is painfully due to used workflows, tools and social networks.

The solution

From my point of view, my personal perfect solution is hosting such sensitive services on my own. However, that cannot be a solution for everyone, and I for myself cannot provide for example the SLAs others need.

Thus I guess the best solution is to be conscious about what you do – and what the consequences are. Try to avoid proprietary solutions where possible. For example for chats, try to use open protocols like XMPP. Google Talk is a good example here: company based, but still using open protocols, they even push the development forward (Jingle, …). Or, if you upload files to web services, make sure you have local backup. Also, try not to upload sensitive data – if you have to, encrypt it beforehand. And if you use social networks, try to not depend on one of them too much, use cross posts for various services at the same time if possible.

And, last but not least: ask your service providers to establish transparency and rules for a responsible and acceptable usage of your data. After all, they depend on the users trust, and if enough users are requesting such changes, they will have to follow.

Google & ActiveSync, Microsoft & CalDav: Pure irony

Today 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?

Stunned by the friendliness of a stranger

Since I decided to blog again a couple of days ago I was always asked by WordPress to publish my posts in twitter as well. However, I didn’t have a twitter account and thus never really gave it any thought.

Today I had some spare time, and decided to go for it and looked for twitter.com/liquidat – and it was taken. The account was abandoned, the last tweet was from years ago, and it was obvious that the company behind it already used another, better fitting twitter account. But, nevertheless, the name was taken.

So what to do? I use my nick name “liquidat” almost everywhere, from Wikipedia over WordPress to GitHub and whatnot, and somehow I didn’t want to use another nick name for twitter. So I decided to write the people behind the twitter account if they somehow would be willing to let me have the twitter name. I went to company website, used the contact form and asked kindly – not expecting any response, and not at all a positive one, since this is a company on another continent, thousands of kilometers away.

But today I got the answer – and it was positive:

No problem. Is a pleasure help you.
[...]
I wish your success.

And in a second mail, it became even better:

Hi! This is a chain. I do well for you, you do good for someone and that
someone does for someone else, and one day your turn will come you again.
Be happy

I am stunned. And speechless. And can hardly believe the fact that this person actually decided to help me. And that the reason behind it was a reason I try to live myself: helping others where you can so that they help others, to make this blue marble a better place. To actually help someone you never met and most likely will never meet who is living thousands of kilometers away, is a beautiful thing to do. And just gave me a bit more faith in humanity.

So: I am now on twitter as liquidat. And that is due to the kindliness and friendliness of the people at liquidation.com.br. I wish them all the best, and best regards!

So there are people who want to make this a better place. I like that =)

Why Android cannot sync multiple calendars via ActiveSync

If you use ActiveSync on your Android device you are not able to sync more than one calendar. The reason is the missing support in the ActiveSync implementation of Android.

Using Android multiple calendars is not a problem at all – as long as you use Google Calendars. However, in business environments – or if you want to keep your data private – it might happen that you want to use your own calendar server. In such cases the sync is most often done via ActiveSync – and there multiple calendars cannot be synced, see for example Google code issue #36797. Of course, there are also other protocols like CalDav, but unfortunately Android does not support these natively.

There are lot of discussions out there why this does not work, and the situation is not simplified by the fact that there are various ActiveSync implementations on server side and even on mobile side (Samsung ActiveSync vs Google ActiveSync, etc.). But for plain Android, the situation is clear: the code lacks the ability.

The Exchange ActiveSync protocol specifies types of folders – like one type for the default mailbox, one for user created mail folders, etc. And while Android does know the type “12, User-created Mail folder”, it does not know the type “13, User-created Calendar folder”. It does not know “14, User-created Contacts folder” either, by the way. It’s simply not implemented in the class “FolderSyncParser”. Just check the list in line 60-75, and compare it to the above given type numbers.

Thus you are not able to natively sync multiple calendars with plain Android and ActiveSync. If you really need it, you have to use one of the many, many hacks: export to Google calendars, create one user for each calendar on the server side, etc. – or use another protocol like CalDav which is not natively supported in Android but can be added by 3rd party tools.

I do hope that Google implements multi calendar sync via ActiveSync (or CalDav, speaking about) at some point in the future. I find the feature of multiple calendars extremely helpful in the daily office routine. But then again, there would be one reason less to use Google calendars on Android phones, so it might be that this is a political decision.

Open Source Groupware checklists

In the last months and years I had to deal with various requirements people have regarding groupware ecosystems. Open Source solutions have matured in this area and this article highlights some needs, but also some common pitfalls.

Preface

In these days there are many excellent Open Source groupware solutions out there. Two well developed solutions I saw in several productive environments are Zarafa and Open-XChange. Both of them are ready to replace Exchange in various productive setups, and I have seen both being deployed successfully as either Exchange replacement or even as a fresh groupware installation for growing offices and working groups.

Also the connection to the mobile world is common as well these days – thanks to z-push and the likes. Yes, there are some licence issues and I would prefer to use a CalDav solution. But ActiveSync works with open source tools pretty well.

However, there are still weaknesses in the Open Source groupware ecosystem. A big one is the Open Source fat client. Most of the clients (Evolution, Thunderbird and Kmail) do not work flawlessly with the currently available Open Source groupwares. Most of the services these days move to web clients anyway, but it is sad to see that there is hardly a well working groupware server fat client setup out there.

For example, in my personal working spaces I do need to sync Evolution with Zarafa, and KMail with OX. And in both setups there are components which do not work at all.

The needs

To better estimate the quality of a groupware solution here is a list of what such a solution should be able to provide:

• Multiple address books and their synchronisation.
• Multiple calendars and their synchronisation.
• Different user rights per calendar.
• The ability to overlay different calendars on the client side.
• E-Mail-Invitations for appointments.
• Free/Busy lists for other users, visible in the calendar view.
• Collision handling whenever the problem comes up.
• Centralized web interface for all components,
• Support for sync of ToDos.

There is no need that one server does that all on its own. The address book could be delivered by ldap, and there are good calendar servers out there like DAViCal.

But even if this list does look pretty normal, some of the points are not covered by the solutions out there. For example: You cannot share multiple calendars with your Zarafa server and your mobile phone without using some ugly hacks. Also, the collision handling is often automatically, the user does not even notice any problems. Another problem is that hardly any solution can sync ToDos properly. And, of course, hardly any of the solutions out there supports Linux based fat clients properly.

Some common tests and problems

But even if a groupware solutions states on paper that it fulfills all the mentioned needs, it might fail in the day-to-day routine. Thus here are some quick tests and common problems which can be checked on demo or test installations to get a first impression:

• Are multiple-day, recurring events synced correctly?
• Are multiple-day, recurring events still correct after changed again and again on both sides?
• Create a calendar with 40k entries, and sync it. How long does the re-sync take after some changes?
• Are ToDos synced together with their due dates?
• Let user B alter calendar entries of user A and check if these changes are properly synced.
• Create a collision on purpose: is the problem solved or is the entry doubled? Is the user notified of the collision?

As mentioned, this list is just to get a first impression. If you are going to become serious about a new groupware, you have to analyze your workflows, and test the groupware ecosystem against these. I must say that most often the biggest challenge actually was to comprehensively identify all workflows! So don’t underestimate the importance of that, and how much time that task takes.

And, with all these tests: keep in mind that sometimes flaws only begin to show under heavy load. Don’t test with two calendar entries and one address book entry and be happy because that minimum setup works!

The solution

As with most real world setups, you should work two-fold: first, check what features you really need, and compare them against the stated features of each groupware ecosystem. Afterwards, pick the survivors and test them against the workflows you have in your daily routine. Don’t trust and hope.