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@dodgeball.com> Date: October 12, 2005 3:37:56 PM EDT To: dave@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@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@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]