Subject: Georpiv and actively lying

From: "James M. Polk" <[email-masked]>
Date: Wed, 17 Sep 2003 17:29:25 -0500

comments below

** I've added the Geopriv list to this discussion because this thread has 
whittled down to the one issue (lying) and it hasn't been commented on yet 
there, and if a previous WG agreement is being called into question (which 
is OK) - more people should see this discussion

At 05:48 PM 9/17/2003 -0400, Jonathan Rosenberg wrote:

>James M. Polk wrote:
>
>>At 04:02 AM 9/17/2003 -0400, Jonathan Rosenberg wrote:
>>
>>>Henning,
>>>
>>>Also, how does this handle lying? I raised this question on the list as 
>>>well.
>>
>>We had this discussion over two meetings last year and the consensus was 
>>that in Geopriv, we shouldn't explicitly allow lying (as in, defining how 
>>to do it - yet knowing we can't prevent it). That was resolved in the POV 
>>that one can always give "less precise" location information (replying 
>>that I'm in North America (only) when I know I'm at 123 Main St., Dallas, 
>>TX, USA).
>>This is where permissions can be mapped to a template or table that 
>>equates to the level of resolution of the target's location a particular 
>>requester can learn.
>
>That works for geoloc, and can be mapped nicely into the model Henning is 
>proposing. "resolution" can be considered an integer, such that the 
>maximum resolution is the value that is communicated.
>
>It doesnt work for presence, and it won't work for geoloc later on when 
>you do decide to lie. It seems lying is really crucial there too. THe 
>classic "mistress" problem applies here - if your wife only sees "I'm in 
>North America" as opposed to "I'm at the office in Parsippany, NJ", the 
>mere fact that the information has been made less precise conveys that 
>there is a problem. You need to be able to say "I'm in Parsippany" when 
>you are really in Las Vegas.

Why should we design for permissible lying in an IETF effort?

If your server or service is configured to give out misinformation, that's 
one thing - but to build it into the protocol as a requirement lacks 
technical justification at this point. A compliant protocol implementation 
shouldn't be required to be able to lie just to be compliant. A protocol 
that chooses not to be compliant can always misbehave.

>As such, I am somewhat surprised this was dismissed.

One argument for this dismissal was that if this were built into Geopriv, 
the IETF would be actively, explicitly endorsing (through functionality of 
the base protocol) the ability to lie.

Doesn't seem like something to be proud of, when all is said and done

>I understand its hard, but it seems crucial, no?

There just hasn't been a good technical reason for allowing this into the 
protocol as a requirement of compliance yet. What I believe you are 
pointing to is a (debatable) societal reason for this

>-Jonathan R.
>--
>Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
>Chief Technology Officer                    Parsippany, NJ 07054-2711
>dynamicsoft
>[email-masked]                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com
>

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

---

From: Carl Reed <[email-masked]>
Date: Wed, 17 Sep 2003 18:53:40 -0600

Interesting discussion. I am not sure the following will help, but I have to agree that any standard for an interface or encoding explicitly (or implicitly) supports the ability to lie. In the OGC, we always live with the adage that "maps can lie".  While our interfaces or encodings would allow an application to access and communicate bad data (the lie), we do not have any specific parameters or encoding rules that would allow for the changing or degradation of the content being communicated. How content is massaged at the client side or the server side is application dependent and could any "massaging" of content to be misleading would be the result of a user setting specific preferences at the application level - not at the encoding/transmission level.

So, for what its worth, the following is from the OMA/LIF Privacy guidelines. They are basically saying that user preferences control what the application does with location - and that the encoding should do noting more than transmit location and metadata for location. I should point out that there is the Mobile Location Platform API for transmission and encoding of location content from the location gateway server (the thing that captures location) to the application server (the thing that processes the location). 

Cheers

Carl

Principles for the handling of personal data were developed in the seventies as a reaction to the ability of computers to process registers of personal data fast and in an automated manner. The purpose of the early principles was to prevent the misuse of the technology. Fair Information Principles (FIP) for handling personal information have been formulated by many organisations. The OECD (Organisation for Economic Co-operation and Development) formulated its principles in 1980, and these are commonly accepted as a good baseline for proper handling of personal information. The relevant part is quoted in appendix i. For location based services these principles are directly applicable. It is strongly recommended to comply with the OECD FIP guideline. In addition it is also recommended to comply with the following principles. The intent is to sharpen the OECD principles specifically for location data.

