Calendar proxy groups should not be readable

[wsanchez@…]

Calendar proxy groups should not be readable

I should probably be unable to know who you have given proxy access to your calendar.

Need to make sure that iCal can still access the info it needs to know what proxy access it has, though.

[wsanchez@…]

9/13/07 5:39 PM Wilfredo Sanchez:

I wouldn't call this a blocker, but I'm not a fan of exposing more info about you than is necessary.

9/13/07 6:10 PM Cyrus Daboo:

This is potentially problematic. Someone who has been made a proxy will see an entry in their group-memberships property. In order to know that that is actually a proxy principal they need to be able to PROPFIND DAV:resourcetype on it to get back calendar-proxy-read etc. Then they know its a proxy membership and can adjust their UI accordingly.

What we probably need to do is a per-property ACL type option here. e.g. anyone with read access to the proxy principal can see resourcetype and maybe principal-URL. Any one with write access can see all properties including group-member-set. That way everyone has read access, but only the "owner" can see the membership list.

However, we also need to protect the group-membership property on regular principals, because I could figure out who is a proxy for whom just by listing all those.

Bottom line - we need to decide which properties need to be exposed when DAV:read is allowed on any type of principal resource.

9/14/07 12:20 PM Wilfredo Sanchez:

Granting read access as part of write privileges sounds like a bad idea, but we can create a separate privilege if necessary, that is limited to resourcetype. If you are allow to know the resource exists, knowing it's type is probably OK as well. DAV:read on the parent should therefore be sufficient.