Subject: Re: [Geopriv] geopriv-policy plans

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 May 2011 05:33:37 +0300

Hi Martin 

> Some of the goals and constraints that we discussed (and may have agreed on to varying degrees) were:
> 
> Constraints
> 
> - The algorithm must take only one policy input: a distance in meters.  Other parameters need to be fixed in the definition of the algorithm.

This sounds strange. If you only demand a single input then there are no other parameters. 
So, I guess you are saying that there is at least one parameter, namely distance in meters. 

> 
> - The algorithm must describe what to do with uncertainty on the input location(s).

Is it OK to say that the input to the algorithm is a point even if that input parameter was computed from some other location shape prior to sending it to the input of the algorithm. 
I am trying to point out that many of the use cases we will see today will use a point as approximation even though there are theoretically all sorts of complex location shapes.

> 
> - The algorithm must be accurate [duckham05] - that is, the reported location must enclose the known location at the time that it is reported
> 
I am OK with the statement that the reported location must enclose the known location. 

> Goals
These goals are all phrased as "should". It would therefore be fine to have an algorithm that supports none of these. 

> - The algorithm should protect a static known location.
> 
I would drop the "known" phrase. I doubt that the algorithm can provide against "unknown" location. 

> - The algorithm should protect the known location when the target moves.  I admit that this needs to be more specific.
> 
> - The algorithm should protect the known location when the target returns to the same approximate location multiple times.

I guess this is a sub-category of mobility. 
> 
> - The algorithm should limit the knowledge that an adversary gains about known locations at different times or locations, if an adversary learns of a known location for a given reported location.  That is, if an adversary finds a known location, they can't use that information to (perfectly) derive known locations from other reported locations.

While it is OK to say "limit the knowledge the adversary can gain" but we have to keep some fundamental limitations in mind. 

Ciao
Hannes

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

---

From: Jorge Cuellar <[email-masked]>
Date: Fri, 20 May 2011 12:23:50 +0200

Hi Martin,

as we spoke in Prague, I have now a student who will implement some
variants of the geopriv protocol.  You mentioned we could use your (?)
GUI to run tests and display the results (and perhaps also compare
different solutions?).

Shall we simply use directly

http://processing.org/

or should we use a particular SW that you have or host?

Best,

Jorge

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 23 May 2011 06:47:28 +0800

Processing is the software that Robert and I have used to visualize the algorithms.
	
Alternatively, you can take a copy of the code from this page:

http://held-location.sourceforge.net/js_geoshape/maptest.html

It's all pretty straightforward to retrieve and use, the algorithm is implemented in fuzz.js.  All you need to do is replace that file with a new one that defines a GeoShape.Fuzzer class.  The ``GeoShape.Fuzzer.fuzz(shape : GeoShape) : GeoShape.Circle'' method is the only method that the rest of the code uses directly.

For the most part, these are really only helpful for conceptualizing the algorithm, understanding how it works.  They wont be a great deal of help in performing an analysis.

I linked to the processing examples here:

http://www.ietf.org/mail-archive/web/geopriv/current/msg09000.html

I can send more privately if you want to explore more.

--Martin