1. Collection limitation: Location data shall only be collected when the location of the target is required to provide a certain service. 

2. Consent: Before any location data collection can occur, the informed consent of the controller has to be obtained. Consent may be restricted in several ways, to a single transaction, certain service providers etc. The controller must be able to access and change his or her preferences.  It must be possible at all times to withdraw all consents previously given, to opt-out with simple means, free of additional charges and independent of the technology used.

3. Usage and disclosure: The processing and disclosure of location data shall be limited to what consent is given for. Anonymity shall be used when the service in question does not need to know the identity being served. 

4. Security safeguards: Location data shall be erased when the requested service has been delivered or made (under given consent) aggregate.

From this it should be clear that the LIF recommendation is to offer location services in such a way that the controller must be able to give his/her informed consent for collection and disclosure of location data. This consent is referred to as the opt-in principle in this document, in contrast to the opt-out principle, where the controller actively must decline location data from being shared with others.

This is one small piece of the LIF Privacy document

---

From: [email-masked]
Date: Wed, 17 Sep 2003 18:19:53 -0700 (PDT)

> >you are really in Las Vegas.

	why is this a need?

	prior work, with roughly the same issues, was debated and
	discussed in the definition of the DNS LOCation RR.
	Then it was deemed ok to specify location with a degree of
	vagueness, e.g. somewhere inside a sphere w/ a radius of 
	100Km vs somewhere inside a sphere w/ a radius of 10cm.
	
	Now w/ geopriv, there has been some historical concern over 
	being able to respond w/ different degrees of accuracy, depending
	on whom is making the request, but I'm not convivnced there is
	a need to build in the capacity to outright lie.

>                  Truth is not to be argued... it is to be presented

--bill

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 Sep 2003 22:47:43 -0400

James M. Polk wrote:

> If your server or service is configured to give out misinformation, 
> that's one thing - but to build it into the protocol as a requirement 
> lacks technical justification at this point. A compliant protocol 
> implementation shouldn't be required to be able to lie just to be 
> compliant. A protocol that chooses not to be compliant can always 
> misbehave.

No particular protocol effort is required to build a lying 
implementation. In a presence model, I can have my 'alibi publisher' 
publish any Munchhausen location information that I like and then select 
to only propagate that information, rather than my GPS information. (For 
example, using my earlier sphere proposal, designate myself in the 
"mistress" sphere, which automatically only selects data from that 
source, presumably without including the label.) This is functionally no 
different than considering my calendar as an approximate location source.

I would think that in most real implementation, the published location 
information is actually an aggregate of various sources, as they all 
have different strengths and applicability (GPS outdoor vs. 802.11 
indoors, etc.). The current model doesn't support this particularly 
well, but I think it would be helpful to solve that, more generic, 
problem and then treat lying as a special case that people can address 
based on their needs.

This has the great advantage that it is far more powerful than any 
simple, static transformation could be. You can emulate a whole 
schedule, with varying meetings, road trips and what have you, rather 
than pretending to be in your office all day.

To some extent, this functionality already exists with the 'class' 
attribute in RPID. With appropriate selectors, as being discussed right 
now, you can easily include just 'class=madeup-from-whole-cloth' elements.

With this, there is no need to take a moral stand on whether the IETF 
should endorse violation of truthfulness.

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Sep 2003 16:30:16 -0400

inline.

James M. Polk wrote:

> comments below
> 
> ** I've added the Geopriv list to this discussion because this thread 
> has whittled down to the one issue (lying) and it hasn't been commented 
> on yet there, and if a previous WG agreement is being called into 
> question (which is OK) - more people should see this discussion
> 
>>>> Also, how does this handle lying? I raised this question on the list 
>>>> as well.
>>>
>>>
>>> We had this discussion over two meetings last year and the consensus 
>>> was that in Geopriv, we shouldn't explicitly allow lying (as in, 
>>> defining how to do it - yet knowing we can't prevent it). That was 
>>> resolved in the POV that one can always give "less precise" location 
>>> information (replying that I'm in North America (only) when I know 
>>> I'm at 123 Main St., Dallas, TX, USA).
>>> equates to the level of resolution of the target's location a 
>>> particular requester can learn.
>>
>>
>> That works for geoloc, and can be mapped nicely into the model Henning 
>> is proposing. "resolution" can be considered an integer, such that the 
>> It doesnt work for presence, and it won't work for geoloc later on 
>> when you do decide to lie. It seems lying is really crucial there too. 
>> THe classic "mistress" problem applies here - if your wife only sees 
>> "I'm in North America" as opposed to "I'm at the office in Parsippany, 
>> NJ", the mere fact that the information has been made less precise 
>> conveys that there is a problem. You need to be able to say "I'm in 
>> Parsippany" when you are really in Las Vegas.
> 
> 

Privacy, of course.

My concern is that, if the only capability of the system is to dilute 
the accuracy of data, and the level of this accuracy is known to the 
recipients of the data, the mere FACT that the data is not as accurate 
as it could be divulges sensitive information.

Its equivalent to the need for "polite blocking" as we call it, in 
presence. If I don't want you, James, to see my presence at all, 
instead of outright rejecting your subscription, the system accepts 
your subscription and then provides you with false data. If the only 
option were to outright reject your subscription, then this reveals 
senstivite data to you - namely, that I don't want you to see my presence.

Polite blocking is discussed as part of the SIMPLE specifications, and 
we have agreed that the mechanisms for setting authorization and 
privacy policies must allow for a client to tell the system to use 
polite blocking.

Do we need to mandate support for authorization and privacy mechanisms 
that facilitate lying? No. Mandatory-to-implement stuff should always 
be bare minimum, and need not include this. But that doesnt mean that 
the system shouldn't support the capability.

> compliant. A protocol that chooses not to be compliant can always 

If it can be done without protocol support, thats great. But, I don't 
see how. In the case where (using geopriv terminology), the rule 
holder and location server are not co-located, there needs to be some 
way to convey that this particular data transformation is desired.

> One argument for this dismissal was that if this were built into 
> Geopriv, the IETF would be actively, explicitly endorsing (through 
> functionality of the base protocol) the ability to lie.

We have already done that. Quoting from rfc2779 on presence requirements:

  5.1.15. It MUST be possible for B to configure the PRESENCE SERVICE
    to deny A's subscription while appearing to A as if the subscription
    has been granted (this is sometimes called "polite blocking").  The
    protocol MUST NOT mandate the PRESENCE SERVICE to service
    subscriptions that are treated in this manner.

In what way is this not lying?

> Doesn't seem like something to be proud of, when all is said and done

Privacy is about masking or misrepresntation of information in some 
way. I thought geopriv was all about privacy?

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Sep 2003 16:50:11 -0400

> different than considering my calendar as an approximate location source.

We have discussed this in the past as part of the facet header 
discussion in Aki's publication work, and I believe Aki also suggest 
it again somewhere in this thread.

I believe it can work. It has the benefit that it can have lots of 
flexibility. If this transformation is done on the server, you need to 
specify particular transformations that are possible so that the user 
can set them as it desires. THe drawback is that it now requires two 
publishers for a single user just to support this capability. It also 
introduces the need to coordination between those publications, either 
by havign them co-resident, or through some other means. When 
co-resident, say, on a wireless handset, it may increase bandwidth 
usage by sending information which could have been algorithmically 
derived at the server.

> problem and then treat lying as a special case that people can address 

I think thats a great idea. In particular, the current diagram in the 
requirements document has only a single source of information. Is 
there a desire to change the model to allow multiple sources, and then 
introduce a composition concept in the location server? This is (for 
geopriv folks), exactly the presence model we have in simple.

> should endorse violation of truthfulness.

This is another advantage of this approach, yes.

The fundamental problem, however, has only been masked. Recall that, 
my original concern was that I didn't see how to apply Ted's "Venn 
diagram" style permission model to transformational policies. It 
seemed that you would need to assign a preference to them, so they 
would be applied in a speific order. It wasn't just set arithmetic.

Now, what we have done here is basically take alternative versions of 
the presence/geolocation for a user, compose them together, and then 
allow the permissions to select which pieces go to various watchers. 
However, we are now faced with a case where the presence/geolocation 
object, after composition, contains conflicting information. Lets say 
it contains (now using simple terms) two tuples, one associated with 
my work sphere, and one associated with my home sphere. These tuples 
present conflicting information. The tuple for my home sphere says I 
am not available for calls on my cell, and the tuple on my work sphere 
says I am.

What happens if someone is associated with both home and work spheres? 
They will now receive conflicting information. Is that the result we 
want? You might argue thats ok, since a user in both spheres should be 
allowed to see both perspectives. However, it reveals additional 
information - namely, that the user is explicitly given out 
conflicting information depending on the sphere - and this may not be 
desirable.

-Jonathan R.

---

From: [email-masked]
Date: Fri, 19 Sep 2003 15:38:32 -0700

At 4:50 PM -0400 09/19/2003, Jonathan Rosenberg wrote:
>>>If your server or service is configured to give out 
>>>misinformation, that's one thing - but to build it into the 
>>>protocol as a requirement lacks technical justification at this 
>>>point. A compliant protocol implementation shouldn't be required 
>>>to be able to lie just to be compliant. A protocol that chooses 
>>>not to be compliant can always misbehave.
>>
>>
>>implementation. In a presence model, I can have my 'alibi 
>>publisher' publish any Munchhausen location information that I like 
>>and then select to only propagate that information, rather than my 
>>GPS information. (For example, using my earlier sphere proposal, 
>>designate myself in the "mistress" sphere, which automatically only 
>>selects data from that source, presumably without including the 
>>label.) This is functionally no different than considering my 
>>calendar as an approximate location source.

I'm not sure I follow this.  Does this imply that you use an "alibi 
publisher" to change
your location under certain circumstances and that this location is 
held to be valid
for all watchers?  If so, this requires no special processing in the 
GeoPriv sense; it
simply implies that you can adjust location provider by 
configuration.  If you do intend
it to apply only to certain watchers, then we're back to a serious 
set of issues, including
how to do in-the-moment updates of the rules, how to apply 
transformative rules,
and so on.

>flexibility. If this transformation is done on the server, you need 
>to specify particular transformations that are possible so that the 
>user can set them as it desires. THe drawback is that it now 
>requires two publishers for a single user just to support this 
>capability. It also introduces the need to coordination between 
>those publications, either by havign them co-resident, or through 
>some other means. When co-resident, say, on a wireless handset, it 
>may increase bandwidth usage by sending information which could have 
>been algorithmically derived at the server.

This seems to me to be more flexibility than GeoPriv can handle at 
the moment.  The bang for
this buck seems awfully small, and the delay larger than is 
warranted.  Just my opinion, of
course,
			regards,
				Ted

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 19 Sep 2003 19:02:50 -0500

in-line

At 04:30 PM 9/19/2003 -0400, Jonathan Rosenberg wrote:
>>whittled down to the one issue (lying) and it hasn't been commented on 
>>yet there, and if a previous WG agreement is being called into question 
>>(which is OK) - more people should see this discussion
>>>>information (replying that I'm in North America (only) when I know I'm 
>>>>at 123 Main St., Dallas, TX, USA).
>My concern is that, if the only capability of the system is to dilute the 
>accuracy of data,

this is the only capability

>and the level of this accuracy is known to the recipients of the data,

this was *not* ever to be included in any form of response, and I think I 
understand why you have stated what you did (based on the belief that this 
second piece of information was also present

>the mere FACT that the data is not as accurate as it could be divulges 
>sensitive information.
>
>presence. If I don't want you, James, to see my presence at all, instead 
>of outright rejecting your subscription, the system accepts your 
>subscription and then provides you with false data. If the only option 
>were to outright reject your subscription, then this reveals senstivite 
>data to you - namely, that I don't want you to see my presence.

I feel this is an acceptable piece of information to provide to you (that I 
don't want you to know where I am). But by making the answer quite grey 
(through reduced resolution), you won't know if this is purposeful (I 
choose not to give you more precise location information) or that I don't 
know more precise location information about where I am (for example, 
because the mechanism that I used (perhaps only this time) to locate myself 
accurately cannot provide me more precise information that it did).

>Polite blocking is discussed as part of the SIMPLE specifications, and we 
>have agreed that the mechanisms for setting authorization and privacy 
>policies must allow for a client to tell the system to use polite blocking.
>
>that facilitate lying? No. Mandatory-to-implement stuff should always be 
>bare minimum, and need not include this. But that doesnt mean that the 
>system shouldn't support the capability.

misbehavior is expected (unfortunately), but it doesn't need to be part of 
the specs here

>>compliant. A protocol that chooses not to be compliant can always misbehave.
>
>If it can be done without protocol support, thats great. But, I don't see 
>how. In the case where (using geopriv terminology), the rule holder and 
>location server are not co-located, there needs to be some way to convey 
>that this particular data transformation is desired.

Based on what I stated above (that the level of imprecision is *not* 
provided in a response), I don't think this is the case. Do you agree with 
this?

>>the IETF would be actively, explicitly endorsing (through functionality 
>>of the base protocol) the ability to lie.
>

Presence supporting this form of lying doesn't mean Geopriv should. Unlike 
SIMPLE, Geopriv has the ability to provide a grey answer that is not lying 
- by reducing resolution - in a way that presence cannot duplicate (I 
think). This should allow Geopriv to respond without a Polite Blocking type 
mechanism.

>Privacy is about masking or misrepresntation of information in some way. I 
>thought geopriv was all about privacy?

Masking (meaning denial) yes, misrepresenting (meaning lying) has another 
meaning here (in all the discussions I've been in, and I wasn't necessarily 
the ring-leader of all those discussions either, so this opinion is 
shared). If by misrepresentation you mean the purposeful reduction in 
precision of a response - then I believe that is in line with the WG 
efforts to date.

cheers,
James

                                *******************

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Sep 2003 21:07:54 -0400

This is not a philosophy working group, but let me try to categorize 
different behavior and see if we can agree at least on terminology:

1 - Withholding of information: In the 'polite blocking' case, the 
information disclosed to the watcher is not really a lie, except if 
there's the understanding that providing a subscription is signing a 
contract to provide information at a certain rate and accuracy. Thus, 
simply not updating the information (not sending NOTIFY in SIMPLE) is 
not really the same as willful misrepresentation. The absence of 
notifications or the absence of change is likely to clue in the observer 
that I'm not revealing information.

2 - Reducing accuracy below knowledge: This is just a gray version of 
case 1, where I know something to a larger precision than I'm revealing. 
We commonly do this in ordinary human life. If somebody asks about 
illness in my family, I don't have to reveal all the medical details, 
even though I might know them. Thus, saying that I'm on planet earth 
hides information and clues in the watcher that I might know more 
details, but it is not lying. Some people (a certain ex-president comes 
to mind) make this an art form, but it seem devious mostly if you 
interpret the question in a very, narrow, technically-accurate sense 
that you know the questioner does not actually intend.

3 - Willful misrepresentation: The answer contradicts the facts. Stating 
that I'm in New York when I'm in New Jersey is clearly lying (although 
some parts of Ellis Island are indeed in dispute...). If done artfully, 
it does not reveal my lack of trust in the individual asking, but I 
would suspect that if you do that with a person you know, they'll find 
out sooner or later and you'll be regarded as a scheming low-life, not 
just somebody who values their privacy. If a system makes it easy to 
automate the lying and this becomes known, the overall reputation of the 
system will likely suffer (see hotmail and usenet). This is particularly 
true in a system such as presence or geopriv where it is easy for the 
lied-to party to get in touch with other parties and compare notes.

 From all I can tell, only support for (1) and (2) is required by 
existing requirement documents.

As I noted before, even if we were to support (3), it seems unlikely 
that a simple XML-based rule set would be sufficiently credible to 
really lie in a convincing way. For true lying, you need the power of C# 
or Java...

If we ignore the mistress, witness-protection and secret service cases, 
the only interaction I can think of where lying may be considered 
valuable is if a web service requires me to reveal information to gain 
access to the service. (E.g., the Washington Post seems to require that 
one offer one's gender, birthyear and zipcode before gaining access). I 
gather lots of people deviate a bit from their driver's license when 
answering these questions. It's probably not ethical (if I don't like 
the conditions a business imposes, I should go elsewhere), but may well 
be common. We don't know if such services will require highly accurate 
information or whether information that identifies me as a member of a 
group of 20 million people will be sufficient.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Sep 2003 21:42:05 -0400

[email-masked] wrote:

> your location under certain circumstances and that this location is held 
> to be valid

The alibi data could be delivered to all watchers or only delivered to 
certain watchers (the spouse in the running example). This only requires 
a selection mechanism, as we already need the ability for a location 
server to select from different representations. (For a completely 
different example unrelated to lying, I might want to deliver my 
802.11-derived location information indoors, but GPS outdoors.)

> GeoPriv sense; it
> simply implies that you can adjust location provider by configuration.  
> If you do intend
> it to apply only to certain watchers, then we're back to a serious set 
> of issues, including

Not necessarily. All I need is to do labeling of data and a selector. 
Consider the following rule, expressed in the 'conditional statement' 
version of my rule model:

if (observer=FBI)
   select class=alibi

or

if (area=indoors)
   select class=802-11

RPID, for example, has such a class attribute for tuples.

>> usage by sending information which could have been algorithmically 

As I point out elsewhere, any self-respecting liar (if there's such a 
thing) would need to have more than just constants in his lies. Thus, 
you either need to have a rulemaker that updates the lie or a publisher 
that publishes a new document. Both are roughly equivalent, except that 
the publisher mechanism does not require the cooperation of the location 
server (or PA, in the SIMPLE context) and thus is likely to be more 
flexible.

> 
> 
> This seems to me to be more flexibility than GeoPriv can handle at the 
> moment.  The bang for
> this buck seems awfully small, and the delay larger than is warranted.  

Are you referring to the ability to lie in general, the ability for the 
LS to transform my location into a lie or the ability to publish two 
location object and allow for selection?

I have to admit that I find adding complexity for willful 
misrepresentation a waste of resources (and hope that Ted's statement 
agrees with that...).

> Just my opinion, of

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Sep 2003 21:49:45 -0400

Jonathan Rosenberg wrote:

> information - namely, that the user is explicitly given out conflicting 
> information depending on the sphere - and this may not be desirable.

In the 'class' model I mentioned earlier, the sphere input selects the 
class. Thus, you get to decide what happens:

if (sphere = home)
   publish class=1
if (sphere = home,work)
   publish class=1
if (sphere = work)
   publish class=2

qualified as necessary by location, watcher/recipient (boss vs. friend), 
etc.

Alternatively, you can use sphere as both condition and selector
if (sphere = home)
   publish sphere=home
if (sphere = home,work)
   publish sphere=home
if (sphere = work)
   publish sphere=work

This allows the rule maker to make an explicit decision to whatever 
granularity is desired.

Here, 'publish X=Y' means "publish tuples/geo-elements where element X 
has value Y.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 19 Sep 2003 21:22:45 -0500

I think this is a good summary of the discussion, and I agree with what you 
stated

At 09:07 PM 9/19/2003 -0400, Henning Schulzrinne wrote:
>simply not updating the information (not sending NOTIFY in SIMPLE) is not 
>really the same as willful misrepresentation. The absence of notifications 
>or the absence of change is likely to clue in the observer that I'm not 
>revealing information.
>
>2 - Reducing accuracy below knowledge: This is just a gray version of case 
>1, where I know something to a larger precision than I'm revealing. We 
>commonly do this in ordinary human life. If somebody asks about illness in 
>my family, I don't have to reveal all the medical details, even though I 
>might know them. Thus, saying that I'm on planet earth hides information 
>and clues in the watcher that I might know more details, but it is not 
>lying. Some people (a certain ex-president comes to mind) make this an art 
>form, but it seem devious mostly if you interpret the question in a very, 
>narrow, technically-accurate sense that you know the questioner does not 
>actually intend.
>
>some parts of Ellis Island are indeed in dispute...). If done artfully, it 
>does not reveal my lack of trust in the individual asking, but I would 
>suspect that if you do that with a person you know, they'll find out 
>sooner or later and you'll be regarded as a scheming low-life, not just 
>somebody who values their privacy. If a system makes it easy to automate 
>the lying and this becomes known, the overall reputation of the system 
>will likely suffer (see hotmail and usenet). This is particularly true in 
>a system such as presence or geopriv where it is easy for the lied-to 
>party to get in touch with other parties and compare notes.
>
> From all I can tell, only support for (1) and (2) is required by existing 
> requirement documents.
>
>As I noted before, even if we were to support (3), it seems unlikely that 
>a simple XML-based rule set would be sufficiently credible to really lie 
>in a convincing way. For true lying, you need the power of C# or Java...
>
>the only interaction I can think of where lying may be considered valuable 
>is if a web service requires me to reveal information to gain access to 
>the service. (E.g., the Washington Post seems to require that one offer 
>one's gender, birthyear and zipcode before gaining access). I gather lots 
>of people deviate a bit from their driver's license when answering these 
>questions. It's probably not ethical (if I don't like the conditions a 
>business imposes, I should go elsewhere), but may well be common. We don't 
>know if such services will require highly accurate information or whether 
>information that identifies me as a member of a group of 20 million people 
>will be sufficient.
>
>
>Henning
>
>

cheers,
James

                                *******************

---

From: John Pagonis <[email-masked]>
Date: Mon, 22 Sep 2003 11:26:31 +0100

hi,
In our experience with mobile devices and smart phones, I'd say that 
there are many cases wher users may be more paranoid than you'd expect 
and do wish to hide/lie. Moreover they actually would not use a certain 
location-aware system if at least they didn't have the _option_ to lie 
-  if and when they needed to.

Therefore we concluded that  this is not a technological issue and 
infact technology should not stand in the way of people (and what they 
wish to do with it), since this is a political/ethical/social thing 
(something like MP3 file ripping) which indeed may have legitimate 
causes. Option (3) in my opinion should be part of the ''system''.

cheers
/JP

Henning Schulzrinne wrote:

> notifications or the absence of change is likely to clue in the 
> observer that I'm not revealing information.
>
> case 1, where I know something to a larger precision than I'm 
> revealing. We commonly do this in ordinary human life. If somebody 
> asks about illness in my family, I don't have to reveal all the 
> medical details, even though I might know them. Thus, saying that I'm 
> on planet earth hides information and clues in the watcher that I 
> might know more details, but it is not lying. Some people (a certain 
> ex-president comes to mind) make this an art form, but it seem devious 
> mostly if you interpret the question in a very, narrow, 
> technically-accurate sense that you know the questioner does not 
> actually intend.
>
> 3 - Willful misrepresentation: The answer contradicts the facts. 
> Stating that I'm in New York when I'm in New Jersey is clearly lying 
> (although some parts of Ellis Island are indeed in dispute...). If 
> done artfully, it does not reveal my lack of trust in the individual 
> asking, but I would suspect that if you do that with a person you 
> know, they'll find out sooner or later and you'll be regarded as a 
> scheming low-life, not just somebody who values their privacy. If a 
> system makes it easy to automate the lying and this becomes known, the 
> overall reputation of the system will likely suffer (see hotmail and 
> usenet). This is particularly true in a system such as presence or 
> geopriv where it is easy for the lied-to party to get in touch with 
> other parties and compare notes.
>
> really lie in a convincing way. For true lying, you need the power of 
> C# or Java...
>
> If we ignore the mistress, witness-protection and secret service 
> cases, the only interaction I can think of where lying may be 
> considered valuable is if a web service requires me to reveal 
> information to gain access to the service. (E.g., the Washington Post 
> seems to require that one offer one's gender, birthyear and zipcode 
> before gaining access). I gather lots of people deviate a bit from 
> their driver's license when answering these questions. It's probably 
> not ethical (if I don't like the conditions a business imposes, I 
> should go elsewhere), but may well be common. We don't know if such 
> services will require highly accurate information or whether 
> information that identifies me as a member of a group of 20 million 
> people will be sufficient.
>
>
> Henning
>
>
>

**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [email-masked] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************

---

From: Carl Reed <[email-masked]>
Date: Mon, 22 Sep 2003 09:05:37 -0600

In the case of option 3, would not the location application server
technology utilize preferences set by the user on their mobile device to
"lie" about their exact location, thereby obviating the requirement to
accommodate such "lying" at the geopriv object rule level?

The geopriv object for a given message instance would be composed after the
"lie" had occurred and as such the application building the geopriv object
may not even be provided the knowledge that a "lie" had occurred - so why
should we worry about the case of willfully "lying"??

Carl

----- Original Message ----- 
From: "John Pagonis" <[email-masked]>
To: "Henning Schulzrinne" <[email-masked]>
Cc: "James M. Polk" <[email-masked]>; "Jonathan Rosenberg"
<[email-masked]>; "Tschofenig Hannes"
<[email-masked]>; "John Morris" <[email-masked]>;
<[email-masked]>
Sent: Monday, September 22, 2003 4:26 AM
Subject: Re: Georpiv and actively lying

> Symbian Ltd is a company registered in England and Wales with registered
number 01796587 and registered office at 19 Harcourt Street, London, W1H
4HF, UK.
> This message is intended only for use by the named addressee and may
contain privileged and/or confidential information. If you are not the named
addressee you should not disseminate, copy or take any action in reliance on
it. If you have received this message in error please notify
[email-masked] and delete the message and any attachments
accompanying it immediately. Symbian does not accept liability for any
corruption, interception, amendment, tampering or viruses occurring to this
message in transit or for any message sent by its employees which is not in
compliance with Symbian corporate policy.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 22 Sep 2003 08:32:26 -0400

Allowing end systems to publish multiple locations does allow for (3). I 
believe Jonathan remarked that this would be too bandwidth-intensive for 
mobile devices. I don't think this will be a problem in practice. You 
might divide the world of liars into two:

(1) amateur liars: they set their fake location to one value and leave 
it unchanged the whole day; in that case, it makes no difference whether 
this is conveyed as a rule from the rulemaker or as a location object 
from the moving target or from a third-party ("alibi-r-us") from a 
stationary server.

(2) professional liars: they create elaborate plots where they move 
frequently and in a plausible fashion (no wormhole jumps from New York 
to California that any decent credit card fraud detector would catch). 
For them, lying based on setting location object values via the rule set 
is not useful - they'd have to update the rule set every few minutes, 
which is likely to be much larger than the LO itself. They would either 
update the location from their end system or would contract with a 
server, their own or alibi-r-us, to update the location automatically. 
If we assume that a location update is about 400 bytes, each 
mobile-initiated lie costs about 0.16 cents at the going rate of $4/MB 
for mobile data.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 22 Sep 2003 14:39:01 -0400

> accommodate such "lying" at the geopriv object rule level?

That's what I've been arguing. My model is that a target can emit any 
number of location objects, marked by a 'class' label. Naturally, the 
target doesn't have to send the objects themselves, but may delegate the 
task to various stand-ins, such as a personal server.

The location server, using rules provided by the rulemaker, selects one 
or more of these location objects, where the selection can depend on the 
person receiving the data and any other factor.

It is immaterial to the protocol operation whether any of the objects 
contain the truth about the person's status and whereabouts. That's a 
layer-8 problem that is no more of concern to GEOPRIV and the IETF as to 
whether the email message from Nigeria will indeed make you rich. (There 
may well be location servers that make claims of truthfulness as part of 
their service offering.)

> should we worry about the case of willfully "lying"??

I agree that we should not and need not concern ourselves with this 
problem if we follow the model that the location server should restrict 
itself to redactions and precision reductions. (From a service provider 
perspective, this affords the nice advantage of plausible deniability. I 
suspect that service providers would be quite hesitant to provide a 
service where they knowingly assist in users providing fraudulent 
information.)

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Sep 2003 21:49:45 -0400

if (sphere = home)
   publish class=1
if (sphere = home,work)
   publish class=1
if (sphere = work)
   publish class=2

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Andrew Newton <[email-masked]>
Date: Tue, 23 Sep 2003 22:32:29 -0400

Everyone,

This was announced before, but it could probably need repeating:

GEOPRIV has a new mailing list.  It is [email-masked].  Please 
discontinue the use of the old list, [email-masked].

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 Sep 2003 22:47:43 -0400

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 17 Sep 2003 17:29:25 -0500

comments below

cheers,
James

                                *******************

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 22 Sep 2003 14:39:01 -0400

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 22 Sep 2003 08:32:26 -0400

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 19 Sep 2003 21:22:45 -0500

cheers,
James

                                *******************

---

From: Andrew Newton <[email-masked]>
Date: Tue, 23 Sep 2003 22:32:29 -0400

Everyone,

-andy

---

From: [email-masked]
Date: Wed, 17 Sep 2003 18:19:53 -0700 (PDT)

why is this a need?

--bill

---

From: Carl Reed <[email-masked]>
Date: Mon, 22 Sep 2003 09:05:37 -0600

Carl

---

From: John Pagonis <[email-masked]>
Date: Mon, 22 Sep 2003 11:26:31 +0100

hi,

cheers
/JP

---

From: [email-masked]
Date: Fri, 19 Sep 2003 15:38:32 -0700

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Sep 2003 21:42:05 -0400

if (observer=FBI)
   select class=alibi

or

if (area=indoors)
   select class=802-11

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Sep 2003 21:07:54 -0400

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Sep 2003 16:30:16 -0400

inline.

Privacy, of course.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Sep 2003 16:50:11 -0400

-Jonathan R.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 19 Sep 2003 19:02:50 -0500

in-line

cheers,
James

                                *******************

---

From: Carl Reed <[email-masked]>
Date: Wed, 17 Sep 2003 18:53:40 -0600

Cheers

Carl