New Properties for iCalendar
RFC 7986
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
Alvaro Retana No Objection
(Alexey Melnikov; former steering group member) Yes
If I am late for the discussion: please put this into substate "revise ID needed". Thank you.
(Alia Atlas; former steering group member) No Objection
(Ben Campbell; former steering group member) (was Discuss) No Objection
The author has addressed all my DISCUSS points and comments in email. (Thanks!). I've cleared on the assumption the proposed text will make it into a revision.
(Benoît Claise; former steering group member) No Objection
Dan Romacanu did the OPS DIR review. The RFC5706 does not apply.
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) (was Discuss) No Objection
Thanks for the updated text to address the SecDir review and Stephen's additional comments (I followed that discussion as well).
(Mirja Kühlewind; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) (was Discuss) No Objection
I think it'd be a fine thing if the calext WG were to consider privacy
issues with caldav in general. As it'd probably be wrong to try get
all of that done in this one document, perhaps we could try and
see if the WG have sufficient interest and cycles to take that on?
My previous discuss text (plus an additional point about images
is below.
- I think adding some privacy considerations to this would be good,
either as new text or via references. Did the WG consider privacy
issues? Some that occur to me are:
- names, descriptions and identifiers here are all ones that
might allow (re)identification in unexpected ways
- the UID property in particular probably ought be random and
probably ought not be re-used for anything else, some RFC2119
SHOULD statements about that would seem like they'd be good.
- doing a refresh against a calendar at the expected frequency
could be a good way to re-identify someone - if I can read the
expected frequency and some IP address connects (even all over
TLS) at about that regularity then I can be reasonably sure
that the client is someone subscribed to that address, and
maybe use that to track a person's movement across various
networks. (That's different from the text in section 7 which
assumes that the URL is what's tracked, but the connection
can be just as revealing, for some calendars.)
I'm not trying to insist all that analysis be documented in this
draft but I would hope that the WG have considered the issues and
how best to document those and have a plan to do that. (If I'm told
such a plan exists and what it is, I'll clear.)
This is related to, but a little different from, Kathleen's discuss,
depending on the added privacy considerations text which I've not
managed to find in the secdir review thread. But this should be as
easily cleared I'd guess.
And another possible issue now occurs to me: I remember that one
social network had an issue where all the avatar image sizes were
nearly unique, so that even though those were all accessed over TLS,
one could identify users and their buddies by watching those be
downloaded. (That depended on how the social network in question
made avatar images available, which'll likely be different here.)
But there may be a reason to recommend normalising image sizes here
as well and to encourage only offering those over https and not
http.
(Suresh Krishnan; former steering group member) No Objection