The reception to the news of Delicious’s new owners has been … varied. Marshall Kirkpatrick has written a post in favour of the transfer, but Violet Blue is not so sure. If you do a little bit of digging, you’ll see that the new Delicious has the potential to be far more restrictive on what you can, and what you can’t bookmark, especially where potentially offensive content is linked to. Offensive is a horribly vague and subjective term; one which means many different things to many different people.

At the heart of the issue is the difference in wording between the old Delicious terms …

The linked websites’ content, business practices and privacy policies are not under the control of Delicious, and Delicious is not responsible for the content of any linked website or any link contained in a linked website. (…) In accessing Delicious or following links to third-party websites you may be exposed to content that you consider offensive or inappropriate. You agree that your only recourse is to stop using Delicious.

… and the new ones …

You agree not to do any of the following: post, upload, publish, submit or transmit any Content that: (…) violates, or encourages any conduct that would violate, any applicable law or regulation or would give rise to civil liability; (iii) is fraudulent, false, misleading or deceptive; (iv) is defamatory, obscene, pornographic, vulgar or offensive (…)

If a complaint is made and if the new terms are upheld, you run the risk of having all your bookmarks removed, without recourse and without warning. Admittedly that’s a lot of ifs.

A cursory trawl through my Delicious bookmarks doesn’t seem to have anything obscene or pornographic, but there’s a lot of linked content which is fictitious and could possibly be deemed misleading or deceptive. As the saying goes, you can please some people, some of the time, not all people, all of the time. When you have terms of service which are vague and ambiguous, you can rest assured that someone will exercise their right to be offended. For now, I’ve authorised my old Delicious account to be transferred to the new service, but I’ve also taken a backup, just to be on the safe side.

What’s also unclear is whether the Delicious API and RSS feeds will remain; one of my web sites relies on these to dynamically update the site’s content.

While Delicious lives on, whether I’ll continue to be a user of the service or migrate to my own, self hosted solution, as I’ve already done with my URL shortener, remains to be seen.

I’m not the only one to question the media coverage and the conclusions the media presents. Longtime Apple commentator and author Andy Ihnatko neatly sums the entire topic up thus

A few reality checks, lest I inadvertently do a Glenn Beck number on all of you, here:

• This database isn’t storing GPS data. It’s just making a rough location fix based on nearby cell towers. The database can’t reveal where you were…only that you were in a certain vicinity. Sometimes it’s miles and miles off. This implies that the logfile’s purpose is to track the performance of the phone and the network, and not the movements of the user.
• A third party couldn’t get access to this file without physical access to your computer or your iPhone. Not unless you’ve jailbroken your iPhone and didn’t bother resetting its remote-access password…or there’s an unpatched exploit that would give Random Person On The Internet root access to your phone.
• It’s pretty much a non-issue if you’ve clicked the “Encrypt iPhone Backup” option in iTunes. Even with physical access to your desktop, a no-goodnik wouldn’t be able to access the logfile.

But still! What a nervous can of worms. This is an open, unlocked file in a known location in a standard database format that anybody can read. If someone has physical access to your Mac — or remote access to your user account — it’s a simple matter of copying a file and opening it. And while the logfile can’t tell someone that you were at a specific house, it can obviously tell your boss that you went to the Cape on the day you called in sick.

And it’s not as though Apple and these two developers are the only people who know that this file exists and that it’s so easy to access. By the time the Good Guys blow the whistle, the Bad Guys have had it for months. Lord only knows what they’ve been doing with this information.

It’s also, frankly, another reason why I value my iPhone’s “remote nuke” feature and wish it were possible to nuke all data directly from the handset. I can’t think of any circumstance under which my location data would possibly be damaging, incriminating, or even just embarrassing. That’s not the point: if I can’t control the data that my phone is collecting, I should at least have the power to destroy it utterly.

Another well known Apple commentator, John Gruber also comments that

The big question, of course, is why Apple is storing this information. I don’t have a definitive answer, but the best at least somewhat-informed theory I’ve heard is that consolidated.db acts as a cache for location data, and that historical data should be getting culled but isn’t, either due to a bug or, more likely, an oversight. I.e. someone wrote the code to cache location data but never wrote code to cull non-recent entries from the cache, so that a database that’s meant to serve as a cache of your recent location data is instead a persistent log of your location history. I’d wager this gets fixed in the next iOS update.

In my previous post I wrote that “caching is a common technique used to speed up network systems and it’s not surprising, at least to me, that iOS is using caching techniques” and it turns out that iOS is not alone and that, unsurprisingly, Google’s Android is doing pretty much the same thing, caching cell tower and wifi location information, again presumably for the purposes of speeding up the location systems on Android mobile devices. The one difference between the iOS and Android approach is that Android overwrites the cache data when the cache file fills up whereas iOS doesn’t. Rather than a dark location tracking conspiracy this looks more like a bug or an oversight on the part of iOS and as John Gruber notes, this will probably be fixed in an upcoming release of Apple’s mobile operating system. I would also hope that the visibility of this cache data on Android will also be secured too, and soon.

Taking a step back for a moment, caching of any information to reduce the need to make time costly network calls seems to be mobile’s Kobayashi Maru … you’re damned if you do and damned if you don’t. If you do cache information which is perceived, rightly or wrongly, to be sensitive then media outrage will result. If you don’t cache such information, then a mobile device will be reliant on network access every time the un-cached information is needed and that mobile device will be perceived as being “too slow“.

Probably the only way to prevent a recurrence of this sort of media event is for more transparency on how such information is being stored and used and, as John Abbott pointed out on my previous post, the provision of a setting which says “Switch this setting on for a super-quick location fix, we’ll keep your location private“.

As is so often the case, this is much less about the technical side of the issue and much more about what Ihnatko calls the “Ick Factor” … about how the public, led by the media, sees things.

A recent report highlighted concerns that the US Air Force has over troops using location based apps, with the Air Force posting a warning on an internal web site on the matter.

“All Airmen must understand the implications of using location-based services,” said a message on the internal Air Force network.
The features, such as Facebook’s ‘Check-in,’ Foursquare, Gowalla, and Loopt “allow individuals with a smartphone to easily tell their friends their location,” it said.
“Careless use of these services by Airmen can have devastating operations security and privacy implications,” said the message, which was posted on November 5, according to spokesman Major Chad Steffey.

The age old adage about Military Intelligence being an oxymoron springs to mind.

Last week an article entitled “Can you digital photos reveal where you live?” was posted on the Big Brother Watch blog; pop over there and read it for a moment, it’s only three paragraphs long …

… welcome back. My first thought on reading that article was “well yeah, duuh“. Followed up by the slightly more lengthy thought of “well yeah, duh … of course a geotagged photo can reveal where you live, if you’ve enabled geotagging, if you understand EXIF data, if you’ve uploaded the photo to the internet and if you’ve set the visibility of that photo to public … upload enough photos and sufficient patterns will emerge that should give a good indication of where you live“.

But I’d be willing to bet that most people’s thought on reading that article was much more along the lines of “s**t … I didn’t know that“. For those of us in the location industry, we should sit up and take note of this reaction.

Here on the inside of the location industry it’s relatively easy to dismiss articles such as the Big Brother Watch one. We know enough to make an informed decision on whether the location component of a service is opt in or opt out. With a bit of background research we can even find out whether a service utilises your location in stealth mode, with potentially abusive consequences, such as recent news that some free apps on the Android mobile platform are secretly sharing their location without the user’s knowledge.

With today’s ever changing technology making a level of technical sophistication available to the mass market that would have been unheard of 10 years ago, maybe it’s time for Location to engage the services of a good Public Relations agency to move the visibility and benefits of the location component of services away from the dense legalese of the EULA and away from burying the control of location deep away inside a densely nested set of configuration options.

If we don’t then the first that the majority of the general public will hear of location privacy will be when a story hits the tabloid media, such as when proof of infidelity of a celebrity due to a location based app on their phone is used in a high profile divorce proceedings. And that will be a sad day for all of the location industry.

Let’s look at the key issues that seem to be getting people hot, bothered and generally up in arms.

Deja vu the first. According to Facebook, at the time of writing they have 500M users. But how many of them will actually use the service, regardless of whether they’ve updated their privacy settings?

Deja vu the second. So you decide you want to use Facebook Places? Only on an iPhone I’m afraid or from Facebook’s HTML5 mobile web site. Want an Android or Nokia app? You’re out of luck, for now. Want to use it outside the US? You’re even more out of luck, for now.

Deja vu the third. So you decide you don’t want to use Facebook Places? It’s a location app so there’s bound to be privacy implications. Granted, Facebook have chosen to go down the opt-out route for location privacy, though you still have to physically use the service, but even the most cursory of web searches for “disable facebook places” yields loads of different takes on the same basic set of actions. Cult of Mac and ReadWriteWeb have great write ups, in non threatening, non technical language for how to ensure Facebook Places never sullies your Facebook stream.

