Posts Tagged ‘location’

The Problem With Location Based Mobile Services

There’s a problem with today’s crop of location based mobile services, commonly referred to as LBMS; those little apps which sit on our smartphones and allow us to geotag status updates or photos, find relevant local place information or check-in at a place.

The problem isn’t one of privacy or tracking. Nor is the problem one of an LBMS dying and going away. The problem isn’t whether I can get a good location fix or whether the results I get are accurate or not. The problem isn’t even of the value of the data we, the customer, put into a service and whether we can get it back again.

No, the problem is whether we can actually use the service from our smartphone at all.

It’s 2013 and I live in the suburbs of the capital of the United Kingdom and this happens all the time. Not in the uncharted wilds of the UK. Not in obscure regions of the world. But in my local neighbourhood and in the heart of London. And it’s not just a problem with Vodafone, my current cellular provider. Over the last few years I’ve been on T-Mobile, on Orange and on O2 and all the cellular carriers seem to have exactly the same problem; one which makes a mockery of their coverage maps. According to Vodafone’s map, I should be getting high or at least variable 3G data coverage where I live, but instead I get variable or no coverage at all when walking in my local neighbourhoods.

3G data coverage that drops in and out; that’s the problem with today’s location based mobile services.

I’m getting off of my soapbox now …

Written and posted from home (51.427051, -0.333344)

Of Digital “Stuff” And Making Your Personal Interweb History

Back in July, I wrote about Big (Location) Data vs. My (Location) Data, which was the theme for a talk I gave at the AGI Northern Conference. The TL;DR premise behind the talk was that the location trail we generate on today’s interweb is part of our own digital history and that there’s a very one sided relationship between the people who generate this digital stuff and the organisations that aim to make money out of our digital stuff.

Once I’d given that talk, done the usual blog write up and posted it, I considered the topic done and dusted and I moved onto the next theme. But as it turns out, the topic was neither done, nor dusted.

Firstly Eric van Rees from Geoinformatics magazine mailed me to say he’d liked the write up and would I consider crunching down 60 odd slides and 3000 odd words into a 750 word maximum column for the next issue of the magazine.

And then a conversation on Twitter ensued where some people immediately saw the inherent value in their personal location history whilst some people … didn’t.

That conversation was enough to make me go back and revisit the theme and the talk morphed and expanded considerably. Fast forward to this week and I’ve given the talk in its’ new form twice, once at Nottingham University’s GeoSpatial faculty and once at the Edinburgh Earth Observatory EOO-AGI(S) seminar series at Edinburgh University.

Maybe now this topic and this talk is finished and it’s time to move on. But somehow, I think this will be a recurring theme in talks to come over the next few years.

The slides from the talk are below and the notes accompanying those slides are after the break.

View this document on Scribd

Read On…

Work+ – A Fantastic Idea For A Location Based App; Shame About The Metadata Though

I once wrote two posts saying that people are mistaking the context (location) for the end game and that location is (also) a key context, but most people don’t know this. Two years or so after I wrote those posts, the concept of location based mobile services and location based apps shows no sign of dying off. I see lots of new location based apps and whilst they’re almost always nice and glossy, not that many of them really grab you as a neat and innovative idea. But every so often, one does come along which makes you slap your forehead, like the scientists in the 80′s ads for Tefal, and mutter under your breath … that’s so obvious, why didn’t I think of that?

These days I tend to work as much out of the office than I do in the office. My needs for this are relatively few; somewhere to plug my laptop in, free wifi and a half-way decent cup of espresso now and again. Using local location based search services I can find places near me that meet these needs but it’s a disjointed experience, using multiple apps to find free wifi, good espresso and so on. Maybe the recently launched Work+ can help me out here?

First impressions are good. I launch the app and connect it to my Foursquare account (the check-in feature within Work+ is a nice touch). Work+ also passes the first hurdle than many location based apps fail at; it actually works outside of the United States.

I install the app, tap on Work and then Go to launch the easy to use search interface. I need wifi … tap. I need a table to put my laptop on … tap. I need coffee … tap.

Ideally I’d also like to see a search setting that says “by coffee I mean decent espresso and no, I don’t mean Starbucks” but maybe I’m being overly picky here.

