I know I know. very boring blog title.
I toyed with the idea of calling it
“to cloud or not to cloud”
but then I figured people would have no idea what the hell it was about etc etc…so there you have it.
This blog post started (as a couple of recent ones have) as an email discussion with Gary Gale (formerly Yahoo, now Nokia).
Do you remember Jaiku? the particular aspect of jaiku I have in mind is the networked “presence”…i.e.
Remember when nokia phones all had
Loud, Quiet, Normal, Meeting, Silent, Vibrate (or something like that) profiles
The coolest thing about Jaiku for me was being able to see what mode someone was in…(before actually calling them)
Now it might sound tempting to translate this to location but for reasons a number of people have spoken about it’s not quite the same. In other words think about this – I may want my phone to be in Silent mode for work calls and Loud mode for personal ones (or vice versa) in the same way as I have umpteen context + person specific preference on my location sharing…
So for sharing personal data – (be it location, status i.e. phone profile, birthday, biography etc etc) sure there can be lots of models.
What we should not lose sight of is that some of this data changes very rarely if at all (e.g. my birthday) whereas other data changes on an ongoing basis – and my preferences for sharing said data may well change on an ongoing basis.
For example I frequently answer phone calls from my parents but not always.
If you tried to make me a set of cloud based preferences for whether the network should let a phone call from my parents go straight to voicemail or not – I would hate that – because I would have to change them so often I would never use them.
This is why some of Danah Boyd’s stuff is interesting – because she’s approaching privacy/sharing from an ethnographic/behavioural point of view.
Let’s look at this another way.
1. If your handset has some kind of LocateHandset() geoAPI exposed to developers then the spray and pray model of sharing location is there by definition.
Send a Tweet (add location to it via the LocateHandset())
Do a Facebook update (add location to it via the LocateHandset() call)
Take a photo with camera and share it via email app (add location…etc etc etc)
You don’t need a separate location managing backend to handle this – the privacy is handled by choice by a sort of caveat transportor model (and yes I had to look that up – and yes it means sender in Latin ;))
When you sorely need location managing back end systems is when other objects (C2C or B2C) can query your location. (be they cab companies, bank/credit card entities, friends etc etc)
So that’s when it gets tricky.
And that’s when the one-to-one stuff becomes necessary.
Danah talks about the fact that privacy is not context specific (time/place) or person specific but it’s both.
So although you can do this in a cloud (just slap a bunch of settings on there and hope for the best – if you wish the FireEagle and Google) we think it’s more sensible (and quicker to manage) done on the device itself.
yes it’s a good old echo flash – easy to understand and super easy to control.
Or as I kept commenting much to the consternation and awe of anyone listening – it’s privacy without any settings or preferences required.
Rolling out over the next week we have a tweak on this functionality – which allows you to easily configure a friend for automatic response. Needless to say we did not add this functionality lightly 😉 – look for a blog post in the next few days as we roll this out on all our platforms.
So wait – if one-to-one location sharing preferences are on the device and automatic location sharing preferences are on the device – what does that leave for the cloud?
In theory – the obvious answer is a continuously updating live location stream so that you save yourself the data pathway roundtrip to my handset.
(this also has the side effect of giving you my last known location in the event of my phone being out of service or out of network (or simply – OFF ;))
But then you have a pandora’s box of preferences…who’s allowed to access this always on location, when they are allowed to do it – and to what granularity. (in other words it’s FireEagle all over again, with the worst aspects of Facebook’s privacy rolled into it and multiplied by 100)
The echoecho model can certainly extend in that direction and both models can of course co-exist. But they are both important for different reasons.
If you accept that networks/handsets are tending towards an always on – always connected model…then effectively the cloud extends to my handset…
so the argument (with regards to where the preferences are) ends up being somewhat semantical.
That’s why I frame the location sharing discussions as push vs. pull…because I feel that the privacy considerations (not to mention the UI simplicity) are overwhelmingly in favor of the echoecho approach.