Re: [SOGo] confidential appointments

2016-06-28 Thread Ralf Cirksena
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

2016-06-27 Thread "sg gs"
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)" <users@sogo.nu>
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)" <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

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

2016-06-26 Thread "sg gs"

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




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

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

2016-06-24 Thread "sg gs"

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

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

2016-06-23 Thread Ralf Cirksena
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

2016-06-23 Thread Ian McMichael

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

2016-06-23 Thread "sg gs"
yes, it's a schow stopper - agreed
 

Sent: Thursday, June 23, 2016 at 8:40 AM
From: "\"Ralf Cirksena\" (c...@holmco.de)" <users@sogo.nu>
To: "Ian McMichael" <users@sogo.nu>
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

2016-06-23 Thread Ralf Cirksena
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

2016-06-23 Thread Ralf Cirksena
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

2016-06-22 Thread Ian McMichael

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

2016-06-22 Thread Ralf Cirksena
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

2016-06-22 Thread Christian Mack
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


[SOGo] confidential appointments

2016-06-22 Thread Ralf Cirksena
Hello,

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?


Greetings
-- 
R. Cirksena 
-- 
users@sogo.nu
https://inverse.ca/sogo/lists