Re: [Ecrit] Location hiding: Consensus?

[Henning Schulzrinne <hgs at cs.columbia.edu>]

On May 9, 2007, at 10:06 AM, Andrew Newton wrote:

> So what is the reason for supporting location hiding?  Otherwise,  
> you seem to be arguing that your view location hiding is correct  
> and cannot be questioned.  I have simply pointed out that location  
> hiding should hide all location information and that there are good  
> reasons for it.  I certainly would like to hear your reasons why my  
> arguments should not be considered.

Location hiding is not an ECRIT charter goal and is not in any of the  
current requirements documents. So far, the only actual user  
requirements are for partial location hiding. Thus, I see no reason  
to support something that no implementors seem to be asking for, but  
which makes the system more brittle, imposes, on end users, costs and  
complexity.

Are you suggesting that, from a technical standpoint, hiding location  
from the end system is a good idea?

We can continue to invent requirements, and continue to make the  
system more complex and less debuggable. I fail to see the value in  
that.

> > > While centroid calculations on polygons may be something we end  
> > > up needing to do, the normal case would not seek to avoid holes -  
> > > or jurisdictions contained entirely in another jurisdiction.   
> > > However, for location hiding, the centroid calculation would have  
> > > to compensate for any holes to avoid misrouting the call.
> >
> > However, that pothole-avoidance computation only needs to be done  
> > by the LIS, not the LoST server. Thus, the computational and  
> > complexity burden is imposed on the party that is restricting  
> > access to location information, which seems to me to be the right  
> > trade-off.
>
> I don't think calling jurisdictions contained within other  
> jurisdictions "potholes" is a good idea.  But the hole-avoidance  
> computation needs to be done by the validating seeker, which is the  
> VSP.  And it needs to know when it is to do the hole-avoidance vs.  
> just a normal polygon lookup.

Unfortunately, in your model, the VSP would have no way to do any  
validation at all, since it is not operating a trusted LoST server,  
according to our 'no business relationship' requirement and thus  
can't resolve the reference. Thus, your model actually fails to  
support the validation requirements. That's certainly good to note.




> If that is not the case, perhaps I misunderstanding how this is to  
> work.  Could you describe the inputs, computations, and outputs at  
> every step in the process?

I'm using Brian's variation of my proposal. The LIS computes, based  
on its querying of LoST, a geometric shape such as a polygon or  
circle whose centroid/center lands in the right PSAP and includes the  
current location of the client, presumably somewhere other than in  
the center.

The VSP does exactly the same computation, again taking the center of  
the circle to do the lookup. Thus, it performs no special operation  
and is not concerned with holes in service areas at all.

If the PSAP is a convex polygon, there's no need for the LIS  
computation, but the verifying VSP doesn't care one way or the other.


> > > > > Issue 1-3 UAs must now be forbidden from conveying dereferenced  
> > > > > location information.
> > > >
> > > > I don't see why. LocationConveyance supports multiple locations.
> > >
> > > For the normal case, there is nothing wrong with an end point  
> > > dereferencing an LbyR and passing along the location information  
> > > as a value.  With location-hiding, you don't want an endpoint  
> > > doing this because the coarse location may have compensated for a  
> > > hole and its centroid might not be accurate enough for dispatch.
> >
> > I think this is an instance of a general problem, namely that the  
> > SIP INVITE may contain multiple locations with different  
> > characteristics. For example, it could contain a (fixed) value and  
> > a reference that's updated based on movement of the caller. In  
> > that case, you also have a location (value) that may no longer be  
> > suitable for dispatch, and another (reference) which is  
> > preferable, i.e., exactly the same behavior.
>
> Perhaps it is my reading of the phone-bcp document.  Steps 10, 11,  
> & 12 in section 6.1 talk about what to do here.  There are no steps  
> that say "do not dereference an LbyR and use the result as an  
> LbyV".  Now that must be expressly disallowed, though your example  
> above also provides a good reason to disallow it.

I suspect clarifying text is in order here.


> > I'd be the last to defend location hiding as desirable, but I fail  
> > to see why providing no location at all is preferable to providing  
> > some location. As noted on the Wiki, having some location at least  
> > allows the end system/user to detect gross errors before placing a  
> > call.
>
> Well, I think it would be preferable to fully support location  
> hiding rather than to only partially support it.  But suggesting  
> that end users will be able to know gross location errors is a bit  
> of wishful thinking.  For lat/long, I doubt most users would be  
> able to know.  As for civic, I always tend to get confused when  
> I've driven into Montgomery Co., MD, when I'm in DC -- knowing the  
> demarkation for various civic jurisdictions isn't something you can  
> count on an end user understanding.

Civic addresses are primarily of interest for the residential case,  
and I suspect most people know their street address enough to  
recognize that they've been placed in the wrong town or county.

Given the availability of Google Maps, I don't see much of a problem  
with visualizing that location on such a map.

I'm not claiming that everyone will do this, but that doesn't make it  
useless. Discovering some mistakes ahead of time seems to beat  
discovering none.


Henning



_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit