Re: [SOGo] confidential appointments
On Thu, Jun 23, 2016 at 01:33:05PM +0100 you wrote: > We've been running v3 since its initial release and I > have never experienced any different behaviour. 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... Outlook 2013 (ActiveSync) does not send an authentication to the server. Therefore the server handles such free/busy requests as coming from "public". The server answers if "public" has at least permission to date/time of the requested user. Is that really the problem? There must be a way for the server to find out who requests free/busy information. And yes, that must be handled server-side. Greetings -- R. Cirksena -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] confidential appointments
it seems to me that the activesync interface does not honor the confidential/privat flags. does anybode know if this is true for the mapi interface (which i did not yet configure)? Sent: Sunday, June 26, 2016 at 12:35 PM From: "\"\\\"sg gs\\\"\" (s...@mail.com)" To: users@sogo.nu Subject: Re: [SOGo] confidential appointments 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)" 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)" To: "Ian McMichael" 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 -- users@sogo.nu https://inverse.ca/sogo/lists -- users@sogo.nu https://inverse.ca/sogo/lists -- users@sogo.nuhttps://inverse.ca/sogo/lists
Re: [SOGo] confidential appointments
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)" 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)" To: "Ian McMichael" 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 -- users@sogo.nu https://inverse.ca/sogo/lists -- users@sogo.nuhttps://inverse.ca/sogo/lists
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)" To: "Ian McMichael" 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 -- users@sogo.nuhttps://inverse.ca/sogo/lists
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
Re: [SOGo] confidential appointments
On 23/06/16 07:53, Ralf Cirksena (c...@holmco.de) wrote: Is that still an issue in SOGo 3.1.2? It is here. We've been running v3 since its initial release and I have never experienced any different behaviour. 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... -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] confidential appointments
yes, it's a schow stopper - agreed Sent: Thursday, June 23, 2016 at 8:40 AM From: "\"Ralf Cirksena\" (c...@holmco.de)" To: "Ian McMichael" Subject: Re: [SOGo] confidential appointments On Wed, Jun 22, 2016 at 12:56:40PM +0100 you wrote: > Alternatively, if any of your users are connected via ActiveSync > there is a long-standing bug which reveals confidential information > regardless of the settings: > > https://sogo.nu/bugs/view.php?id=3118 Uh oh... We are syncing MS Outlook 2013 via ActiveSync. Not preserving privacy may be a show stopper within our calendar project. -- users@sogo.nuhttps://inverse.ca/sogo/lists
Re: [SOGo] confidential appointments
On Wed, Jun 22, 2016 at 12:56:40PM +0100 you wrote: > Alternatively, if any of your users are connected via ActiveSync > there is a long-standing bug which reveals confidential information > regardless of the settings: > > https://sogo.nu/bugs/view.php?id=3118 Uh oh... We are syncing MS Outlook 2013 via ActiveSync. Not preserving privacy may be a show stopper within our calendar project. Greetings -- R. Cirksena -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] confidential appointments
On Wed, Jun 22, 2016 at 12:56:40PM +0100 you wrote: > Alternatively, if any of your users are connected via ActiveSync > there is a long-standing bug which reveals confidential information > regardless of the settings: > > https://sogo.nu/bugs/view.php?id=3118 Is that still an issue in SOGo 3.1.2? Greetings -- R. Cirksena -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] confidential appointments
On 22/06/16 12:51, Christian Mack (christian.m...@uni-konstanz.de) wrote: You did give them privileges to see those in your calendar. Or the admin did so, and you didn't change that. Alternatively, if any of your users are connected via ActiveSync there is a long-standing bug which reveals confidential information regardless of the settings: https://sogo.nu/bugs/view.php?id=3118 -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] confidential appointments
On Wed, Jun 22, 2016 at 01:51:41PM +0200 you wrote: > You did give them privileges to see those in your calendar. > Or the admin did so, and you didn't change that. The others, who should not see the details of confidential entries, have permission to see time/date. Maybe I found out what has been the problem. Both testers are admins. "Others" was the other admin. :-/ Really "others" (normal users) can just see time/date. Seems to be o.k. I think. Thank you for setting me on the right track. Greetings -- R. Cirksena -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] confidential appointments
Hello Am 22.06.2016 um 12:48 schrieb Ralf Cirksena (c...@holmco.de): > > if I enter an appointment as "confidential" through the web interface > it is visable to others in CalDAV synchronized Thunderbird calendar. > > SOGo 3.1.2 > > What's wrong here? > You did give them privileges to see those in your calendar. Or the admin did so, and you didn't change that. Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung Basisdienste 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature