[IP] more on Location tracking -- for people, products,

[Seth David Schoen]

places -- is fast coming into its own / It's 11 o'clock. Do you know
where your _______ is?


David Farber writes:


>Begin forwarded message:
>
>From: Dennis Crowley <dens at dodgeball.com>
>Date: October 12, 2005 3:37:56 PM EDT
>To: dave at farber.net
>Subject: Re: [IP] Location tracking -- for people, products, places
>-- is fast coming into its own / It's 11 o'clock. Do you know where
>your _______ is?
>
>
>
>>Location enabled and mobile computing have been watchwords for such
>>a long time, it's
>>nice to be using something that actually makes use of these ideas
>>and to see what
>>the accidental or deliberate social implications are.
>>
>
>hi dave -
>
>saw the post about Plazes  and wanted to send this along as well.
>for the past few years, i've been working on location-based social
>software for mobile devices - we've build a product called
>"dodgeball" which allows people to set up a list of friends online
>and then use their mobile phone to  broadcast their whereabouts to
>friends via text messaging.  once dodgeball knows of your location,
>it will look at all the other users who have "checked-in" nearby to
>see if it can match you up with a nearby friend-of-friend or someone
>from your "crush list".
>

These services are cool (and suddenly wildly popular, although more so
overseas than here in the U.S.), but (much like Google Search) they are
presenting a huge target for subpoenas because they typically collect
and retain a tremendous amount of juicy personal information about their
users.

Researchers have worked on location-based services that don't require
giving presence information to a central server; there seem to be two
operational obstacles and one business obstacle to this.  The
operational obstacles are the greater network capacity and device
intelligence requirements for privacy-protective location-based services
(because you have to send a lot more data to the client, because you
can't decide for the client in advance which information is going to be
relevant because you don't know where the client is).  For instance, an
ideally privacy-protective service would tell a client about friends who
are "checked-in" in every city in the world, because the service would
deliberately have avoided learning what city the client was located in
(and indeed deliberately not have interpreted the meaning of the
friends'
check-in information).  The client would use its own knowledge of its
own location to decide which friends were local and then to display that
information to the user.  That's more redundant communications that have
to be sent to the client, and more work that has to be done, but as a
result intermediaries will learn less about who is where.

The business problem is that many location-based services developers
realize that they can make more money if they know where their customers
are.  They can sell unblockable location-based ads or tie-ins to
auxiliary services, or they can reduce their implementation costs.  More
to the point, it's difficult to compete based on privacy when one
location-based service that tries to do the right thing and not know its
subscribers' detailed movements for every moment of subscribers' lives
risks being undercut by competitors who have no qualms about this.
Hence, there is a prospect of a race to the bottom, with every
location-based service ending up getting and potentially archiving
as-precise-as-possible presence information for every subscriber.

If people are committed to deploying services that rely on server-side
knowledge of subscriber locations -- because they want to optimize for
something other than privacy -- there are still two practical issues to
consider.

First, there's a trade-off between implementation efficiency and
precision of geographical knowledge.  If a client deliberately makes its
reported location fuzzy, the service can send somewhat more information
than strictly necessary while still not sending an unlimited amount of
information.  Here are a few points along the continuum:

(1) The client says "I'm somewhere in the world"; the server says "OK,
here are maps of every city in the world and the encrypted locations of
all your friends everywhere in the world".  The client then picks out
the map and the friends' locations that it concludes are relevant.
(If and when we have the communications capacity, this is the ideal for
subscriber privacy; the intermediary _does not have to know anyone's
location at all_.)

(2) The client says "I'm in New York City"; the server says, "OK, here
is a map of all of New York City, and the locations of all your friends
who told me that they were in New York City".  The client then picks out
the region of the map that's relevant and displays the locations of
friends who appear to be nearby.

(3) The client says "I'm on the Upper West Side in New York"; the server
says, "OK, here is a map of the Upper Wide Side, and the locations
of all your friends in that neighborhood"; the client again displays
the subset that it finds relevant.

(4) The client says "I'm on the east side of Broadway between 93rd
and 94th"; the server says "Your friend Josephine is on Broadway
between 94th and 95th; your friend Sam is on Amsterdam Avenue
between 92nd and 93rd; your friend Kate is headed west from Central
Park; your friend Jim just walked out of the building across the
street, take a look!".

If people developing these applications are willing to go a little more
coarse-grained than what they have the _ability_ to do, privacy will be
better protected.

Second, there's the question of how long information is retained.  If
it's retained as long as possible, it's a greater temptation for
subpoenas, and a virtual certainty that these subpoenas will eventually
become routine -- for law enforcement, divorce, child custody,
employment and worker's compensation litigation, and probably other
things we haven't thought of yet.  Not to mention the traditional risks
that it will be stolen, or that some successor-in-interest, in dire
financial straits, will decide to sell it off to the highest bidder.
It takes an effort to overcome the temptation to keep things forever,
but a data-retention policy would do a lot to protect privacy here.

--
Seth David Schoen <schoen at loyalty.org> | This is a new focus for the
security
     http://www.loyalty.org/~schoen/   | community. The actual user
of the PC
     http://vitanuova.loyalty.org/     | [...] is the enemy.
                                       |          -- David Aucsmith,
IDF 1999


-------------------------------------
You are subscribed as eugen at leitl.org
To manage your subscription, go to
 http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting-people/

----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07100, 11.36820            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]