Handling of private/confidential groupware objects
Martin Konold
martin.konold at erfrakon.de
Wed Nov 30 05:25:30 CET 2005
Hi,
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
functional.
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.
Example:
boss/calendar
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
boss/calendar.private
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.
Yours,
-- martin
--
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
More information about the format
mailing list