Re: [Ecrit] Location hiding: Consensus?

[Andrew Newton <andy at hxr.us>]

On May 4, 2007, at 8:22 PM, Henning Schulzrinne wrote:

> > Issue HR-1 This should not be a requirement. Not all IP address  
> > based location determination systems are that accurate.  
> > Additionally, giving away course location information should not  
> > be required to hide location. Course location information even at  
> > the country level is useful commercially. One such example is  
> > Google, which uses IP address location determination at the  
> > country level to route users to language specific start pages.  
> > Access networks should be allowed to charge for location  
> > information that is as course as this, since it is a valuable  
> > asset on today's Internet. -andy
>
> We are not in the business of creating business opportunities for  
> carriers at the expense of others. As long as our main 'customers'  
> don't object, it's not our role to make life difficult and less  
> debugable for emergency services. Given that GeoMind and others are  
> giving away rough location information, the value of such  
> information is in doubt in any event.

What!?  I don't understand your response and can't seem how it is  
even directly relevant to the issue raised.

But while we are on the subject of having to do special things to  
support location hiding (which is what I think you are talking  
about), I'd like to point out that the centroid of the intersection  
idea is a special case needed only for location hiding and imposes an  
implementation burden on everybody else, even though they are doing  
location hiding.

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.

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

> > Issue 1-4 The semantic difference regarding authorization/ 
> > nonauthorization of location information is lost, making it  
> > difficult for UAs to know if they truly are not authorized to get  
> > true location information. This introduces ambiquity, which should  
> > be avoided for emergency situations.
>
> I can't parse this. There is little ambiguity in a 403 Forbidden  
> HTTP response, but in any event, the UA without credentials would  
> get location, not a refusal, just not with the same accuracy.

That's exactly the point.  If an endpoint isn't authorized to get  
location, then it should be told so.  It should not be led to believe  
that it has location as accurate as is possible.  The semantics are  
being overloaded in an ambiguous way.

> > Issue 2a-2 The work around LoST discovery needs to be completed.  
> > This is not specific to location hiding.
>
> The issue is that LoST discovery will likely return multiple  
> servers. I had earlier pointed out at least three plausible  
> operators (ISP, VSP, general public service), provided by several  
> different configuration mechanisms. The UA has to use the right  
> one, as things will fail otherwise.

I don't understand your point.  Do you believe codifying the  
preference order is difficult and too burdensome to define?

> Also, from an operator perspective, here the landline ISP has to  
> operate a LoST resolver, instead of dumb "return fixed location"  
> server.

Well, I would hope running a LoST resolver is not much more  
troublesome than running a DNS resolver.  It really isn't that big of  
a deal.  But the LIS cannot be dumb in the first place, as it must  
know about authorization policies, etc.. and know to provide fine  
location vs coarse location.

-andy

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