Fwd: [Kolab-format] Visibility of incidence infos in XFB-lists, was: Client behaviour regarding "Access" or better "information sensitivity"

Bernhard Reiter bernhard at intevation.de
Mon Sep 20 17:17:58 CEST 2010


Feedback from a long-standing Kolab-/Kontact-operator:

----------  Weitergeleitete Nachricht  ----------
Hello,

Am Mittwoch, 8. September 2010 um 14:38:40 schrieb Bernhard Reiter:
> Am Dienstag, 7. September 2010 14:29:21 a long-standing
> Kolab-/Kontact-operator wrote:
> > IMHO the core issue with this "prominent" setting is (and always has
> > been) its label: There is not the slightest hint anywhere in the GUI,
> > that it deals with the scope of visibility of XFB-/FB-information
> > only.
>
> Just to be extra clear: It only has an effect now on the XFB
> information. There is _no effect_ on the FB info.

Well, first of all, this is a loosely related, but distinctively different 
topic.  Here the functionality of the setting is discussed, in contrast to 
the original topic "keep the prominent placement of that setting or not".

NB: I will quickly dive into this other topic (functionality) for one 
paragraph.
So if one sets this "Sensitivity" to "confidential" (=invisible), the time 
and date of that IMAP-folder item (incidence type) will still be visible 
via (non-extended, regular) FB-list (containing time & date only, that is), 
but not via XFB-list?
If so, this is a modelling-flaw resulting in inconsistent functionality 
(independent of the original topic "placement"), as the information one 
intends to hide is easily obtainable for others: just trigger the 
generation of an regular FB-list and download it.  In an mixed client 
environment this unintended information disclosure automatically happens, 
as soon as MS-Outlook clients utilise this Kolab server (and its FB-lists).
Even more important is that this is inconsistent from the user's point of 
view: if one does not intend to publish date & time of an appointment 
(using the setting which is currently called "confidential") via 
(X)FB-infos, that setting must suppress *all* (X)FB-data on all [kinds of] 
FB-lists.
IIRC this also was a requirement of the original Kolab customer, but it 
never worked as intended due to aforementioned usability and technical 
(scope does not include regular FB-list) issues: as a result the 
(X)FB-lists are nowadays just used as an minor source of additional 
information, rather than as a pivotal point for many calendar-based 
actions.
The obvious and IMO "right" solution is to extend the scope of this setting 
to FB-lists as well; the "wrong" alternative "solution" is to label this 
setting "XFB-visibility" and to hide it (your original suggestion might 
serve well, then); then it also would have to be accompanied by a tool-tip, 
which clearly states that hiding the (basic) FB-infos this way does not 
work, as they are obtainable for everybody with HTTP-access to that 
Kolab-server.

In the following responses I assume, that the export of information to 
regular FB-lists will be also covered by this setting.
Yes, I am aware that regular FB-lists cannot show the contents of an 
IMAP-folder item (incidence type), hence the topmost two choices will be 
equivalent for regular FB-lists.

> > I believe it should stay prominently (and separatly) placed, as it
> > would provide valuable ease of use in many XFB-based use-cases, if
> > only this setting would be labled with concise wording, so most
> > users intuitively understand it instead of being misled (which is
> > currently the case).
>
> Improving the wording was part of my proposal.
> Did you like the suggested words?

No, IMO they are almost no improvement to what we have already, as they 
still avoid to clearly name what is happening; instead metaphors are used 
again, which will be interpreted to mean something vastly different by 
others: the same story/theme as before. 

IMHO the category shall be labelled "Visibility in Free/Busy lists" 
or "Relevance for Free/Busy lists" (I like the first one much better); 
the choices may be called "Full content visible" / "Only date & time 
visible" / "Invisible", alternatively, when using "Relevance" in the 
label: "All content relevant" / "Only date & time relevant" / "Hidden".

An maybe even better alternative may be to use the label "Export to 
Free/Busy lists:" with the choices "Full content" / "Only date & 
time" / "Nothing".
Actually, I believe that is the best choice I came across yet.

> > It is definitely not a part of the regular IMAP-folder item
> > (incidence type) properties, due to the aforementioned fact that
> > it deals with the scope of visibility of XFB-information only.
> > Hence I believe this setting must not be merged into those IMAP-
> > folder item specific settings, as this would be mislead users again
> > to believe the setting would be a property of the IMAP-folder item
> > (and maybe affect its access rights for others).
> > But this setting sure has been in dire need of better UI-strings for
> > years.
>
> Again to be extra clear: Currently "sensitifity" does affect single
> objects so moving it to be reachable via the categories would keep this
> focus as the selection of categories also are per objects.

Oh, I never questioned the fact that this is "per object (= IMAP-folder 
item, incidence type)": it definitely is!
My point is: it is a very special setting, which is solely specific for the 
(X)FB-list visibility of that incidence item, so it shall not be 
intermingled with other settings.
As said, it could provide a very valuable instrument for conveniently 
controlling which data becomes published via (X)FB-lists, hence enabling the 
long overdue proper and full use of (X)FB-lists.

> When there are more clients that can deal with several accounts and
> folders fully, the need for the use of those categories and even for XFB
> at all will vanish and then there will be only the ACL settings that
> affect the folders.

No not at all, as per account and per folder settings are way too coarse for 
many use-cases and -models: with these one will never be able to properly 
substitute per item settings.
The discussed setting is so unique, as it controls per item what information 
is exported to the (X)FB-list: any setting which does not carry exactly 
these properties will not work as a substitute.

Best regards
	

P.S.: I changed the subject line , as 'Client behaviour regarding "Access" 
or better "information sensitivity"' IMO does not at all point to that 
topic.

-------------------------------------------------------




More information about the format mailing list