So I tap on Search and I get a list of places that are close by to me that meet my needs or I can view those places on (Apple’s new) map. This is great. What is there not to like?

But wait, do all of these places actually meet my needs? The search results seem good, there’s no duplicates or places that either don’t exist or have since closed; problems which can plague location based services and which are by no means simple to solve. The results are also pretty close to where I am. But …

The two hits for Costa Coffee are pretty good; as the name implies they both sell (reasonably passable) coffee and have (free-ish but time limited) wifi. Score, 2/7.
The same goes for Caffe Nero, another one of the big UK coffee chains. Score, 3/7.
Caffe Toscana is my local neighbourhood cafe. Great food and coffee … but no wifi, at least not when I visited last week. Score, 3/7
Astrora Coffee isn’t a cafe. They sell coffee in the raw, roasted beans and ground beans. No wifi and not really somewhere you can work; I’d imagine the staff getting somewhat bemused if someone turned up and tried to work there. Score, still 3/7.
Diner’s Delight is as the name suggests, a local diner. No wifi here either. Score, 3/7 again.
Finally, The Nearest Cafe is a cafe and they do sell pretty good coffee. But again, no wifi here.

The final score ends up as 3 hits that really meet my needs, out of a possible 7.

It would be easy to take what I’ve just written as an indictment of Work+ but nothing could be further from the truth. Local search is not an easy thing to do. Tightly focused local search across a wide range of attributes that you can assign to a place (wifi, coffee and so on) is insanely difficult to do. It’s true that Work+ doesn’t score as highly as I’d have hoped in what is admittedly a very subjective search on a very limited local area. But Work+ shows the direction that local search is headed in. It’s no longer enough to ask find me what’s around me, we need to be able to ask find me what’s around me that fits what I need to know now and more importantly get good answers to that question.

What makes the Work+ experience not quite as good as it could be isn’t down to the app, which makes local search a pain free and simple process. What lets Work+ down is the lack of a complete local data set which contains not just the accepted standard place attributes of name, address, location and category but also which adds in more detailed, almost ambient or fuzzy, attributes, such as wifi, capacity (can I fit a large group of people in here?), beverage types (coffee or tea?), noise level and ambience.

Make no mistake, Work+ is a precursor to the local search and location based experiences we can expect to see in the very near future; whether the back-end data with all of the rich attributes that people want to search on will keep up with demand remains to be seen.

Written and posted from home (51.427051, -0.333344)

Where You Are Isn’t That Interesting But Where You Will Be Is

Every once in a while the thorny topic of location privacy rears its ugly head, often in tandem with a new location based service or the discovery of what an existing one is really doing. There’s often cries of “Big Brother” and “company X is tracking me” as well. But lost in the rhetoric and hyperbole around this subject is a well hidden fact … your current location isn’t actually that interesting to anyone apart from yourself.

For most of the day we tend to be on the move so even if a service does know your location that fact becomes irrelevant almost immediately. Intrusive location based advertising is normally held up for inspection here but without context a location is just a set of longitude and latitude coordinates, coordinates that are out of date and no longer relevant almost as soon as they’ve been detected.

Maybe a location based service I use does want to target me with location based ads, but for example, if I’m on my irregular commute from the suburbs to the centre of London on a train, I challenge anyone to find an ad, intrusive or not, that would be contextually relevant to me in sufficient detail that would warrant an advertiser paying out the not insignificant sums that such ad campaigns cost. Unless maybe, just maybe, it’s an ad that offers me a viable alternative to SouthWestTrain’s execrable and expensive train service, but that’s just in the realms of fantasy.

Now it’s true that if you gather enough data points you can start to infer some meaning from the resultant data set. You can probably determine the rough area where someone works and where they live based on their location at certain times of the day. But in today’s connected world of the interwebs, with their social networks and uploaded photographs, that level of locational granularity can be inferred fairly easily without the need to explicitly track the location of an individual.

All of the above can be summed up as something like …

Where you are right now isn’t that interesting. Where you were is slightly more interesting. Where you will be is very interesting.

