Handling of private/confidential groupware objects

Helge Hess helge.hess at opengroupware.org
Wed Dec 7 03:54:07 CET 2005

On 6. Dez 2005, at 16:30 Uhr, Bernhard Reiter wrote:
> I agree on the general point that there are marking and access  
> control.
>> The intention is to make the information consumer aware of the
>> sensitivity of the data. Eg a secretary won't open a file marked "top
>> secret" but rather pass it on to her general (but she stil has  
>> access).
> For this I would say that technology
> should prevent the secretary having access.

No offense but I don't think that you understood the general point  
(probably my mail was too confusing).
With marking the secretary _is_ allowed to see the data, it (mostly)  
says how he/she is supposed to deal with it wrt _other_ people.

If you do not want to have the secretary see the item, just remove  
the permissions via access control. Which, as explained, happens  
automatically in Outlook but not in Kontact.

Maybe a better example is a company wide memo. This would be marked  
'confidential' so that people know that they are not allowed to tell  
their out-of-company friends.
Seperate thing unrelated to permissions of the item (its basically  
public inside the company).

>> Or to give another anology: you might tell your friend your personal
>> income but explicitly tag the information as "private". So he will
>> know that he must not tell other people or get kicked.
> Your friend has the information in this case, though.

Err. Which is intentional, did you actually read the sentence you  
quoted? :-)

IMHO the real bug is that the Kontact UI does not make the user aware  
of the fact that this is "just" a marker (only affects the iCalendar  
CLASS property, no ACL settings).
In contrary, it explicitly labels the checkbox as "Access:" which is  
just wrong. Should be "Sensitivity:".

>> Summary2: you can't do that with IMAP4 because you lack per-message
>> access control.
>>    calendar.private is insufficient. You would at _least_ need to  
>> have
>>    calendar.$userid$ since private as per b) belongs to a certain
>> user [unlike a)]
> In Martin's example, one extra calendar would be enough,
> as this is only access control to one person (the user).
> Because all users have calendar folder, one named private
> for each of them is enough.

Sorry, when I think about groupware I tend to think about multiuser  
systems, which means shared folders ;-) And in a shared folder the  
private (ACL, not marker) flag  must be per user.


More information about the format mailing list