Client behaviour regarding "Access" or better "information sensitivity"

Bernhard Reiter bernhard at intevation.de
Fri Aug 27 16:46:55 CEST 2010


As some of you might know, I am involved in a project
to create Kontact-Mobile [1]. It is a Kolab client
for handheld devices like the N900 smartphone.

Because we want finger touch usage on a small screen, we design
a new interface. And I ran into the issue with declaring the information 
sensitivity of Kolab objects again. This is what is called the "privat" 
setting  for appointments in Outlook where it is a two state button.
In Kontact it currently is called "Access" ("Vertraulichkeit") 
and has the states: public, privat and confidential.

In both desktop clients, it is taking up significant space in the interface.
And it does not work like users would expect it to work. (See the archives of 
kolab-format@ for a few discussions about it.) The real access to objects
in the Kolab world is mainly governed by the ACLs of each folder.

So even if you would have marked something as confidential this would be more 
like a sensitivity label. It gives the (human) readers a hint, but access 
would  still be for everybody that has access to the folder.
With modern Kolab Clients being able to deal with several fully featured 
folders, there is no problem in just creating a few folders and making sure
that the ACLs for them are right. Then you would just create the appointment
in the right folder to do the labeling and control access.

With current Kolab Server implementations, the setting of this sensitivity
should only influence the creation of extended freebusy information.
A setting of "public" would lead to "Subject" and "Location" of an appointment 
be written in the corresponding pxfb and both would be left
out for all other settings ("privat" and "confidential") [2]. However pxfbs 
are not widely used yet and only modern versions of Kontact and the web 
client offer some support for it. 

I propose two things for modern Kolab Client implementations:
a) (minor) If client would like to have a prominent selection box or button,
   call it "Sensitivity" ("Einstufung") and do not use wording that suggests 
   that actual access control measures are taken.
b) Clients can (and should) remove the prominent button and offer the
   functionality as part of the category and tagging functionality.
   My suggestion is that: if "privat" or "confidential" categories are
   there, this will be treated as such. 
   "public" will map to having none of the mentioned category entry.

Rationale: We are improving the usability of the interface, by removing one 
selection and gui element. Still we are compatible with systems that use this 
setting. The potential for confusion will be reduced. In the mid term using 
several folders with adequate names and ACLs could become the canonical way 
to manage access and information sensitivity.

Best Regards,
Bernhard

[1]
http://userbase.kde.org/Kontact_Mobile
http://techbase.kde.org/Projects/KDE_PIM/Development/Mobile
[2]
ftp://ftp.intevation.de/users/bernhard/scratch/extended-freebusy-concept-0.92+dev20080503-ber1-pub2.pdf
-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20100827/b5165eb8/attachment.sig>


More information about the format mailing list