Handling of private/confidential groupware objects

[Johannes Hirche]

Hi!

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

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

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

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

The problem with private items is actually much broader, as
every single Outlook object (contact, task, even mail) can
be marked as private. It is no real security of course as
it's the client that hides those entries (in an exchange
scenario) but the user is used to it and expects it to work
that way nonetheless.
Calendars are the most complicated though as a lot of
side effects are triggered by it.

I personally would like a per object security (possibly
through encryption) but that would probably be management
hell (forgotten passwords and whatever). A hidden folder
would be painful, but - at least for Outlook clients - the
more straightforward than making Outlook behave differently.


Greets

--

Dr. Johannes Hirche
KONSEC  GmbH