Now take a step back, re-read the three points above and substitute, in order, Google’s Latitude, Foursquare’s, err, Foursquare and Yahoo’s Fire Eagle for Facebook Places. Granted the opt-out vs. opt-in approach to location sharing differs substantially (for Latitude, Foursquare and Fire Eagle it’s implicitly opt-in) but we’ve been here before. Many times. A new location sharing service is launched, people get worried due to media coverage and eventually the status quo is restored and everyone gets on with their lives as before, maybe with an additional bit of location richness added, maybe not. It’s worth bearing this in mind before you buy into the latest media coverage which over-uses the phrase “sparks privacy concerns“.

Update 1/9/10 – turns out I’m not the only one thinking along these lines. After I originally posted this, my daily trawl through my RSS feeds uncovered a post from Jonathan Crowe over at The Map Room blog that draws pretty much the same conclusions over Facebook Places as I do.

When it was launched in early 2009, Latitude was the receipt of some fairly harsh press from the informed tech media and from the uninformed traditional media and I argued for some latitude in the discussions on, err, Latitude.

Latitude kept on getting compared to Yahoo’s Fire Eagle and the main gripes seemed to be:

1. Latitude is a consumer application built into Google Maps, not a platform
2. Latitude doesn’t have an API
3. Latitide’s privacy model is opt-in but all or nothing

So now Latitude has an API and everyone’s happy. Right?

Wrong. The previous gripes have been done away with and replaced with three more gripes.

1. Latitude needs to run in the background and so will either drain battery life or won’t run in the background on an iPhone at all.
2. Latitude now has granular privacy controls but these are on the back-end so Google will know your location prior to federating it to location consumers via the API.
3. Latitude needs a Google account to use.

There’s a lot of inconsistency here.

1. Latitude, as part of Google Maps, already runs in the background on handsets that support that. The iPhone doesn’t, yet, but that’s an iPhone OS issue not a Latitude issue. Short battery life is a feature of almost all smartphone class handsets, Latitude or not.
2. Latitude gains granular privacy controls but they’re on the back-end so this is a bad thing. Fire Eagle has granular privacy controls and they’re on the back-end but this has never been a source of complaint.
3. Latitude needs a Google account to use. Correction. Latitude has always needed a Google account to use, so this is a bad thing. Fire Eagle has always needed a Yahoo! Id to use, and yet this is something not seen as a contentious issue.

One of the criticisms that was levelled at Fire Eagle was lack of a definitive consumer application at launch; a not unfair criticism. Latitude’s taken the inverse approach, launching with a consumer application and then opening up an API almost a year later.

Time will tell which of these two location sharing platforms will dominate or whether they will be usurped by another unseen contender.

A lot of web sites try to capitalise on this, offering earnest entreaties to “make me your home page” … “no make me your home page” … “no, choose me for your home page, I have so much personalised content”.

They’re needy and somewhat neurotic entities these web sites, it’s not like I can have all of them as my home page.

Most of them personalise their content for you, based on a registration setting or some other insight, to give you what they think is the information your looking for.

This is not creepy.

A large amount of web sites are advertising supported and serve up ads which, again, are personalised, either from a demographic, behavioural or geographic point of view (sometimes it’s just from plain old fashioned key word matching with often hilarious results).

This is still not creepy.

But then this morning Facebook told me it wants to be my home page.

Like most people I’ve evolved a filtering mechanism which understands why I’m being asked and which either ignores such pleas or uses the minimal amount of effort and mouse clicks to convey the message “buzz off, you’re not going to be my homepage and don’t bug me again“. I’m politely paraphrasing here you understand.

But when Facebook offers to be my home page because, and I’m quoting here, it’s noticed I use Facebook regularly … that smacks of Big Brother and is most definitely creepy, whichever way I look at it.

The focus of the Horizon event was to discuss the infrastructure needed to support location in its role as a key context and to identify any research theme that came out of the discussions; a classic case of the ill defined and fuzzy interface between the commercial world and that of academia.

The day was split into three thematic tracks:

• The Location Challenge
  • What are the challenges specific to the capture and management of location data?
  • What is the state-of-the-art in the technologies available to store, query and present location data?
  • How do we understand location in context, especially in real-time, on the move?
