Handling of private/confidential groupware objects

[Johannes Hirche]

Hi,

> Hi Johannes,
> thanks for joining the discussion.

and thanks for the warm welcome.

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

That is of course always correct.
I wouldn't be overly happy to split the representation of
one folder into multiple physical folders, as it adds loads
of complexity, on the other hand I need some solution for
the whole issue and I would like to see some consensus
about how we should do it.

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

Yes, but on the other hand the KDE Kolab clients can be far
more flexible as opposed to Outlook, where we have
rather limited influence.

The problem here are also the differing needs of small
groups, say some ten users, and large corporate
installations with hundreds or thousands of clients. A small
group will most likely want the features Outlook offers now,
with per object security and only few folders and very
simple procedures for the users.

A large installation with many projects and groups and
corresponding group calendars will have far more complex
procedures and rules. It can be rather difficult to bring
these in sync.

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

There are a number of things which are really hard to do
or hard to change in Outlook as they happen outside of mapi
or rely on binary black box data.
The reminders, freebusy, recurrences(those are reverse
engineered, but still horrible) are only examples of that.

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

The unique ID is already there, but as I pointed out, it is
more or less impossible to safely detect who it is we're
talking to, and to behave differently according to that.
Hotsync for example probably uses cdo, which in turn routes
calls through an Outlook process which then performs the low
level mapi calls.

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

Indeed. The major pda sync clients in use are completely
usuitable for this, they are fully adapted to the
single-folder concept of Outlook with per-object pseudo
security.

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

You mean writing a Windows sync client for pdas? Who would
want to do that, it's a major chore. However, I'm not really
up to date as to how well available (open source) sync
clients (if there are any for windows) perform. Adopting one
of those might be an option for some users.

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

Yes, I think it can probably only be solved through own sync
code if we stick to per-folder access rights.

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

The sharing of a folder is pretty obvious to most, as it
corresponds pretty well to the window file sharing
semantics. Teaching them that a private flag is not what
they expect is probably harder. It is even worse, as we're
taking away a feature they used to have.


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

We're not talking about real security here, though, it's
merely privacy. If the encryption key is stored in the ldap
directory for example it wouldn't protect against the
administrator and there would be no issues with lost
passwords as the users aren't even aware they exist.


> How you you propose to solve the other folder with reminders
> (and freebusy information) problem then?

Well, if a sufficient amount users need that feature it has
to be done of course. It will be rather annoying though, as
Outlook whines every single time a user creates an
appointment in a non-default calendar and turns on the
reminder for it. It will show a dialog box warning the user
that this reminder won't be shown as it is not in the
default calendar and asking if the user is ok with that,
rendering it pretty unusable in that case.

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

Yes, I understand that perfectly, it does make a lot of
sense.

So we're having to issues at hand here. One is generic
support for reminders/freebusy of (non-default) calendars,
which has to be supported, but is (at least with us) not of
the highest priority as Outlook handles that case pretty
badly anyway.

The other is support for per-object privacy. I assume that
Joon would also like to see some policy for it, as they
implemented something similar in the past.

If it's only about the private/public items in a calendar,
another option would be to always create two imap folders,
calendar-public and calendar-private, and display a merged
view in Outlook and place its items depending on the flag in
one or the other imap folder. Other more flexible clients
could choose to display them seperately. If that folder is
shared (in the Outlook world), only the public folder is
shared, a client would have to ensure that the private
folder stays that way. This would be more transparent to the
user than a hidden folder I guess. Technically this is more
or less the same as the hidden folder approach, but maybe
less confusing.

Greets


--

Dr. Johannes Hirche
KONSEC  GmbH