Handling of private/confidential groupware objects

[Bernhard Reiter]

Am Mittwoch, 30. November 2005 05:25 schrieb Martin Konold:
> 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.

The "privat" flag is a marker in Kontact 
and for Outlook it is also some access control switch. 
(This has been known during the Proko2 contract, 
so it is not news.)

> 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.

Potentially, the user has his client under control,
so you cannot enforce things on the client.

> 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....

Using encryption will be the way for very strong settings, 
where protection again the administrators is wanted.
Technically we are basically there from the format except for a few ends:
a multipart/encrypted could just include the other mime parts
of the storage function format.
The fb lists could be uploaded for this particular folder.
Both will be very hard to implement on Outlook clients.

> 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.

Using a hidden folder will pose problems.
And we might need more than one folder for other ACLs.

Currently the user can just create other folders, e.g. boss/calendar/privatea
and then manually deal with the ACLs.
This makes the picture consistant as now OL will also only have a marker.


> 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.

Outlook cannot do this currently, 
so I prefer sticking with the current solution 0,
that the user needs to do this manually, and with Outlook/Kolab Server,
the "privat" flag will only be a marker.

> 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.

I prefer solution 0 (which we already have),
it makes the picture much more consistant and simpler,
which are core qualities of good secure solutions.

Bernhard