• Whose Data Is It Anyway?
  • What data should be considered “personal”?
  • Should I “own” data about me, such as where I am, my home electricity usage, my bank transactions?
  • How can users be enabled and encouraged to manage this data?
  • What technologies are available to do this?
  • How, when and by whom should “personal” data be exploited?
  • What checks and balances should be in place to protect all stakeholders, including both citizens and service innovators?
• Can Crowds Be Authoritative?
  • Crowd sourcing is a powerful technique for data collection enabled by modern handheld devices, but how far can user-contributed data be trusted?
  • What are the processes required in order to meld crowd-sourced data with existing, authoritative, datasets?
  • What are the legal implications of generating, combining and using such user-generated datasets?
  • For example, what environmental details could citizen sensors collect?
  • How might this change our understanding of the live state of the world?

The location challenge session was a basic introduction to geo and to location, just to get everyone on the same page. A small wry cheer from myself and Ed was caused by the mention of slippy maps after half an hour of pure GIS but the session was also notable for reminding us that GPS isn’t just the domain of the US NAVSTAR system, though it’s the one we’re most familiar with and which is considered pretty much synonymous with GPS (the Wikipedia entry for GPS redirects to the NAVSTAR entry). But there’s also the Russian GLONASS, the Chinese COMPASS and the European Galileo systems chafing at the heels of NAVSTAR and threatening it’s hegemony. We also touched on the accuracy of satellite navigation systems, ranging from the fictitious, with Dan Brown asserting that “(GPS) is accurate within 2 feet anywhere in the world”, even when in the toilet in the Louvre, to the technically feasible, with accuracy of 1 cm being touted as possible. Though no one in the room was able to articulate precisely what use 1 cm GPS accuracy would be.

The low point of the session was a rambling and tedious sales pitch from Oracle which can be summarised concisely as “there’s an explosion of (geographic) data coming, you need to buy our (highly priced) servers in order to cope with it”. It’s a shame no-one’s told Flickr about the need for Oracle servers as they’ve been making MySQL and commodity Linux servers cope with an explosion of data for a while now.

The high point of the session was a (rather hip looking) Doctor who’s name escaped me who’d managed to do something that eludes many commercial concerns. They’d managed to put together a prototype, intelligent car pooling and routing service, complete with web, mobile and SMS interfaces, together in just a few weeks. Oh and it worked as well; this was not only deeply impressive but illustrated the positive social and community facet of this thing we call location.

An an erstwhile privacy nerd, the session on whose data is it anyway? was fascinating, defining and categorising a whole range of what can be considered personal data:

• access data (name, address, phone number)
• direct data (photos)
• intrinsic data (fingerprint, genome)
• state data (location, activities)
• transactional data (finance, journeys, purchases)
• interaction data (things I say and do)
• indirect observation data (energy usage)
• things I create data (emails, texts, documents, photos)
• things I’m given data (emails, texts, documents, photos)
• things I’ve seen data (documents, tweets, locations)

With all of this data being out there, in a variety of data sinks, both personal, governmental and commercial, the concept of a distributed, durable, scalable and trusted personal data store was floated as a theoretical solution; much emphasis should be placed on the word theoretical by the way. A worthy theoretical concept, the notion of if you need to know about me, ask my PDS, is alas one that the majority of the audience who hail from a commercial background, view as interesting but flawed and not viable in the real world.

The high point of the session was a recommendation to read Paul Ohm’s Broken Promises of Privacy; the low point the need to Lynne Truss to visit the room unannounced to pounce on the person who thought that “Who’s Data is it Anyway?” was acceptable for a title slide.

The final can clouds be authoritative session started aptly withe a quote from Wikipedia and paired Muki Haklay from University College London against Glen Hart from the Ordnance Survey. Whilst the pairing may have been unintentional, following a strong proponent of the crowd sourced OpenStreetMap with a pointed, if tongue in cheek, talk from the OS made comparisons difficult to avoid. Stephen Feldman’s write up of the day has more insight on this final session and is well worth a read.

Acronym of the day goes to BHP, which left the audience looking perplexed until it was revealed as a Bloody Hard Problem. Days like this are essential to draw academia away from a pure research perspective and to get representatives of commercial organisations and academia talking on common ground … that in itself is a BHP which Horizon goes a long way towards solving.

Posted via email from Gary’s Posterous

We all suffer from SPAM, the unwanted and unsolicited commercial bulk emails that are the reason we have Junk Mail filters and folders in our email clients and servers. A quick glance at the Junk folder for my personal email account shows over 300 of these since the beginning of February alone.

Posted via email from Gary’s Posterous