If you hang around technology blogs and news sites, you may have seen the recent dust
up after it was discovered that many
iOS apps upload user address books to their servers to perform friend finding
operations. There has been some outrage about this because this has happened silently
in the majority of cases. The reasons for doing this typically are not nefarious.
Users sign up to the service and provide their email address as a username or contact
field. This is used to uniquely identify the user. Then when one of the user’s friends
joins the service, the app asks the friend for their contact list then finds all of
the existing users they whose email addresses are in the new users list of contacts.
Such people
you may know features are the bread and butter of growing the size of a social
graph and connectedness in social applications.

There are a number of valid problems with this practice and the outrage has focused
on one of them; apps were doing this without explicitly telling users what they were
doing and then permanently storing these contact lists. However there are other problems
as well that get into tricky territory around data ownership and data portability.
The trickiest being whether it is OK for me to share your email address and other
contact details with another entity without your permission given it identifies you.
If you are a private individual with an unlisted phone number and private email address
only given to a handful of people, it seems tough to concede that it is OK for me
to share this information with any random app that asks me especially if you have
this information as private for a reason (e.g. celebrity, high ranking government
official, victim of a crime, etc).

As part of my day job leading the program management team behind the
Live Connect developer program which among other things provides access to the
Hotmail and Messenger contact lists, these sorts of tricky issues where one has to
balance data portability and user privacy are top of mind. I was rather pleased this
morning to read a blog post titled Hashing
for privacy in social apps by Matt Gemmell which advocates the approach we took
with Live Connect. Matt writes



Herein lies the (false) dilemma: you’re getting a handy social feature (automatic
connection with your friends), but you’re losing your privacy (by allowing your friends’
email addresses to be uploaded to Path’s servers). As a matter of fact, your friends
are also losing their privacy too.

What an awful choice to have to make! If only there was a third option!

For fun, let’s have a think about what that third option would be.

Mathematics, not magic

Hypothetically, what we want is something that sounds impossible:

Some way (let’s call it a Magic Spell) to change some personal info (like
an email address) into something else, so it no longer looks like an email address
and can’t be used as one. Let’s call this new thing Gibberish.

It must be impossible (or at least very time-consuming) to change the Gibberish
back into the original email address (i.e. to undo the Magic Spell).

We still need a way to compare two pieces of Gibberish to see if they’re
the same.

Clearly, that’s an impossible set of demands.

Except that it’s not impossible at all.

We’ve just described hashing, which is a perfectly real and readily-available
thing. Unlike almost all forms of magic, it does actually exist - and like
all actually-existing forms of magic, it’s based entirely on mathematics. Science
to the rescue!



This is the practice we’ve advocated with Live Connect as well. Instead of returning
email addresses of a user’s contacts from our APIs, we provide email
hashes instead. That way applications don’t need to store or match against actual
email addresses of our users but can still get all the value of providing a user with
the a way to find their Hotmail or Messenger contacts who also use that service.

We also provide code samples
that show how to work with these hashes and I remember being in discussions with
folks on the team as to whether developers would ever want to do this since storing
and comparing email addresses is less code than working with hashes. Our conclusion
was that it would be just a matter of time before this would be an industry best practice
and it was best if we were ahead of the curve. It will be interesting to see if our
industry learns from this experience or whether it will take external pressure.

Now
Playing: Notorious
B.I.G. - Want
That Old Thing Back (featuring Ja Rule and Ralph Tresvant)

Towards the end of last year, I realized I was about to bump up against the ”use
it or lose it” vacation policy at work which basically means I either had to take
about two weeks of paid vacation or forfeit the vacation. Since I hadn’t planned the
time off I immediately became worried about what to do with all that idle time especially
since if left to my own devices I’d play 80 straight hours of Modern
Warfare 3 without pause.

To make sure the time was productively used I decided to write a mobile app as a learning
exercise about the world of mobile development since I’ve read so much about it and
part of my day job is building
APIs for developers of mobile apps. I ended up enjoying the experience so much
I added an extra week of vacation and wrote two apps for Windows Phone. I’d originally
planned to write one app for Windows Phone then port it to iOS or Android but gave
up on that due to time constraints after some investigation of both.

I learned a bunch about mobile development from this exercise and a few friends have
asked me to share of my thoughts on mobile development in general and building for
Windows Phone using Microsoft platforms in particular. If you are already a mobile
developer then some of this is old hat to you but I did find a bunch of what I learned
to be counterintuitive and fairly eye opening so you might too.

Thoughts on Building Mobile Apps on Any Platform

This section is filled with items I believe are generally applicable if building iOS,
Android or Windows Phone apps. These are mostly things I discovered as part of my
original plan to write one app for all three platforms.

A consistent hardware ecosystem is a force multiplier

After realizing the only options for doing iPhone development on Windows was the Dragon
Fire SDK which only supports games, I focused on learning as much as I could about Android
development options. The Xamarin guys have MonoTouch which sounded very appealing
to me as a way to leverage C# skills across Android and Windows Phone until I saw
the $400 price tag. :)

One of the things I noticed upon downloading the Android SDK as compared to installing
the Windows Phone SDK is that the Android one came with a bunch of emulators and SDKs
for various specific devices. As I started development on my apps, there were many
times I was thankful for the consistent
set of hardware specifications for Windows Phone. Knowing that the resolution
was always going to be WVGA and so if something looked good in the emulator then it
would look good on my device and those of my beta testers not only gave piece of mind
but made UX development a breeze.

Comparing this to an ecosystem like Android where the diversity of hardware devices
with varying screen resolutions have
made developers effectively throw up their hands as in this article quoted by
Jeffrey Zeldman

If … you have built your mobile site using fixed widths (believing
that you’ve designed to suit the most ‘popular’ screen size), or are planning to serve
specific sites to specific devices based on detection of screen size, Android’s settings
should serve to reconfirm how counterproductive a practice this can be. Designing
to fixed screen sizes is in fact never a good idea…there is just too much variation,
even amongst ‘popular’ devices. Alternatively, attempting to track, calculate, and
adjust layout dimensions dynamically to suit user-configured settings or serendipitous
conditions is just asking for trouble.

Basically, you’re just screwed if you think you can build a UI that will work on all
Android devices. This is clearly not the case if you target Windows Phone or iOS development.
This information combined with my experiences building for Windows Phone convinced
me that it is more likely I’ll buy a Mac and start iOS development than it is that
I’d ever do Android development.

No-name Web Hosting vs. name brands like Amazon Web Services and Windows Azure

One of my apps had a web service requirement and I initially spent some time investigating
both Windows Azure and Amazon Web Services. Since this was a vacation side project
I didn’t want expenses to get out of hand so I was fairly price sensitive. Once I
discovered AWS charged less for Linux servers I spent a day or two getting my Linux
chops up to speed given I hadn’t used it much since my the early 2000s. This is where
I found out about yum and
discovered the interesting paradox that discovering and installing software on modern
Linux distros is simultaneously much easier and much harder than doing so on Windows
7. Anyway, that’s a discussion for another day.

I soon realized I had been penny wise and pound foolish when focusing on the cost
of Linux hosting when it turns out what breaks the bank is database hosting. Amazon
charges about $0.11 an hour ($80 a month)
for RDS hosting at the low end. Windows Azure seemed to charge around the same
ballpark when I looked two months ago but it seems they’ve revamped
their pricing site since I did my investigation.

Once I realized database hosting would be the big deciding factor in cost. It made
it easier for me to stick with the familiar and go with instead of as a

LAMP

server stack. If I had stuck with

LAMP

, I could have gone with a provider like Blue Host to
get the entire web platform + database stack for less than $10 with perks like free
credits for Google ads thrown in. With the

WISC

stack, hosters like Discount ASP and Webhost
4 Life charge in the ballpark of $15 which is about $10 if you swap out SQL Server
for MySQL.

These prices were more my speed. I was quite surprised that even though all the blogs
talk about AWS and Azure, it made the most sense for my bootstrapped apps to start
with a vanilla web host and pay up to ten times less for service than using one of
the name brand cloud computing services. Paying almost ~$100 a month for services
with elastic scaling properties may make sense if my apps stick around and become
super successful but not at the start.

Another nice side effect of going with a web hosting provider is the reduced complexity
from going with a cloud services provider. Anyone who's gone through the AWS
getting started guides after coming from vanilla web hosting knows what I mean.

Facebook advertising beats search ads for multiple app categories

As mentioned above, one of the perks of some of the vanilla hosting providers is that
they throw in free credits for ads on Google AdSense/Adwords and Facebook ads as part
of the bundle. I got to experiment with buying ads on both platforms and I came away
very impressed with what Facebook has built as an advertising platform.

I remember reading a few years ago that MySpace
had taught us social networks are bad for advertisers. Things are very different
in today’s world. With search ads, I can choose to show ads alongside results when
people search for a term that is relevant to my app. With Facebook ads, I get to narrowly
target demographics based on detailed profile attributes such as Georgia Tech alumni
living in New York who have expressed an interest in DC or Marvel comics. The latter
seems absurd at first until you think about an app like Instagram.

No one is searching for "best photo sharing app for the iphone" on Google and even
if you are one of the few people who has, there aren’t a lot of you. On the other
hand, at launch the creators of Instagram could go to Facebook and say we'd like to
show ads to people who have liked or use an and who also have shown an affiliation
for photo sharing apps or sites like Flickr, Camera+, etc then craft specific pitches
for those demographics. I don’t know about you but I know which sounds like it would
be more effective and relevant.

This also reminded me that I'd actually clicked on more ads on Facebook than I've
ever clicked on search ads.

Lot's of unfilled niches still exist

I remember being in college back in the day, flipping through my copy of Yahoo!
Internet Life and thinking that we were oversaturated with websites and all the
good ideas were already taken. This was before YouTube, Flickr, SkyDrive, Facebook
or Twitter. Silly me.

The same can be said about mobile apps today. I hear a lot about there being 500,000
apps in the Apple app store and the
same number being in Android Market. To some this may seem overwhelming but there
are clearly still niches that are massively underserved on those platforms and especially
on Windows Phone which just
hit 50,000 apps.

There are a lot of big and small problems in people's lives that can be addressed
by bringing the power of the web to the devices in their pockets in a tailored way.
The one thing I was most surprised by is how many apps haven't been written that you'd
expect to exist just from extrapolating what we have on the Web and the offline world
today. I don't just mean geeky things like a
non-propeller head way to share bookmarks from my desktop to my phone and vice versa
without emailing myself but instead applications that would enrich the lives of
millions of regular people out there that they'd be gladly willing to pay $1 for (less
than the price of most brands of bubble gum these days).

If you are a developer, don't be intimidated by the size of the market nor be attracted
to the stories of the folks who've won the lottery by gambling on being in the right
place at the right time with the right gimmick (fart
apps, sex position guides and yet
another photo sharing app). There are a lot of problems that can be solved or
pleasant ways to pass the time on a mobile device that haven’t yet been built. Look
around at your own life and talk to your non-technical friends about their days. There
is lots of inspiration out there if you just look for it.

Look for Platforms that Favor User Experience over Developer Experience

One of the topics I’ve wanted to write about in this blog is how my ge[…]

David Recordon of Facebook has an interesting post titled Why
f8 was good for the open web where he talks about how some of Facebook’s announcements
at their recent F8 conference increase the openness of the Web. He calls out the following
four items as the key benefits to the web as a whole from the F8 announcements

No 24-hour caching limit

An API that is realtime and isn’t just about content

The Open Graph protocol

OAuth 2.0

Of these, the third seems to me to be the most beneficial to the Web as a whole. The
first, second and fourth items are really about benefits to Facebook developers. Although
I guess you could argue that such a significant service adopting OAuth 2.0 is great
for increasing adoption across the Web. However this pales in comparison to the fundamental
shifts in thinking introduced by the Open Graph Protocol.

Evolving the Social Graph

The first question is what problem does the Open Graph Protocol solve for Facebook
and why are they releasing it?

Figure 1: The Facebook Social Graph in 2006

The original Facebook social graph had a one type of node and edge. The nodes were
users and the edges were friend relationships. The operations you could perform on
the nodes are also straightforward. How many friends does Jane have? Is Kim a friend
of Mary? And so on. As more features were added to the site, new nodes and edges were
added to the social graph

Figure 2: The Facebook Social Graph in 2009

Each of these nodes supports similar operations. By counting the number of incoming
connections you can tell how many fan's Justin Bieber has, how many people want to
show the world their love for the Ramblin’
Wreck or how many people have added Mary as a friend. However as Facebook tries
to model more of our offline world, it is clear that these aren’t the only types of
relationships that users can have nor are these nodes the only entities users can
have a relationship with. Which brings us to…

Figure 3: The Facebook Social Graph in 2011

The Open Graph Protocol is the first step in allowing Facebook users express relationships
with arbitrary social objects. If you aren’t familiar with the concept of
social objects, Hugh McLeod wrote a great introductory post on this concept entitled social
objects for beginners which is excerpted below



The Social Object, in a nutshell, is the reason two people are talking to each
other, as opposed to talking to somebody else. Human beings are social animals. We
like to socialize. But if think about it, there needs to be a reason for it to happen
in the first place. That reason, that “node” in the social network, is what we call
the Social Object.

Example A. You and your friend, Joe like to go bowling every
Tuesday. The bowling is the Social Object.

Example B. You and your friend, Lee are huge Star Wars fans.
Even though you never plan to do so, you two tend to geek out about Darth Vader and
X-Wing fighters every time you meet. Star Wars is the Social Object.

Example C. You’ve popped into your local bar for a drink after
work. At the bar there’s some random dude, sending a text on this neat-looking cellphone
you’ve never seen before. So you go up to him and ask him about the phone. The random
dude just LOVES his new phone, so has no trouble with telling a stranger about his
new phone for hours on end. Next thing you know, you two are hitting it off and you
offer to buy him a beer. You spend the rest of the next hour geeking out about the
new phone, till it’s time for you to leave and go dine with your wife. The cellphone
was the social object.

Example D. You’re a horny young guy at a party, in search of
a mate. You see a hot young woman across the room. You go up and introduce yourself.
You do not start the conversation by saying, “Here’s a list of all the girls I’ve
gone to bed with, and some recent bank statements showing you how much money I make.
Would you like to go to bed with me?” No, something more subtle happens. Basically,
like all single men with an agenda, you ramble on like a yutz for ten minutes, making
small talk. Until she mentions the name of her favorite author, Saul
Bellow. Halleluiah! As it turns out, Saul Bellow happens to be YOUR FAVORITE
AUTHOR as well [No, seriously. He really is. You’re not making it up just to look
good.]. Next thing you know, you two are totally enveloped in this deep and meaningful
conversation about Saul Bellow. “Seize The Day”, “Herzog”, “Him With His Foot In His
Mouth” and “Humbolt’s Gift”, eat your heart out. And as you two share a late-night
cab back to her place, you’re thinking about how Saul Bellow is the Social Object
here.



There are more examples in Hugh’s post but you get the idea. Social objects had been
represented by “fan pages” in the Facebook world but with the Open Graph Protocol,
it is now possible for any random website to become a part of Facebook’s social graph.
This is a very powerful and liberating concept both from the perspective of what it
enables Facebook’s platform to do but also because it gets rid of some ugly forms
of lock-in. For example, Robert Scoble would no longer need to maintain a brand presence
on Facebook at http://www.facebook.com/scobleizer that
is different from his website at http://www.scobleizer.com to
stay connected with fans of his blog who are Facebook users. 

Turning Web Pages into Social Objects

The process of turning a web page into a social object that Facebook can add to their
social graph is very straightforward. From the Open
Graph Protocol documentation we learn



To turn your web pages into graph objects, you need to add basic metadata to your
page. We've based the initial version of the protocol on RDFa which
means that you'll place additional <meta> tags in the <head> of
your web page. The four required properties for every page are:

og:title - The title of your object as it should appear within the
graph, e.g., "The Rock".

og:type - The type of
your object, e.g., "movie". Depending on the type you specify, other properties
may also be required.

og:image - An image URL which should represent your object within
the graph.

og:url - The canonical URL of your object that will be used as its
permanent ID in the graph, e.g., "http://www.imdb.com/title/tt0117500/".

As an example, the following is the Open Graph protocol markup for The
Rock on IMDB:

<html xmlns:og="http://opengraphprotocol.org/schema/">
<head> <title>The Rock (1996)</title> <meta property="og:title"
content="The Rock" /> <meta property="og:type" content="movie"
/> <meta property="og:url" content="http://www.imdb.com/title/tt0117500/"
/> <meta property="og:image" content="http://ia.media-imdb.com/images/rock.jpg"
/> ... </head> ... </html>

The following properties are optional for any object and are generally recommended:

og:description - A one to two sentence description of your object.

og:site_name - If your object is part of a larger web site, the name
which should be displayed for the overall site. e.g., "IMDb".



For now Facebook supports a limited
set of object types from the following categories; activities, businesses, groups,
organizations, people, places, products & entertainment & websites. Once your
page is marked up and categorized, the next step is to provide a way for users to
add it to their social graph on Facebook. This is done by using adding the Facebook Like
button to the page. From then onward, when a user clicks the Like button they
become a fan of that page.

Not only is your page added to their profile but you can also send news feed updates
to all the people who have liked your page (just like “Fan Pages” can) if you associate
the Like button with your Facebook ID. Doing that provides you with an admin page
where you can post news feed entries from.

The Return of the Semantic Web

One of the things I find most exciting about this development is that sites now have
significant motivation to be marked up with extremely structured data which can then
be consumed by other applications. Having such rich descriptive metadata will be a
boon to search engines especially those from startups since some of the big guys consider
their ability to extract semantics out of HTML tag soup a competitive advantage and
have thus fought the semantic
web for years.

In the social media space, a few people have focused on the fact that this data is
put in place to enable sites to be added to Facebook’s social graph. However there
is little reason why other social networking services couldn’t also read the same
markup as a way to add those web sites to their social graph. For example, Yelp is
one of the sites that now supports the Open Graph Protocol so when I click like the Pro
Sports Club it is added to the list of “pages” I’m a fan of on Facebook. However
I could just as easily see that being a [Twitter – Like] button which would add the
Twitter account for the gym to my following list along with tweeting to my followers
that I liked the gym. It would only take adding a markup element to what Yelp is outputting
to indicate the Twitter account of the page being liked. With my Windows Live hat
on, I can imagine going to Amazon or IMDB and clicking a [Windows Live – Like] button
which would add the movie to my
list of favorite things. There are a ton of possibilities this opens up in a totally
decentralized way without forcing services or users to be locked into a particular
social network.

This has been the dream Tim Berners-Lee has been pushing for years and I’m quite surprised
to see Facebook being the service to take RDFa mainstream.
One of the things I’m happiest about is that Facebook chose RDFa for their implementation
instead of the much hyped yet weaker solution, microformats. As Evan Prodromou wrote
a few years ago in his post RDFa
vs. Microformats, RDFa encourages interoperable[…]

There's an interesting post on ReadWriteWeb about a burgeoning technology effort supported
by a number of web companies titled XAuth:
The Open Web Fires a Shot Against Facebook Connect which states



A consortium of companies including Google, Yahoo, MySpace, Meebo and more announced
tonight that it will launch a new system on Monday that will let website owners discover
which social networks a site visitor uses and prompt them automatically to log-in
and share with friends on those network. The system is called XAuth and
serves to facilitate cross-site authentication (logging in) for sharing and potentially
many other uses.

Facebook and Twitter, the dominant ways people share links with friends outside
of email, are not participating

...

What XAuth Delivers

It's like Facebook Connect, but for every other social network.

The gist here is that XAuth will make it easier for sites around the web to find
out what social networks you are using, let you log in to those easily, access your
permitted information from those networks in order to better personalize your experience
on their site and easily share their content back into your social network. It's like
Facebook Connect, but for every other social network. Any website can register as
an identity provider with XAuth, too.

What About OAuth?

If you're familiar with OAuth,
you might be wondering what the difference is between that system of secure authentication
and XAuth. Here's one way to explain it: XAuth tells a webpage "this is where
the site visitor does social networking." Then, OAuth is the way the user logs
in there, granting the site permission to access their info without seeing their password.
In other words, XAuth tells you where to ask for OAuth from.

Google's Joseph Smarr, recently hired because of his high-profile work on distributed
identity systems across the web, says that XAuth is a provisional solution to the
limitations of the cookie system. If you visit ReadWriteWeb, for example, our servers
aren't allowed to check the cookies left on your browser by the social networks you
use because they are tied to URL domains other than ours.



The first thing that is worth pointing out is that XAuth is not like Facebook
Connect. Facebook Connect enables a website to associate a user’s Facebook identity,
social graph and activity stream with the site. XAuth enables a website to discover
which services an end user is a member of that support associating a user’s
identity, social graph and/or activity stream with third party websites.

A practical example of this is the various sharing options at the bottom of this blog
post (if you’re viewing it in the browser on your desktop PC)

This is a fixed list of options that where I had to write special Javascript code
to handle each service. There are a few issues with this approach. The first is that
people end up seeing exhortations to share on services they don’t use which is just
visual noise in that case. Another is that, each of those widgets involves a Javascript
call to the domain of the service which impacts page load times. In fact, I used to
have a Reddit widget but took it out because their
server was too slow and noticeably impacted rendering of my blog. Finally, I tend
to keep the list small because I don’t want my blog posts to suffer from the NASCAR
problem so some services that may be popular with my audience audience are left
out (e.g. I have no widgets for sharing on Google
Buzz, Slashdot or Digg).

How the XAuth specification attempts to solve
this problem is fairly straightforward. Services that want to participate include
some Javascript from http://xauth.org which writes
some data to the local storage (not cookie) for that domain when the user visits the
social network. At that point there is now an indication on the user’s machine that
they are a member of the aforementioned social network. Then when the user visits
a site such as my blog, I also include the same Javascript from but this time I ask
it if the user is a member of the social networks I’m interested in. Once the list
of sites is returned, I then only have to render sharing widgets from the sites I
support which the user is a member of.

In general, I think XAuth is a legitimate attempt to solve a valid problem. However
it should be made clear what problems XAuth doesn’t solve. For one, people like me
who have an account on Facebook, Twitter, Digg, Google, Windows Live, Reddit, 
Delicious, etc will actually have a more cluttered experience than we do today. I
know I’m always a little confused when I visit a site that uses Clickpass since
I can never remember if I’ve associated that site with my Facebook, Windows Live,
Yahoo! or Google account. Similarly XAuth will potentially exacerbate the problem
for the subset of people who are members of lots of social media sites. Another thing
to be made clear is that this isn’t a replacement for delegated authentication and
authorization technologies like Facebook
Connect, Twitter’s @Anywhere or OAuth
WRAP. Sites will still need to support all of these technologies if they want
to reach the widest audience. This is just about hiding options from users that do
not matter to them.

The one thing I’d keep an eye on is that XAuth provides a token that uniquely identifies
the user as part of the results returned to the requesting site instead of a simply
stating the user is a member of a specified social media site. This enables the requesting
site (e.g. my blog) to potentially make some API calls to the social network site
for information specific to the user without asking for permission first. For example,
pre-populating the user’s name and display picture in a comment box. Since Facebook
has already announced such functionality I guess people don’t think it is overstepping
the bounds of the user relationship to enable this feature on any website the user
visits without the user explicitly granting the sites permission to their profile
information. It will be interesting to see if implementations of this feature steer
clear of some of the creepiness factor of Facebook’s Beacon program which led to massive
outcry in its day.

Now
Playing: Jamie
Foxx - Winner
(featuring Justin Timberlake & T.I.)