Subject: RE: full integrity?

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Thu, 23 May 2002 15:33:51 -0600

Aleksandar Gogic wrote:

> I'm more on Eric's side of the argument.  It's just
> as effective to say "stuff it", as it is to provide 
> false information, in terms of privacy protection at
> least.  

Only if you believe you have prevented false information from being injected in the first place. The right metaphor for this is the concept of "universal precautions" used by emergency personnel--you take some simple precautions (face mask, gloves), assuming the patient *might* have AIDS or another blood-communicable disease until proven otherwise; the alternative is to rely on society at large not sending infections your way. In other words, not sending false data and not being overly trusting of data in general are two separate things

And by the way in practice, undercover law enforcement agents will be able lie about location and will do so under the full protection of the law. Nothing we do in the protocol can preclude this use case from being realized.

--Andy

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Thu, 23 May 2002 15:38:19 -0600

Randall Gellens wrote:

> At 5:09 PM -0400 5/22/02, Richard Shockey wrote:

> >   ..you would have really enjoyed the IETF debates on wiretapping 
> > several years ago :-)
> 
> I recall those debates well; that issue has relevance to our work 
> here, but not to the question I have tried to raise.  (The 
> wiretapping issue relates to how much attention we pay to regulatory 
> and legal constraints.)

This is an important point, because there are conflicting legal constraints in this space and the official conclusion of the wiretapping debates was framed in terms of law and regulation, not privacy activism (though you'd never know it from the plenary rhetoric).

--Andy

---

From: Dan Greening <[email-masked]>
Date: Fri, 24 May 2002 03:24:52 -0700

I agree with the flavor of James' approach (summarized by his last
paragraph), with the exception of the error representation.

First, simple radius errors should be in some linear measure, like
meters, rather than degrees.  Meters are preferred by applications
(although I'm also aware that a few applications want degrees--they can
convert to get it).

Second, the error boundaries returned by mobile phones are never boxes,
sometimes circles, sometimes ellipses, sometimes "bananas" (region
defined by two angles and two radiuses from a single center point) from
cell-id/timing-advance, and rarely other things (but they exist).  

Many applications want this error term very precise.  Returning a sloppy
box when reality is a banana shape is perhaps a programming convenience,
but there is a real end-user usability problem when you do it.  You
might make the user have to choose from many more streets or
intersections, because the bounding box could contain well over twice
the area of the banana shape. 

Dan Greening, Ph.D.  CEO, BigTribe Corporation 
              330 Townsend Street, Suite 209, San Francisco, CA
94107-1662 
              [email-masked]  +1(415)995-7151  fax 995-7155

-----Original Message-----
From: James Card [mailto:[email-masked]] 
Sent: Thursday, May 23, 2002 11:16 PM
To: [email-masked]
Subject: RE: full integrity?

5/22/02 1:48:59 PM, Randall Gellens <[email-masked]> 
wrote:

>I was trying to get an idea of how wg participants felt about 
>accuracy adjustments being the primary method of disclosure 
>control, as opposed to also allowing multiple locations.

My preference would be to always transmit exactly two spatial 
coordinate sets (minimal case, two lat/lon points; with optional 
altitude and/or direction/velocity vectors). 

The process I currently envision would be something like this:

1. Calculate the current (most recent) geospatial position, 
   returning a single point. Let's make an example with very 
   simple math: 2 degrees north latitude, 2 degrees east 
   longitude. 

2. Calculate the estimated error or degree of precision. In this 
   example we'll say it is +/- 0.2 degree longitude, +/- .1 
   degree latitude.

3. Add and subtract the estimated error to create a bounding 
   box.  Our example location is now defined by two lat/lon 
   points: one at 1.9 degrees north, 1.8 degrees east; and the 
   other at 2.1 degrees north, 2.2 degrees east.

   This represents the best-case calculation of position, and 
   would be transmitted only in response to requests whose 
   authentication/authorization/policy clearance matched the 
   highest level of trust.

4. All other requests would cause a further calculation to 
   expand the size of the bounding box surrounding the location. 
   The size of the resulting box would vary in inverse 
   proportion to the degree of trust assigned to the request 
   (through the policy/authentication mechanism).

The result might be something like the following diagram, where 
the "o" represents the single point from step 1, the small box 
(with the "*" characters marking the reference points of the 
bounding box) presents the highest-precision estimate of 
position from step 3, and the large outer box might be the 
coordinates provided to less trusted requestors.

   +------------------------------------------------*
   |                                                |
   |   +-------*                                    |
   |   |   o   |                                    |
   |   *-------+                                    |
   |                                                |
   |                                                |
   |                                                |
   |                                                |
   *------------------------------------------------+

The recipient of the data would always understand that the 
actual position is contained within the bounding box, and could 
then determine whether that provides enough "accuracy" for their 
purpose.

I see no need to transmit any additional "confidence level" or 
"degree of precision" information. You always get exactly two 
lat/lon points. Applications that require a single lat/lon point 
may simply calculate the centroid of the bounding box.

I also see no need to transmit more than one set of location 
data in any given transaction. The requestor can always assume 
that they have received the most accurate information available 
(given the authentication/policy status of their request).

This is admittedly a very simplified model -- and that is what I 
like about it -- but I believe that we've slogged through arcane 
detail and abstract discussion long enough; I needed a simple 
way to summarize my thinking about the multiple locations / 
accuracy adjustment question.

To summarize: I favor full integrity, always transmitting the 
the greatest precision that is consistent with the policy 
mechanism under which the request was authenticated.

-- 
James Card  --  http://home.inreach.com/jdcard/
The wise person restrains his words, and the one who keeps 
his cool is a discerning person. -- Proverbs 17:27