Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-eventpub-extensions-13: (with DISCUSS and COMMENT)

[Michael Douglass <[e-mail]>]

Thanks Benjamin.

I'm in the process of producing a new draft with fixes to some points 
raised by Barry and others.

Further comments on your suggestions...

On 12/29/20 13:34, Benjamin Kaduk wrote:
> Hi Michael,
>
> ...

> Thanks for these; I think we're all set on the Discuss front, now, and I'll
> update my ballot position in the datatracker after I send this message.
That's grerat.
> ...
>> I've added a comment in the privacy section and referred to that. Could
>> you take a look at that please?
> Yes, the new privacy (and security) considerations are much-improved!
> (Unrelated to this particular comment,) I would suggest one other
> improvement: currently we just say that "any network access of the URI data
> can be tracked", which as a phrase suggests to me that the tracking occurs
> "in the network", but of course the remote endpoint hosting the referenced
> resource will have a very authoritative view of who is accessing it and
> when.  So perhaps "can be tracked both by a network observer and by the
> entity hosting the remote resource" (or similar)?
I'll take a look
> ...
>
> We probably should go a little further and note that this may facilitate
> tracking of individuals or malicious actions targeted against them at
> the known location/time pair.
>> I've added more text and aligned this to some extent with jscalendar.
> As mentioned above, I do appreciate the added text, but it doesn't seem to
> capture my intended point here.  Specifically, calendaring rather
> intrinsically has the property that it provides information about a future
> time when a given individual will be at a particular location, which could
> enable further (targeted) attacks against that individual.  Most other
> sources of tracking information about people are retrospective, not
> future-looking, so I wanted to have this aspect emphasized.

Good point and happy to do so. Events of late have served to make me 
more concerned about privacy issues.

I guess it's a bit of a side issue but I'm pretty convinced that these 
are more protocol issues than data schema and representation. For 
example, it's undeniably (I believe) a good thing to have a place to 
store the expected location of an attendee. It's also a good thing for 
an organizer to be able to have that information when trying to come up 
with a good meeting time.

However, it's not a good thing for the organizer to have free access to 
that information without the attendee being aware of how it is to be 
used and stored and shared. Those issues are related to how we design 
protocols and services. I'm pretty much convinced that the client/server 
model is inherently unsafe and a more peer-to-peer model is the only 
safe approach. Given our always online world I believe we can build 
those services without handing over the data to 3rd parties (who then 
wittingly or unwittingly hand them on to 4th, 5th etc parties).


> Thanks again for the updates!
>
> -Ben