Handling of private/confidential groupware objects

[Bernhard Reiter]

Hi Johannes,
thanks for joining the discussion.

Am Montag, 23. Januar 2006 11:52 schrieb Johannes Hirche:
> > My criticism boils down to:
> >    - adding a hidden folder semantic, will make things
> >      more complicated especially for other clients.
> >      Together with access control, this means less security.
>
> Why would this mean less security? It will get more
> complicated, that is true, even for the real kolab clients.

complexity is the number one foe of security.
(E.g. see Schneier and Ferguson, Practical Cryptography, 
to motivate the top ranking.)
We should try really hard to keep it as simple as we can.

BTW: I consider any client that can handle the Kolab procedures 
in a nice way, a "real" Kolab client. 

> >    - We need to solve the reminder issue for other folders anyway,
> >      otherwise we never get over this Outlook limitation. As we need
> >      to solve this anyway on the connector side, this even might be
> >      less work in the end.
>
> Why does it have to be solved in the Outlook side? 

One reason for this is that KDE Kolab clients can create more folders
and that users want to have project folders without the need to
copy the appointments each time.
So the "other" folders are out there already, wanted and useful.
No matter how we solve the privacy issue, this problem will
remain. So if the solution for the other calendars also solves
the privacy issue, we save work.

> Outlook 
> behaves very focused on the single calendar it considers
> important. Even if the reminders get fixed, we would still
> have to workaround and reverse engineer the LocalFreebusy
> (which is a nightmare), or a user would always have to
> invite himself with a different email adress so that Outlook
> performs a freebusy lookup on the server. Otherwise Outlook
> will only rely on his own freebusy cache.

Good point I have not had in mind so far
(and was lacking from Martin's write ups, so far I remember.)

> Another thing which is really hard to fix is placement of
> new calendar items, Outlook will always put them in the
> default calendar. The user would have to manually move them
> around every time.

True, the usability is sometimes not the best with Outlook, 
my hope is that Outlook will further improve the usability of several 
calendars. The situation is not that bad, especially not on Outlook 2003.
You can directly click on the calendar and the appointment will be in there.
Of course with responses and invitations, this is not as nice as it could be.

> > I guess that most PDAs will not know about several calendars and
> > will disregard some options that Outlook(+connectors) and the KDE Kolab
> > Client can deal with. The only way to solve this in my opinion is to
> > somehow establish a connection from the appointment saved
> > to the smaller device and the mapping of capabilities.
> > Example:
> > My personal folder appointment will be saved to the PDA only calendar,
> > but getting the category "personal folder", so that syncing it back will
> > put it in the right folder.
>
> How would you establish this connection? 

Use a unique ID for the item and have a list of the capabilities of the
PDA model.

> We have no control 
> whatsoever over the pdas, in fact it is really hard to tell
> if it's Outlook talking to us or some FoobarSync client, as
> they all use mapi.
> So if there are multiple relevant calendars, how should we
> present them to the PDAs. If the user wants all the calendar
> entries we have to manually merge them and present the
> merged view to the PDA. 

Yes, you are right in that a merged view (a temporary calendar
or so) would be needed to make the Sync code on windows to pick this up.
My thoughts were going in the direction of how to really solve the
sync problem and if the current sync application on windows 
do not solve this principle problem, we are a bit lost out in the cold
unless we want to do the syncronisation ourselfs.
Thinking about this, this clearly speaks in favour of doing the sync
with the server. This is what users want anyway and then we are not
bound on the current sync code limitations. 

> And given that we can't be even 
> sure that its the PDA we're talking to, this is quite
> unfeasible. PDAs with only one calendar (which is the
> majority these days, but that will probably change in the
> future) won't cope with multiple calendars in the profile.

As far as I have thought, I think that the problem with 
one-calendar-only PDAs can be solved on the sync code level.

> > > > The Outlook way of enforcing this in the client
> > > > can be used as another reason to explain this change
> > > > to users.
> > >
> > > Yes, but my proposal would solve the issue in a doable and secure way
> > > while keeping the well established semantics working.
> >
> > I agree that it is doable,
> > for the reasons above I think that doing it differently will be even
> > more secure, because of a structure which is easier to understand
> > for users.
>
> I don't think it's easier to understand, at least for users
> of Outlook XP and earlier as it doesn't have the
> split-calendar view feature of Outlook 2003 (showing two
> or more calendars side by side). A user would have to switch
> between the calendars all the time.

You have to take into account that people will need to understand
the ACL settings per folder anyway. They and especially the IT crew
of an organisation using Kolab must understand what "private"
really means. 

> I personally would like a per object security (possibly
> through encryption) but that would probably be management
> hell (forgotten passwords and whatever). 

Actually I started to like the idea of thinking about security policies
only on a folder basis. Object security seems to be too hard to understand
for many users, if I remember the research about ACLs in filesystems
and operating systems.

Encryption on the emails using S/MIME or OpenPGP would protect
against administrator, too. (Rarely will actually raise security)
Even this I would currently model on a per folder basis. 

> A hidden folder 
> would be painful, but - at least for Outlook clients - the
> more straightforward than making Outlook behave differently.

How you you propose to solve the other folder with reminders
(and freebusy information) problem then?
Currently I have seen organisations that will create the (non-technical)
policy that any work appointment needs to be copied in the appropriate
group account with Outlook/Exchange. Know with Kolab they can
stop doing this, but get the problems with the reminders and their local
freebusy lists.

Bernhard