Re: [Geopriv] Location in SIP and "retransmission-allowed"

From: Henning Schulzrinne ^lt;hgs@cs.columbia.edu>
Date: Tue May 01 2007 - 16:16:25 EDT

I think our fundamental disconnect is that I believe that location
information, by itself, has no privacy implications. After all,
there's nothing private about "1600 Pennsylvania Avenue" or "40 N, 20
E". The privacy implications occur when location information is
combined with a (personal) identity, as in "Dick Cheney is at 1600
Pennsylvania Avenue" (as opposed to an undisclosed location). The
privacy risk discussions have been about revealing a person's
location, not a location by itself. (Indeed, the fact that Google
Maps is proprietary is irrelevant. Even an OGC-certified map
retrieval protocol would have the same considerations. I'm pretty
sure OGC does not use privacy indicators in their mapping protocols.)

I'm trying not to argue by appeal to charter; I'm trying to argue by
privacy interests we both try to protect. By the way, the charter
talks about "geographic location information about certain resources
or entities.", as opposed to location by itself.

Henning

On May 1, 2007, at 3:54 PM, Ted Hardie wrote:

> At 3:38 PM -0400 5/1/07, Henning Schulzrinne wrote:
>> I fail to see the privacy aims that are met by this restriction.
>
> It retains a mechanism that allows the user to say "don't redistribute
> to *anyone* for *any purpose*". That's important. Making "no"
> mean something other than "no" eliminates it without replacing
> it. I object to that.
>
>
>> You did not in any way my technical argument, just argued by
>> appeal to authority. It's the usual "we can't answer you
>> technically, but just imagine the wasted time you go through
>> trying to argue it, so you'll see why it's best if you don't even
>> try".
>
> Actually, you argued first by reference to an unrelated service
> (Google Maps,
> a proprietary service which has nothing to do with the chartered
> work of
> the group or of SIP), then in 1-3 by exploring bits of the problem
> space that
> I thought obviously the same. If you act on the location or based
> on the location,
> you are acting as a recipient, and the rules apply to you. That
> includes redistribution.
> If you are just forwarding along to the recipient they don't. That
> seems pretty
> simple to me. I did and continue to challenge the correctness of
> using your
> 4 as a baseline.
>
>> My prediction: We'll end up with some meaningless token that
>> everybody always inserts or ignores, depending on the
>> circumstances, since nobody outside a small group of people will
>> understand as to why a LoST query has GEOPRIV privacy implications
>> when Google Maps does not.
>
> Ah, the "we can't win, so let's not try" argument, supplemented
> with a reference
> to the same unrelated service .
>
> We're talking about whether a specific token can be used in SIP
> context, not
> whether that context will get compared to something else. If SIP
> developers
> and deployers can get "location-based routing has to be approved by
> the user
> unless trumped by emergency", then we're squarely in the territory of
> SIP as using protocol of GEOPRIV. Given the other things they've
> folded their
> brains around, I'm pretty sure they can.
> regards,
> Ted
>
>
>
>
>> On May 1, 2007, at 3:28 PM, Ted Hardie wrote:
>>
>>> At 1:55 PM -0400 5/1/07, Henning Schulzrinne wrote:
>>>> I think what got lost in the long message is the crucial
>>>> distinction that the LoST request contains no personally
>>>> identifiable information about the querier (except maybe the IP
>>>> address of the proxy server), unlike a normal PIDF-LO.
>>>
>>> It wasn't lost on me. The proxy gets a PIDF-LO and it acts on
>>> it; that acting on
>>> it includes removing some of the identifying information before
>>> sending it
>>> as a LoST query, but that does not change the fact that it is
>>> acting as a recipient
>>> by routing based on the location. I believe it should not do so
>>> unless it
>>> is authorized to do so. That fits with the overall privacy aims
>>> of this
>>> group, which are clear in its charter. Sorry if you think that
>>> is lawyering,
>>> but I think this isn't the place to object to it. Feel free to
>>> argue for
>>> a recharter with Robert; it's always a nice way to be greeted as
>>> a new chair.
>>>
>>> There are two ways forward: agree that we add a state for
>>> routing queries,
>>> which handles this fairly cleanly, or add a state that says
>>> "Absolutely no" that
>>> forbids even routing queries, since we have re-written "no" to mean
>>> "no, except for routing queries". There MUST be some way for a user
>>> agent to say "no" to redistribution and mean it. GEOPRIV is
>>> nonsense
>>> with that.
>>>
>>>> (4) It's an emergency call; no retransmission allowed. No LoST
>>>> query?
>>>
>>> For emergency calls, we can talk in ECRIT's PhoneBCP about when
>>> violating the
>>> geopriv privacy rules is justified. The example given was Pizza
>>> delivery,
>>> though, not a 911 call.
>>>
>>> I am also frankly tired of emergency calling being used a spectre
>>> for
>>> weakening the privacy infrastructure. The chartered baseline
>>> for the
>>> group is private information (see the default "no" to
>>> redistribution in
>>> 4119) and control by the user. It can be relaxed, but that is
>>> the baseline.
>>> If you'd like to change that, feel free to propose an update to 4119
>>> that changes the defaults.
>>>
>>> regards,
>>> Ted
>>>
>>>> We're getting into heavy-duty protocol lawyering here, out of
>>>> touch with reality as perceived by the rest of the world.
>>>>
>>>> Henning
>>>>
>>>>
>>>> On May 1, 2007, at 1:35 PM, Ted Hardie wrote:
>>>>
>>>>>
>>>>>> 3. Does the current definition of retransmission-allowed=no
>>>>>> permit a sip
>>>>>> proxy server to send Location Information to a LoST server
>>>>>> (without
>>>>>> identity)?
>>>>>
>>>>> No, I don't think so. Whether you consider the proxy or the
>>>>> Lost server
>>>>> to be a recipient in that case, I believe one of the two is. I
>>>>> think
>>>>> the routing-query-allowed solution is better than allowing
>>>>> retransmission=no
>>>>> to be weakened for this in the Pizza case. If
>>>>> retransmission=no is
>>>>> allowed to include this case, I see no way for an end user
>>>>> which did not
>>>>> want to to allow routing queries to be performed to express
>>>>> that; so
>>>>> the choices appear to be to create an explicit permission or add a
>>>>> "no, really, even including routing queries" entry. The
>>>>> explicit permission
>>>>> seems cleaner and clearer.
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Geopriv mailing list
>>>> Geopriv@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 1 May 2007 16:16:25 -0400

This archive was generated by hypermail 2.1.8 : Tue May 01 2007 - 16:15:06 EDT