I’m sure I’ve said words to this effect before in a talk at a conference but try as I might I can’t find a reference to back up this assertion.

What’s even more interesting is that a recent research study at the UK’s University of Birmingham took 200 volunteers who agreed to have their phones track them, added in the locations of their friends in their social graphs and produced an algorithm that was able to predict where a participant would be in 24 hours time, sometimes with accuracies of less than 20 meters and with an average accuracy of around 1000 meters. The full research paper makes for fascinating reading and shows that the real key to location technologies may not be where you currently are but may be much more about our predicability and daily routines for ourselves and our friends.

Now that’s interesting.

Photo Credits: misspixels on Flickr.

Written and posted from home (51.427051, -0.333344)

Big (Location) Data vs. My (Location) Data

For a pleasant change, the guts of this talk didn’t metamorphose oddly during the writing. Instead, it geolocated. This was originally planned to be my keynote talk at Social-Loco in San Francisco last month. But I wasn’t able to make it to the Bay Area as planned for reasons too complex to go into here. Suffice to say, the slide deck languished unloved on my laptops hard drive, taking up 30 odd MB of storage and not really going anywhere.

Then I got an email from Stuart Mitchell at Geodigital asking me if I’d like to talk at the AGI’s Northern Conference and thus, after a brief bit of editing to remove the conspicuous Silicon Valley references, this talk relocated from San Francisco to Manchester. As per usual, the slide deck plus notes are below.

View this document on Scribd

Read On…

From Where 2.0 To Just Where; With Meh 2.0 Somewhere In The Middle

And so, as Where 2012 draws to a close and the lobby of the Marriott Marquis in San Francisco fills with a slew of geo’d-out delegates waiting to check out, it’s time for the traditional post conference retrospective writeup. If you were at Where this year or in previous years you’ll probably want to skip ahead to the next paragraph, right now. Where, previously called Where 2.0, is one of the annual maps, geo, location conferences. Though it’s very Californian and eye wateringly expensive, it’s still the place to go to talk, listen and announce anything related to the nebulous industry we call Geo.

After skipping Where 2.0 last year, this year I returned as part of the Nokia contingent and found out that some things had changed.

Firstly, Where 2.0 was no more. O’Reilly have rebranded the conference as simply Where, with the strapline of the business of location. The conference had also moved from its traditional San Jose venue, via the soul desert that is the Santa Clara Convention centre last year, to a new home at the Marriott Marquis slap bang in the middle of downtown San Francisco.

Secondly, and probably more importantly, whilst Where was as slick and well put together as it’s always been, something was missing. It’s not easy to put my finger on what precisely was lacking. There seemed to be a lack of … buzz, for want of a better word. It felt … muted. Numbers were certainly down from previous years but that alone can’t account for the feeling, or lack of it, this year. Granted, the venue was excellent, the food was as well too. The coffee was … Starbucks. We can’t have it all. The wifi almost held up. I met up with a lot of old friends and colleagues, including some from Yahoo! and the after show parties were edgy and the bar was open, free and copiously stocked.

But it did feel more Meh 2.0 (to be said out loud with an indifferent shrug of the shoulders) rather than Where 2.0, and from speaking to other people, I’m not alone in thinking this.

So enough introspection, to the point of this post, which is retrospection. Let’s start with the high points.

Read On…

Check In, Get Acquired, Check Out. Farewell Gowalla

With the benefit of hindsight, it was probably inevitable but 5 years after the location based, check in social network we know as Gowalla launched and 3 months after they were acquired by Facebook, Gowalla is no more.

Despite launching in 2007, 2 years prior to Foursquare, Gowalla never seemed to be able to capture attention from either users or from the media in quite the same way as Foursquare. The similarities were many; both social networks used location as a key facet, allowed users to check in to locations they were at or near and to share those locations with other users and other social networks. But while Foursquare’s game mechanics of badges and Mayors seemed to hit the right note with users, Gowalla’s ill explained and ever morphing system of virtual items, spots and trips never seemed to make sense. No-one I’ve ever spoken to could explain exactly what the point of Gowalla was, whilst Foursquare’s mechanics were simplistic and easy to grasp.

