Subject: [Simple] Re: Georpiv and actively lying

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

Jonathan Rosenberg wrote:

> 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.

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.

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

---

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

---

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

At 4:50 PM -0400 09/19/2003, Jonathan Rosenberg wrote:
>Henning Schulzrinne wrote:
>
>>James M. Polk wrote:
>>
>>>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.
>>
>>
>>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'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.

>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.

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: [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

[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.

>> 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.

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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Sep 2003 16:50:11 -0400

Henning Schulzrinne 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 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.

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.

> 
> 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.

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.

-- 
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

---

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

-Jonathan R.

---

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: Andrew Newton <[email-masked]>
Date: Tue, 23 Sep 2003 22:32:29 -0400

Everyone,

-andy