On Mon, 09 Jul 2012 22:48:59 +0100 Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote: > > So I have a question about this draft that wasn't > resolved on apps-discuss and is maybe more suited > for IETF LC anyway. > > With geopriv, we've gone to a lot of trouble to > support end-users having some control over their > location privacy. "Location Object (LO): An object used to convey location information together with Privacy Rules. Geopriv supports both geodetic location data (latitude, longitude, altitude, etc.) and civic location data (street, city, state, etc.). Either or both types of location information may be present in a single LO (see the considerations in [5] for LOs containing multiple locations). Location Objects typically include some sort of identifier of the Target." I'm not really sure that an IP address fits into that description. If the geopriv thought that an IP address is a LO, they should have written so in the document. But more important; I think it would be really unfortunate if the IETF would encourage people to use IP addresses as location objects, it is done already, and it works bad and breaks lot of stuff. > This HTTP header will be used by proxies to forward > on the IP address of a client, and that will be used > via geo-ip services to locate the HTTP client. IP addresses are also forwarded by ISP's routers, I am not convinced about the big difference here. It may also be relevant to note that a proxy may not proxy HTTPS-requests, so in those cases it would be enough to inline an element served over HTTPS to get the client IP address. Is that also a privacy issue? > But in this case, there's no control whatsoever > for the end user, nor are they even told that > its happened. Since it is non-trivial for end users to protect their privacy, I think education of the end users are the only way to go. This education is, however, not within the scope of this document. My point is: privacy and anonymization is hard and hairy, and an uneducated end user will "never" get this right. > That seems to me to be quite a disconnect, but > I'm not sure what if anything ought be done about > it, since in this case, there's a non-standard > header that's widely deployed that does this. > > So if we did try encourage taking the geopriv > approach we'd presumably just be ignored. Yes. Cheers, Andreas
Attachment:
signature.asc
Description: PGP signature