After loosing ground to Foursquare, Gowalla tried to act less as a sole source of checkins and more as a central aggregator of the disparate checkins from itself, Foursquare, Facebook and Twitter, amongst others, but this move did little to slow Foursquare’s ascendancy.

And now, 3 months after they were acquired by Facebook in December 2011, both the Gowalla smartphone app and website started to announce

Thank you for going out with Gowalla. It was a pleasure to journey with you around the world. Download your check-ins, photos and lists here soon.

So long Gowalla. You were one of the first movers in the so called check-in economy. It was fun while it lasted. Only time will tell whether Foursquare’s seemingly unbeatable lead will continue.

Wikipedia’s Gowalla entry has the final word on the subject.

Gowalla was a location-based social network

The past tense says it all.

Written and posted from home (51.427051, -0.333344)

GeoCommunity and LocNav; One Talk, Two Audiences

You can argue that it’s cheating or you can argue that there’s a vague degree of ecological-friendliness but sometimes you just end up recycling and repurposing a conference talk deck for more than one conference. So it was with my keynote at GeoCommunity in Nottingham last month and my keynote at the Location Business Summit in San Jose. One deck, two audiences. As it turns out, taking this approach can yield unexpected benefits.

Firstly there’s the UK audience at GeoCommunity, the Association For Geographic Information’s annual get-together and all round geo shindig. GeoCommunity is probably the closest the UK has to California’s Where 2.0, but with a very different audience and a very different accent. The AGI still draws the bulk of its membership from the GIS heartlands of the GI community, although in recent years the association has dramatically expanded its reach into the web, mobile and neogeography domains.

The Location Business Summit, on the other hand is firstly in San Jose in the heart of Silicon Valley and secondly has a very pronounced American accent and draws the bulk of the audience from the Bay Area where web and mobile, both from a developer and from a business perspective, hold sway.

One deck, two audiences.

The slide deck is above, plus there’s a PDF version with the talk notes.

As previously mentioned, the GeoCommunity audience hails, in the main, from the GIS heartland. A talk which deals with context, with search, with relevance, with LBS and with maps and mobile got a great reaction and fitted well with the other closing keynote from the British Library’s Kimberley Kowal who put together a gorgeous deck full of beautiful maps, ancient, old and not so old. Steven Feldman has put together a list of these cartographical wonders, if you’re interested. Following up old maps with new, digital maps seemed to be a good segue and bridge between printed maps and digital maps. After the talk, people came up to me and said nice words and overall, the reaction seemed to be that this was an area of geo and location that didn’t normally appear on their professional radar. That’s a sweeping generalisation of course but it was also immensely gratifying.

Fast forward to today; not in the UK but slap bang in the middle of San Jose. Same talk. Same deck. Same sentiments. But a vastly different, though equally good, reaction from the audience. This time the questions and comments focused not on the map, not on LBS but on what the next major step in sensors would be after GPS and on what sources of data LB(M)S needs and lacks.

One deck, two audiences. Even in the same industry, albeit the vague and nebulously fuzzy grouping that we call the location industry, two very different audiences can give two very different reactions. One day, reaction will probably be the same, but today, geo and location really is a very broad church indeed.

Written and posted from Location and Navigation 2011, Convention Plaza Hotel, San Jose (37.3301, -121.8916)

iOS Location Caching Round-up – Conspiracy Theories: 0, Smart Location Caching: 1

More a meta post, or what Kuro5hin would have called MLP (meaningless link propagation), this post started out as a comment to one of my previous posts on the iOS location caching controversy but soon expanded way beyond a comment into a full blown post.

Firstly, let’s get the conspiracy theory out of the way; this theory has been presented in a variety of ways but all of them seem to think that your iOS device is tracking your location and that the reason for this is some shadowy request from government or intelligence agencies. Perhaps the most eloquent case for this was on Frank Reiger’s blog.

Now I love a good conspiracy theory as much as the next person and Frank’s blog post was a great read. But I have to take issue with the two main points he raises. Firstly there’s “if it was a bug then it would have been fixed … it hasn’t been fixed so it can’t be a bug and must therefore be deliberate“. Secondly there’s “not only has the bug not been fixed but the file even moved location without being fixed so it must be (even more) deliberate“.

