Stefan Lehmann


Public, private and confidential calendar events and how to use them properly

Anyone using a calendar program today to manage events can make them available on various devices via an iCal server. This way you have your appointments under control at any time. The function of the server is often performed by corresponding calendar services from Apple, Google, Microsoft and many other providers. However, if you want to share your calendars with colleagues or friends, sooner or later you will have a serious privacy problem.

Just like me, people will ask themselves: Should this or that event of my shared calendar really be public or what will colleagues say if their calendars are flooded with appointments that have no relevance for them? After a short thought I had a seemingly simple solution. I simply used a second calendar to which all events are added that nobody needs to know about. But if my colleagues should still know that I am not available on a certain day for a certain time, I don't stand a chance with this solution. After all, I would have to maintain the relevant appointment twice in the private and shared calendar, which inevitably leads to confusion when making changes.

Actually there is a reasonable approach for this scenario in the specification RFC 5545 , the standard exchange format of all online calendar solutions. Here the access classification, i.e. the access setting, is mentioned. As part of the basic security system, this property should enable the owner to control access to a specific calendar entry. The following three values are provided: "PUBLIC" for public, "CONFIDENTIAL" for confidential or "PRIVATE" for private events. Unfortunately, there is no clear definition how the program has to be implemented to reach this goal or what a confidential calendar event ultimately is. The implementation in the calendar services is accordingly different.

In the Google calendar, also on Android, you can assign the so-called "Privacy" status "Public", "Standard" and "Private" to events. However, the Google service on the server side interprets these entries according to its own preferences. Although the "Standard" assigns the property CONFIDENTIAL to the event, a subscriber with appropriate rights can view all event details in the respective calendar and even update it.

Apple does not make it better, on the contrary. For whatever reason, they keep the choice of private and confidential events completely free for their customers. There are also no alternative programs or apps to Apple's own calendar management that would make the feature available. All potential alternatives are based on the same calendar management of OS X and iOS and therefore offer no added value.

Actually it is obvious how the functionality should be implemented to meet the specification and to solve the problem I described at the beginning. Based on the value "CONFIDENTIAL", the iCal server delivers confidential events in "blackened" form to all subscribers of the shared calendar. They appear in the calendar client as entries where the title is replaced by "XY is busy". In addition, the location and the description, which would allow conclusions about the event, are not delivered. The server prevents the calendar event in question from being updated, regardless of the subscriber's individual editing rights in the shared calendar. Private events are only delivered to the owner of the calendar. This ensures that event information declared as non-public does not leave the server if the requesting calendar client is not the owner.

In search of a solution that provides this functionality, I stumbled upon ownCloud some time ago. This up-and-coming open source project based on PHP is, according to its own statement, a "file sync and share solution for companies and organizations" that has a calendar interface (Cal-DAV). Since version 5, privacy settings in the calendar are also supported, although here too, not without inconsistencies. But the freely available source code allows to customize the functionality as desired and to create a workaround for the missing support by Mac clients. Another positive side-effect: You stay in control of your data, because the system is hosted on your own webspace/server. And in addition to the calendar function, ownCloud offers a number of other interesting features that may be quite useful.

A customized version of the ownCloud calendar extension (internally called app) can be downloaded here. It works with the current ownCloud version (5.0.5). To install it, simply replace the supplied calendar app.

For calendar programs that already support the CLASS attribute, there is not much to say about how it works. You can change the privacy setting as desired using the program's settings options. This works wonderfully for the calendar app on Android 4 and in Thunderbird.

For Mac users who can't set privacy settings, I have introduced two shortcuts that precede the event title. The modified ownCloud calendar server recognizes by the abbreviation "P: " for PRIVATE and "C: " for CONFIDENTIAL which privacy setting should be defined. If you want to create a private event that you want to keep secret in the shared calendar, you have to specify e.g. "P: My private event title" as title. For Confidential Events, where all other subscribers should only know that you are busy, but not what you are doing, you have to enter e.g. "C: My Confidential Event Title" in the title field. If none of the abbreviations is used, you will get a public calendar event. The privacy setting can be adjusted by the owner at any time by adding, removing or changing the shortcuts.

The abbreviations can also be used in all other calendar clients.

Stefan Lehmann


Stay up to date!

With the newsletter, which is published 4 times a year, you will receive the latest news from our agency every 3 months. We will not use your e-mail address for any other purposes and you can easily unsubscribe from the newsletter at any time via a link in the mail footer.

Thank you! Your submission has been received!
Oh! Something didn't work. Please try again.