Handling of private/confidential groupware objects

[Bernhard Reiter]

Hi Martin,

Am Donnerstag, 26. Januar 2006 05:12 schrieb Martin Konold:
> Am Mittwoch, 25. Januar 2006 12:37 schrieb Bernhard Reiter:

> I am unhappy how the discussion with you is evolving! It is
> counterproductive and wasting my time :-(

I am unhappy that you are unhappy and wasting my time.
Describing my arguments against your idea as "nonsense" 
or "ridiculous" is not just bad style, it also shows that you do not
understand what I was saying and your lack of ability to
convince me with real arguments.

> > Am Montag, 23. Januar 2006 23:29 schrieb Martin Konold:
> > > Am Montag, 23. Januar 2006 09:58 schrieb Bernhard Reiter:
> > > > This cannot be guarenteed as long as clients can set the ACL
> > > > of all the folders. A user _could_ set the ACL of the hidden folder
> > > > differently. Or do you think that we should add more protection
> > > > to the imapd implementation then?
> > >
> > > Well, if users shoot themself in the foot we cannot prevent them from
> > > doing so in the good old unix tradition. Though we could apply "self
> > > healing" semantics to the Kolab clients which can "fix" the wrong ACLs.
> > >
> > > IMHO trying to prevent intentional shooting the foot will in the end
> > > require TPM like architectures.
> >
> > well this is a general type argument which can be used in any direction.
> > We are discussing the how to make a good solution which is easy
> > enough to understand and use so that people will not shoot them
> > in their feet.
>
> This is nonsense. The "hidden" folders are hidden by default this means
> they are typically _not_ listed by Kolab clients and therefore are
> typically _not_ prone to unintentional ACL changes by the user.
>
> If a user chooses to use a non Kolab tool e.g. some arbitrary 3rd party
> client with IMAP ACLs setting capabilites and chooses to mess with the ACLs
> on the hidden folders (most don't allow _any_ ACL operations...) it is
> shooting herself in the foot.

So why not weight the chance that a user takes a regular IMAP client
and uses its operations? For LDAP you always make a huge point out
that we are using real LDAP ACLs and to do not put security in the client
implementation. Why not here?
Okay, maybe it is a point with small weight, but a real one.

> Calling my proposal a security issue due to the fact that users can use
> some non Kolab tool to actively set an ACL for other users/groups which
> allows access to formerly nonaccessable private data is ridiculous!.
>
> You: It hurts horribly if I go to the weapons shop, buy a gun, point at my
> foot and pull the trigger.
>
> Doctor: Well, a gun is a powerful tool. You have multiple choices here.
> Either don't obtain a gun or avoid pointing at your foot and last but not
> least never pull the trigger when pointing at your foot.

To stay in the picture: 
If you can do with less guns, you will have a smaller number of shot people.

Kolab Server is an email solution, people will use it with available IMAP 
clients, there is a real chance that in the near future, people will have 
different IMAP client than KDE's KMail and work on Kolab.

> The real problem with you is that you are mixing different issues in this
> thread and try to solve different non topic issues while dilluting the
> current discussion.
>
> I am talking about "Handling of private/confidential groupware objects" and
> you seem to discuss other unrelated issues like "private freebusy", group
> calendars,....

You do not seem to see the connections.
Folders with ACLs would provide a wonderful way of taking care of privacy 
issues without further object security, that, as you will point out, will 
only hurt scalability.
Exploring why multiple folder do not fully the solve the problem:
- reminders
- PDA syncs
seems a good way to find out if it is possible to give the user
a good solution for their problem.

In other cases I have heard you say to make the design as simple as possible
and aim for the future, obviously this is done, if I do not have two places
to model access control: object and folder.
There is research about two many security layers and places actually to make
it lesss secure for the users, because they make more mistakes.

> The most obscure stuff from you is:
> > 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.
>
> This is nonsense!
>
> The technically challenge does not in any way become easier when doing the
> sync of PDAs with the Kolab server compared to the Kolab client. Actually
> it is more complicated not less complicated.
>
> In contrast what you seem to assume doing the sync directly with the server
> (e.g. sync-ml) does _not_ grant us more control!

It does give us more control, 
as we are controling the sync store and how the mobile device is used.
As opposed to a Microsoft Software that will directly work on the .pst
for instance.

> (This is partly due to the fact that we still don't have control about the
> sync algorithm implemented on the PDA)

We could provide a view that the PDA would like, and join or leave out
the folders apropriately. Map flags and categories to what the PDA can deal 
with and so on.

> Last but not least this does not mean that I am agains implementing direct
> PDA sync with the server in the future but doing so does not solve the
> private/confidential groupware objects issue.

It would solve the problem that prevent to solve one part 
that would enagle to solve the privacy problem differently.

> > As far as I have thought, I think that the problem with
> > one-calendar-only PDAs can be solved on the sync code level.
>
> Only if you are willing to create your own PDA specific sync sw. (No I am
> not up volunteer to create this....)

While we are at it, I guess that we should take a new look on funambol
(ex sync4j), they claim to have many devices supported.

> > Encryption on the emails using S/MIME or OpenPGP would protect
> > against administrator, too.
>
> You seem to be citing poor Schneier for your nonsense. Of course using
> encryption in a corporate environment does _not_ protect from malicious
> administrators. It is helpful for other purposes though. E.g. it helps to
> protect stolen media (like backup tapes or harddisks).

I did not cite Schneier for email encryption, but for simplicity only.
So far I do not think that the email encryption is wanted at this point,
but it would protect offer some (minor) protection against the server 
administrator, given that the server administrator is not fully controlling 
the clients, too. 

> > which means we cannot guarantee that a hidden folder is "private"
> > to the ower of the folder in all cases on the server, it depends on the
> > ACL of the hidden folder.
>
> Which is perfectly fine from a security POV!

It is an argument that people probably need to learn about the ACL
anyway.

> > This question was is one aspect,
> > and yes it is an aspect against your proposal.
>
> It was nonsense and wasting my time.
>
> > However this always needs to be weighted with all aspects.
> >
> > I have not disregarded your proposal yet,
>
> Fortunately it is not up to you to make such technical decissions. It is
> your job to do the _non-technical_ project management.

I have my share in technical decissions as many developers have
and also because I do have some technical skills on my own, too.

> > but with my current knowledge, I think
> > the other solution is better.
>
> You did _never_ proposed another technical solution! You only raised some
> points which you would love to have also been solved and provided some non
> technical proposal how to circument the issue on a procedural/social
> level......

Sometimes a procedural/social level does indeed solve a problem.
Technically staying with multiple folders and their ACLs,
but enabling them to fully work on Outlook, is a solution.
I admit that I did not fully think about PDAs at that point, 
which throw in a major problem. But still I cannot see what is
wrong in exploring this options from the technical point of view.

> There are currently no other solutions than those I proposed at the
> beginning of this mail thread on November 30th in 2005.

You did not add many arguments to that claim.

Bernhard