Handling of private/confidential groupware objects

Martin Konold martin.konold at erfrakon.de
Wed Nov 30 05:25:30 CET 2005


The GUI of both Outlook and Kontact offer the possibility to make some 
groupware objects private/confidential.

Due to the fact that Kolab handles access control on the folder level not on 
the object level the private/confidential is stored in the xml but not 

This is a problem with potential security/privacy issues if a folder is shared 
with other users.

Basically I am aware of three different approaches to the issue.

1. Honour the privacy setting in the client

This is what Bynari is trying to implement in their most recent development. 
IMHO this approach is conceptionally flawed as it provides a false impression 
of security and the information is leaked easily using other IMAP clients 
like Thunderbird.

2. Use encryption to protect the sensitive data

This is a very straight approach. Using encryption indeed will protect the 
privacy. The biggest challenge here are on one hand the effort to implement 
this in the clients. (only parts of the message shall be encrypted as some 
other parts are required for creating the fb information...). 

On the other hand the required key handling is a major usability problem. How 
to make the key roaming. What to do if key is lost....

3. Use a second folder namespace for the private/confidential items and well 
understood ACLs

This means that for groupware folders e.g. Calendar or Contacts we create a 
hidden extra folder on demand.



user boss is granting user secretary access to her calendar using ACLs

When boss creates a private appointment for the first time the client creates 
a new folder


This folder shall be hidden in the GUI of the client and the if the client has 
access to the private folder (in our case only boss) the events shall be 
_merged_ in the calendar.

Technically this means that the security is implemented on the server while 
the presentation/user interaction is implemented on the client.

What do you think?

I personally tend to prefer solution 3.
-- martin

Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker

More information about the format mailing list