hello,
caldav: at least v3.1.3.20160623-1 honors the confidential/private flag but i'm unsure if this is done on the server side - tested this using icedove/ligthning.
carddav: does not apply
sorry for any confusion, g.
Sent: Friday, June 24, 2016 at 6:35 PM
From: "\"\\\"sg gs\\\"\" (s...@mail.com)" <users@sogo.nu>
To: users@sogo.nu
Subject: Re: [SOGo] confidential appointments
From: "\"\\\"sg gs\\\"\" (s...@mail.com)" <users@sogo.nu>
To: users@sogo.nu
Subject: Re: [SOGo] confidential appointments
hello,
i guess caldav/carddav/.. suffer from the same issue and i was told this is a weakness, deigned into the rfc. the implementaion is correct with respect to this rfc. as this might be a show stopper at our site (ok, i could teach users. but this is not really an option because users tend to forget - the higher in the hierarchie, the ealier and the higher the risk).
if there is the option to declare an object private/confidential, the meaning of such flags should be respected and this should be done by the server.
may i suggest: whenever an object is requested, check the object for private/confidential flags and modify the object (ical,ics) in the same way the web client does it after the sharing permissions have been merged but before it will be sent to the requester.
yes i know, other systems do not respect these flags as well, but why not have a better system?
thanks for your attention
regards, g.
Sent: Thursday, June 23, 2016 at 2:55 PM
From: "\"Ralf Cirksena\" (c...@holmco.de)" <users@sogo.nu>
To: "Ian McMichael" <users@sogo.nu>
Subject: Re: [SOGo] confidential appointments
From: "\"Ralf Cirksena\" (c...@holmco.de)" <users@sogo.nu>
To: "Ian McMichael" <users@sogo.nu>
Subject: Re: [SOGo] confidential appointments
On Thu, Jun 23, 2016 at 01:33:05PM +0100 you wrote:
> It is here. We've been running v3 since its initial release and I
> have never experienced any different behaviour.
Bad.
> The appointments are correctly flagged as confidential (if you
> examine the XML sent to the client) but I believe this should be
> handled server-side (like it is with CalDAV) as I have yet to find a
> client that honours this! It is also much safer if data never
> intended for a client device is kept centrally and never distributed
> to it...
Fully agree. Why doesn't Inverse fix that? It should not be rocket
science.
MS-Outlook seems to handle that correct client-side. But leaking data
will be misused some day...
Greetings
--
R. Cirksena
--
users@sogo.nu
https://inverse.ca/sogo/lists
> It is here. We've been running v3 since its initial release and I
> have never experienced any different behaviour.
Bad.
> The appointments are correctly flagged as confidential (if you
> examine the XML sent to the client) but I believe this should be
> handled server-side (like it is with CalDAV) as I have yet to find a
> client that honours this! It is also much safer if data never
> intended for a client device is kept centrally and never distributed
> to it...
Fully agree. Why doesn't Inverse fix that? It should not be rocket
science.
MS-Outlook seems to handle that correct client-side. But leaking data
will be misused some day...
Greetings
--
R. Cirksena
--
users@sogo.nu
https://inverse.ca/sogo/lists
--
users@sogo.nu
https://inverse.ca/sogo/lists
users@sogo.nu
https://inverse.ca/sogo/lists