I’ve worked in the software industry for almost 25 years, many of those cutting code, and can say with hand on heart that bugs, oddities and plain wrong behaviour stay in code bases not because they don’t need to be fixed but because other factors push them down in the priority list, factors such as hard release dates, new features taking precedence and the ill defined side effects of complex software systems not being able to be fully QA’d. Just because a bug or an unforeseen side effect remains in a production code base does not make a conspiracy theory of government or intelligence agency intervention.

We also live in a world of distributed software development teams. It’s enough of a challenge to keep teams in different floors of the same building in synch; it’s even more difficult when language, time zones and different countries get into the mix. Just because the consolidated.db cache moved location again, does not make a conspiracy theory.

So all in all, nice post, great conspiracy theory but, sadly, very little to back up the assertions.

But if your iOS device is tracking or caching your location, why is the data so inaccurate in places, showing places you’re pretty sure you haven’t been or have visited only fleetingly, yet not showing places you’d think would show up, such as where you live or work?

For the answer to these questions, I’d recommend a thorough reading of Peter Batty’s excellent three posts on the topic, which actually digs into the data that is present on iOS devices, rather than making shrill conspiracy theories based on other, equally shrill, media headlines.

Peter’s posts, “So actually, Apple isn’t recording your (accurate) iPhone location“, “More on Apple recording your iPhone location history” and “The scoop: Apple’s iPhone is NOT storing your accurate location and NOT storing history” go into great detail about what the consolidated.db location data cache does contain and, more importantly, what it doesn’t.

An anonymous comment on one of Peter’s posts points to a document submitted by Apple to US Congress in July 2010, which includes the following

When a customer requests current location information … Apple will retrieve known locations for nearby cell towers and Wi-Fi access points from its proprietary database and transmit the data back to the device … The device uses the information, along with GPS coordinates (if available), to determine its actual location. Information about the device’s location is not transmitted to Apple, Skyhook or Google. Nor is it transmitted to any third-party application provider, unless the customer expressly consents

Another comment from Jude on one of Peter’s posts makes this observation …

My Guess?

It’s not a list of cell phone locations that you’ve been to, but the opposite, a list of cell phone locations near you downloaded to the iPhone from Apple in case you move into range of one of them. i.e. At a guess what is happening is location services identifies a cell tower and asks for its location, and is replied to with the list of locations that contains that cell tower, that list is then cached so that it does not need to be requested again.

Of course, this is only a guess based on the wide range of addresses people are seeing and how its near to, but not exactly where, the people have traveled.

So rather than iOS actively and accurately tracking you and reporting this information to some, unspecified, intelligence agency it’s actually the complete opposite; your device is actively downloading the next cell tower and, in some cases, wifi information that is near you and where you might be going to provide a better location experience. Which explains the inaccuracy of the locations people have been seeing in their version of the cache data and explains why there’s some places they haven’t been showing up in the data and why places they have been aren’t showing up.

Of course, this information still has personal value and should really be secured by iOS and not by an individual having to secure their handset and encrypt their backups but if anyone still thinks they see the black helicopters circling, it looks more and more unlikely and, as Ed Parsons pointed out, a smartphone without location just isn’t … smart.

Photo Credits: Álvaro Ibáñez and Tom Jervis on Flickr.

Written at home (51.427051, -0.333344) and posted from the Nokia gate5 office in Schönhauser Allee, Berlin (52.5308072, 13.4108176)

Location’s “Ick Factor”; First iOS And Now Android

Two days ago I wrote about the “discovery” of a cache file on iOS devices that stores the position of cell towers and the associated media coverage surrounding this. Note that I use “discovery” in inverted commas here. As Sally Applin pointed out in a comment on my previous post, this “discovery” is not new and a paper on this by Alex Levinson, Bill Stackpole and Daryl Johnson was published in January 2011 as part of the Hawaii International Conference on System Sciences. Maybe sometimes researchers don’t read other, existing, research on a subject before publishing.

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.

Photo Credits: Stefan Andrej Shambora and Trevin Chow on Flickr.

Written and posted from home (51.427051, -0.333344)

Older Entries