Hello,
Nice to see that some discussion has started in this WG. I hope we get our
slot in upcoming IETF meeting soon.
Currently, their are two general types of location services. Macro location
aware services, which have an accuracy of around 100 meters. For example,
local area information, restaurant guides etc are provided to mobile phone
users depending upon their location in DoCoMo's network in Japan. The
operator has a rough estimate of the location of a user at all times. Micro
location aware services, such as GPS based navigation, have much greater
accuracy. In most cases the user's location is known to the user (or his
device) himself and his privacy is not compromised.
Future mobile systems will use highly accurate location information which
may include the user's precise location even inside a building, the user's
orientation and the direction in which he is looking etc.
I believe that privacy of location is a part of a much bigger problem i.e.
the privacy and security of context information.
By context I mean any information that maybe used to describe the situation
of an entity.
For example context information may include:
the user's identity;
spatial information e.g. location, orientation, speed, and acceleration;
temporal information - e.g. time of the day, date, and season of the year;
environmental information - e.g. temperature, humidity, and light or noise
level;
social situation - e.g. who you are with, and people that are nearby;
resources that are nearby - e.g. accessible devices, and hosts;
availability of resources - e.g. battery, display, network, and bandwidth;
physiological measurements - e.g. blood pressure, heart rate, respiration
rate, muscle activity, and tone of voice;
activity - e.g. talking, reading, walking, and running;
personal preferences and capabilities;
schedules and agendas etc.
Next generation mobile systems will need to take into account the user's
context in order to provide meaningful services. It is not just the
privacy/security of the location that needs to be taken care of, but we need
a framework that ensures the privacy of all contextual information and still
provides mechanisms for reliable service delivery.
As I see it, we can either do this now or wait for another five years and do
it then.
Best Regards
Shahid Shoaib
----------------------------------------------------------------------------
--------------------------
Shahid Shoaib +1-408-451-4740 Direct
DoCoMo USA Labs Inc. +1-408-573-1090 Fax
shahid@dcl.docomo-usa.com http://www.docomo-usa.com
----- Original Message -----
From: "Valentin Christoph" <christoph.valentin@siemens.at>
To: <geopriv@mail.apps.ietf.org>
Sent: Thursday, July 12, 2001 6:01 AM
Subject: RE: combination of location and identity
> Hello all,
>
> I agree with Mr. Hauser's theses and I'm also glad that I have found this
> WG.
>
> About the proposal to distinguish between the location and its
> "representations", I suggest to consider the following representations:
>
> - geographical coordinates (with or without altitude), maybe plus time
> coordinate
> - postal address
> - telephone number's country/city prefix etc.
> - access network specific identifier
> e.g. CGI/SAI (cell global identifier/Service Area Identifier of a
> GSM/UMTS network)
>
> I also agree with Mr.Takahashi, who wrote on July, 2nd: "I think, in first
> place, we need a common understanding on what are location-based services
to
> discuss security and privacy."
>
> I suggest the following preliminary list of procedures using location
> information:
>
> 1.) Location information associated with a common resource
> Some Internet Resource (HTML document) is indexed by geographic
coordinates
> (or another representation of location). This case is considered in
> draft-daviel-html-geo-tag-05.txt.
> Such a document could for instance, be a contract, which is associated
with
> time and space coordinates (WHERE and WHEN did the contractors sign it)
and
> which is made available for the public.
> It could also be a restaurant guide or something similar, which has only
> significance in a distinct region, but is of public interest.
>
> 2.) Request location information associated with a static interface/node.
> This case is considered in rfc1876, where is described, how to incorporate
> geographic information into the DNS.
> This information is useful for the network operator, but it should be
> accessible in a very restricted manner, because serious damage of network
> infrastructure could result from a wrong person getting this information.
>
> 3.) Request location information associated with a mobile interface
> (notebook, mobile phone, router in an airplane...)
> This may result in a lot of nice applications, but there has to be the
> permission of the owner of the interface to reveal this location
> information.
>
> 4.) Request "geographic infrastructure information" based on a given
> location.
> A user requests a map (2D or 3D-map) with a given resolution about a given
> region.
> (Could also be indexed by time coordinate, if it is a political map with
> borders - you know, borders change by time, as in Yugoslavia)
> The region given in the request should not be traceable by anyone, because
> most likely this will be the location of the requestor, or at least a
> region, the requestor is interested in.
>
> 5.) Request location dependent information from a given provider (server).
> This is similar to case 1., but a trustet relationship between the
provider
> and the requestor is assumed. On the one hand the provider guarantees,
that
> nobody else gets the information about which place the requestor is
> interested in, on the other hand the requestor is authenticated and
> authorized to get this information (and he will pay for it - accounting).
>
> 6.) Anonymous push services
> Depending on the change of the current location (of the terminal
equipment),
> a user gets publicly available information in an anonymous manner.
>
> 7.) Authorized push services
> Depending on the change of the current location (of the terminal
equipment),
> a user gets information which is provided to a specific group.
>
> Best Regards
> Christoph Valentin
> SIEMENS Austria
> Program and System Engineering
>
>
> > -----Original Message-----
> > From: Christian Hauser [mailto:lobase@gmx.net]
> > Sent: Thursday, July 12, 2001 9:53 AM
> > To: geopriv@mail.apps.ietf.org
> > Subject: combination of location and identity
> >
> >
> > Hello,
> >
> > I'm very glad to find this group, which covers one of the
> > most interesting
> > and important topics of today. Currently, I'm doing some
> > research on privacy
> > issues of location-based services. I would like to
> > participate in this group
> > and to contribute to a common understanding of this topic.
> > Actually, I have
> > two contributions:
> >
> > 1) Reading the literature, I was wondering, if it could help
> > to clarify,
> > what we exactly think of when talking about "location". My
> > proposal would be
> > that "location" is a certain place (on earth?), which has several
> > "representations", e.g. a coordinate or a symbolic
> > representation like "The White House".
> >
> > Within certain user groups, these representations are well
> > known and thus
> > equivalent to a location (meaning of a WGS84 coordinate is
> > nearly globally
> > known, the exact place of "The White House" is known by a
> > certain group of
> > people, too), whereas some groups do not know (exactly) the
> > according place (some
> > people only know the rough area, "The White House" is situated in).
> >
> > Moreover, thinking of user identifiers including location
> > representations
> > (like "president@whitehouse.gov" or an IP address), these can
> > be linked to a
> > more or less exact place dependent on the attacker's
> > knowledge (e.g. knowledge
> > of the IP address topology). Apart from that, some
> > identifiers reveal just
> > the location of the user with regard to network topology
> > (e.g. the home network
> > "whitehouse.gov") but not the geographic location of the user.
> >
> > 2) From our point of view, the degree of danger risen by disclosure of
> > location information primarily depends on two parameters,
> > regarding user privacy.
> > The first and most obvious one is the granularity (precision,
> > resolution) of
> > the location information, which is a kind of entropy of this
> > information.
> >
> > The second parameter, which we rate of at least same importance is the
> > information, which can be linked to the disclosed location
> > information. Regarding
> > tracking of a user ("target"), this can be seen as the
> > identity information
> > bound to the revealed location information, e.g. the user's
> > real name, a
> > pseudonym, a role (pedestrian, member of a certain group).
> > Moreover, it can also
> > be any other information, known about the target. E.g., if
> > the tracked target
> > is my cell phone or PDA it is usually located where I am,
> > thus disclosing my
> > location, too. Thinking of my car being tracked, then I am
> > likely to be, too
> > (at least if it is moving) but inference of my location is much more
> > imprecise than regarding my cell phone.
> >
> > Thus, in my opinion we do not only need to consider the location
> > information, but also other information about the target
> > linked to this location
> > information. These are two parameters to adjust the overall
> > entropy of the
> > information. For example, somebody knowing my exact location
> > may not be allowed to
> > know my exact identity (just perhaps a pseudonym) and
> > somebody knowing my exact
> > identity may not be allowed to know my exact location
> > (neither that of my
> > cell phone). Therefore, we need to control the accuracy of
> > location information
> > as well as the amount of identity information that can be
> > linked to the
> > location information.
> >
> > Does anybody agree with my theses?
> >
> > Best regards
> >
> > Christian Hauser
> > Institute of Communication Networks and Computer Engineering
> > University of Stuttgart, Pfaffenwaldring 47, 70569 Stuttgart, Germany
> >
> > --
> > Sent through GMX FreeMail - http://www.gmx.net
> >
>
Received on Thu Jul 12 15:16:06 2001
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:21 EST