Handling of private/confidential groupware objects

Bernhard Reiter bernhard at intevation.de
Wed Feb 22 18:30:12 CET 2006


Hi Johannes,

take my appologies for not answering earlier.

Am Mittwoch, 25. Januar 2006 19:28 schrieb Johannes Hirche:

> > complexity is the number one foe of security.

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

It would be good to have some consensus,
I think Joon's proposal might not be that bad afterall,
but I have not thought about all implications yet.

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

But we can sure try.
Even in a few small groups I could observe that people really like the 
modeling abilities the ACLs on the folders give them.
Making this work better in Outlook would benefit all users, I think.

Obviously it stays a question if it can be done realisticly.

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

I guess there is no way to make Outlook behave differently at this particular 
point and just always grab the remote freebusy list?

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

For the sake of the argument:
If (in theory) we would use a direct connection between mobile device
and the server, Outlook would be out of the question.

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

No I mean writing a server client that can directly sync with the PDAs,
without involving Outlook or Windows at all.
Funambol claims to habe something like this, but this need inspection
to see if this is real.

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

Hard to say how difficult it is, as you can offer feature as part 
of the deail which they did not have before, like using severl calenders
without must to copy them into a section account.
If the new features are more useful, users might forget the other flaw.

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

Protection my personal information against others, 
could be labled security.
Being the master of your own data is a very good principle.
Kolab clients with a multi-account, multi-folder capability 
could offer a lot more than other contemporary solutions.

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

I consider storing the secret key in the directory service
a bad idea. The only reason for me to encrypt would be
to protect against the server administrators.
And this is way to much as we would need for a private confidential
attribute.

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

I have a users that want it for a while now. :)
As for reminders I think it might even be easier to implement
a seperate handling for it.

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

To me this is connected as offering a solution to work
with private objects would solve the problem for most of the users.

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

If the folder approach is taken, I think this might be a better way
of doing it, compared to the hidden folder idea.

Given it some thoughts, Joons and your double-folder proposal
will both be easier to implement then to solve the multiple-folder
problem regarding fblists, reminders, handling and PDAs.

Best,
Bernhard




More information about the format mailing list