Posts Tagged: facebook


10
Jul 11

Google Plus : Getting close to the sweet spot by getting the basics right

My first reaction to google plus was Nice. But facebook has a lockin on the friends and people will not shift until their friends shift which will pretty much mean most will play around with google and then go back to facebook since thats where their friends are.

As I played with it a little more, I realised the Circles were a little confusing. It took me a while to realise who exactly got to see my posts when I posted them to my extended circle. While they allowed you a more natural way to constrain publishing to a private subgroup of your network, their organisation wasn’t exactly simple or natural (though I’m sure Google worked very hard even to get circle management to its current shape). Despite its bold move on circles that has been well received. I think circles will need to be better managed. It will perhaps take some time for the feedback from the community to find its way back into superior circle management.

So while I was willing to give it more credit than google wave, it didn’t quite blow me off my feet. And I imagined facebook to continue to be the unchallenged king of social networking.

As I used it over the week, I felt my perceptions changing. Not in a manner that I could feel the change strongly, but slowly and quietly. And then it struck me. The gauntlet had indeed been thrown quite credibly. And the king is now being challenged.

Here’s why. At a very fundamental level, google is changing the game. And it is not wanting to be the king of the social networks as understood today. It wants to be the be king of social networks that will be.

The Public / Private Asymmetric Network :

Facebook is a private network. Sure you can make your facebook status update completely visible for everyone to see, but thats really an atypical usecase. Facebook allows me to bring online the friends I made in the past. Friends I now therefore trust. Friends I can make remarks to that I wouldn’t want to make publicly. And barring a few exceptions (eg. when someone ranted about their job only to find their boss reading the rant), the model held. Privacy is important, critical and assumed. Any real or perceived violations of privacy are met with an uproar. What facebook does not allow me to do (at least based on the easily understood controls available to me) is create further subgroups within my network (it actually does that – but I rarely find myself using these features and doubt if many others use them). It takes my “offline photosharing” and makes it “online”. It takes my “offline gossip” and makes it “online”. Facebook “takes my offline network” and “makes it online”.

Twitter on the other hand is a public network. There should be a tagline which says “Everything you say, can and do will be used against you in a court of law, in your classroom, in your job, in your sports team and even within your friends and family”. But its not really required, and no one misses it, since most Twitter users very quickly understand it. With twitter, I can eavesdrop on conversations between two other twitter users, and neither of them are likely to object nor am I likely to feel guilty – since that is consistent with the conventional protocol. Twitter is a public network. It is perfectly normal for strangers to start engaging in a conversation. It therefore has this end result called “serendipitous discovery” of both information and relationships. Most of the people I interact with on twitter are people I met online. And later on I feel nice when I end up meeting them in real life. Twitter is all about “discovering an online network” and then when feasible “bringing part of the online network offline”.

Twitter is also an asymmetric network. While facebook carries friendships online, twitter enabled followings in an asymmetric fashion. Which allows me to fine tune the messages that I choose to listen to. Thus I am no longer required to read the status updates of those who wish to read mine. (Facebook allows this too via hiding- but again thats probably not a very typical behaviour). Offline conversations are constrained by space and time – the people who are conversing need to be at the same place at the same time. Thus they are often necessarily symmetrical (An example where that is not true is when a charismatic leader is say addressing a large crowd – the leader hardly knows each person in the crowd, though they all know him a lot better). Online networking removes the constraints of space and time. Thus asymmetric relationships are much easier to support.

While most understood facebook very quickly, for a lot of people the response to Twitter is “I don’t get it”. And part of the reason is that twitter does not convert an offline network to online network, but is really pushing at the boundaries of what an online network can be. While I value the privacy of my data on facebook, I actually value the serendipitous discovery and the astonishing learning I can benefit from with twitter so much more, because it has enabled communication and network patterns that were not earlier feasible in offline networks given constraints of space and time. And while the 140 character magic holds, it does become painful when tracking long and convoluted conversations.

Google Plus groks this. It has smartly enabled the capabilities and features of a public and private network. While you can push your posts on the public channel and eavesdrop and participate on conversations others are holding on the public channel, it simultaneously affords you the choice to constrain your messages to the specific group of people that you would choose to constrain them to. It also has the most rudimentary capabilities to start building an interest graph. And it is asymmetric which helps each person maximise the value he gets from the network. Moreover it has features to allow me to implement the appropriate communication patterns with people that I share my childhood photographs with, with those I work with, and those that inspire me. It has simultaneously enabled private gossipy conversation, listening into the people I respect (not befriend), and serendipitous discovery.

Ka Ching!

The unified consolidated channel

Once upon a time, I had a watch, a camera, a phone, an alarm clock, a map, a hi-fi audio system, a radio, a TV / DVD player to play my DVDs. Now I have a smart-phone. And while the really keen will continue to own each or some of the individual components, it is neither a surprise nor a secret, that my smartphone is ever encroaching into their territories. We want these together, and we want them to be easy to carry.

While online services are inherently portable and thus the physical form factor of having to carry them around is not applicable, the integration of various service is an important factor. Google Plus is but one element of a broader channel. Incoming notifications on google plus show up in a small red box at the top right corner of my gmail tab. Now imagine gmail, google docs, google plus, picasa, youtube, google maps, google music, google latitude, google storage all getting (social / interest) network enabled. And imagine them being available in google apps also. And imagine them simultaneously available on desktops, netbooks, notebooks, tablets and mobile phones. Google already has most of these pieces – what it lacked is that these were not “network friendly”. Imagine each of these assets becoming network friendly – I can publish google docs to a specific circle I had defined on google plus. It has been suggested that the google plus we see today is but an early stage view of what is likely to be a continuous rollout of features over a year. Whether you look at facebook, linkedin, slideshare, foursquare, skype, or quora – they are the watch makers, camera makers, radio makers. Google is building the online smartphone. And that will probably be the important advantage google will have to offset facebook’s entrenched user base. That will cause many of your friends on Facebook to also start using Google Plus. Google Plus is google’s one ring to bind them all.

Openness :

Facebook did a phenomenal job in opening up its screen real estate to a number of other applications through its platform API. However it has also attempted to lock-in the users by licensing constraints. (eg. Robert Scoble getting his facebook account disabled). On the other hand google has made a public commitment to keep its data under the users’s control all the time including being able to move it out. As we start utilising the graphs we build across many more applications, and especially the more serious ones than the FarmVilles at Facebook, data openness will continue to become more critical. Unless others play catch up with google, in terms of its commitment to open data – this will start becoming an increasingly stronger factor in google’s favour.

In summary

Google plus is credible execution to fill an important gap in google’s earlier offerings. However it goes well and beyond just private social networking. It is really building public / private, asymmetric networking built using social graphs based on friendships, work relationships, online discoveries and probably soon enough interest graphs as well. It is building the network that will be. While google wants to own the experience, it is liberal enough to publicly commit that the data is owned by the user. Combined with the awesome google portfolio and its evergrowing warchest built out of search advertising revenues – This is the network to beat.


10
Feb 10

Google Buzz Test Drive Report

Feature Notes :

Note: Google Buzz had not yet been enabled for me through normal GMail Desktop access. These notes are based on my experience with the same by switching my Firefox user agent to iPhone and accessing the iPhone Google Buzz UI.

  • Has a very facebook / friendfeed like interface.
    • Comments : People can enter comments against a post which appear sequentially below the post.
    • Like : Has the Like feature also supported by facebook / friendfeed
    • Inline images and videos : Images and videos appear inline as a part of the stream.
    • No 140 character limitation : Or at least none that I observed
  • Each conversation becomes a web page. eg. the comment stream against my very first google buzz post.
    • The same conversation is also posted to your inbox. The conversation in the inbox gets dynamically updated as the conversation continues. A conversation that has been read earlier gets marked as unread when more comments are entered against it.
    • The conversation web page becomes an alternative location for participation. If say the conversation link is forwarded to others, they can immediately comment on (or choose to “Like”) the conversation from the web page itself.
  • Private Channeled Messaging. You can mark posts as private but directed to a group of people. These groups are maintained and managed using Google Contacts. To the best of my understanding the future conversation is also constrained to the same group. Such messages are obviously not visible publicly. This is an excellent feature for closed group interactions.
  • Directed messaging is supported using the familiar twitter ‘@’ style. However in this case you use ‘@’ followed by the entire email address. Any posts made with ‘@’ addressing also get delivered to the user’s inbox.
  • Geolocation integration is supported. Thus you can view the public posts being made by people nearby you. Since I used firefox, it used firefox for geolocation support. I imagine and presume it would be using alternative superior mechanisms for mobile based conversations.

Comparison to Twitter :

One of the reasons I test drove Google Buzz was since I was wondering if it was a better Twitter. In many ways it is. But I don’t think thats likely to be universally true. There is the 140 character simplicity to twitter which is its identifying feature. In many ways Google Buzz is a Friendfeed clone – not a twitter clone (with added inbox integration). I always found Friendfeed much superior to twitter for conversations and I suspect those who shared that perception will find Google Buzz far superior to twitter too. However it will run into the same difficulty that Friendfeed did. If the twitter user doesn’t correlate his twitter account to the friendfeed account, it is very laborious in friendfeed to add a user you follow as an imaginary user in order to have his tweets appear in your friends stream.

I think where Buzz will take on Twitter .. and big time is the really large number of people who sign on to twitter, maybe make a few tweets and then say I don’t get it and go away. I suspect most of them will “get it” on Google Buzz – especially if they have any Facebook experience (which is a large large set of people). In that sense while Twitter appealed to only a small set of people, Buzz at least has the potential to appeal to the mainstream .. and in that sense go for the jugular – Facebook’s that is.

Comparison to Facebook :

Since facebook over a period of time has cloned its update stream to be like that of Friendfeed, it should come as no surprise that the Buzz stream is likely to look and feel quite similar. However two big differences stand out. The first is the way the social graph is managed. The social graph unlike facebook is asymmetric. ie. two persons don’t have to agree to be friends to follow each other. In case of Buzz, the social graph is managed through google contacts. You can follow people who have public google profiles or follow anyone in your contacts. Thus if a person doesn’t have a public google profile or his email address is not known to you, you may not be able to follow him/her. You don’t need the other person’s permission to follow. (At least thats the impression I formed, though I could stand corrected). The other big difference is the email integration. The entire stream and conversations are integrated into the gmail account. For most knowledge workers, I think these differences are likely to make for a more positive experience. In that sense – buzz is extremely well suited to be the Facebook of knowledge workers. Whether it can compete with the trivial, frivolous, chatty social networking capabilities of Twitter or Facebook is something I couldn’t form a clear opinion on.

On carving a new market :

Based on my earlier statements, it should be obvious that I believe buzz will carve new markets which did not use Facebook / Twitter / Friendfeed earlier. These markets are :

  • People who tried twitter but didn’t get it
  • People who primarily use email for communications instead of facebook / twitter (for both Personal and Business Networking)
  • People who would like to use Facebook / Twitter like capabilities from a knowledge working / business perspective.
  • People who are just too nervous to use anything new on the net may still find the email integration a continuum of their email exchange rather than a ‘new web site’.

On Privacy :

I think Buzz definitely ranks superior on privacy, given its capability to conduct private directed closed group conversations. As an example, I can imagine many google apps installations which could use buzz for intra company conversations even as they clearly restrict even the public streams not to be visible outside the domain. While I haven’t seen any comment from Google on whether buzz would be available for google apps, I imagine its only a matter of time since it is so particularly well suited for that environment.

On google wave :

Google wave in many ways was a damp squib. It imposed a new usability paradigm even as some of the capabilities such as near real time updates were clearly superb. Google buzz reverses the wave approach by offering a different conversation model which dovetails not only into similar usability expectations as defined by the competition but goes one step beyond by integrating into the killer web application – web mail. I wouldn’t be surprised if it came to light later that Google buzz is a google wave backend with a completely new usability experience.

A note on integration :

While its only a statement of intent at this stage, google has setup a site for the Google Buzz API. However the promise is awesome in terms of multi standard support for variety of standards and protocols support including RSS, Atom, PubSubHubbub, Social Graph API, OAuth, WebFinger and Salmon. It does seem that google will want to support a variety of other alternative and mashup use cases around Google Buzz which might allow for more interesting uses to emerge (as it happened for Facebook and Twitter). Clearly a space to watch with some interest in months to come.

In summary :

Google buzz makes the strongest case for appealing to the power email users and those particularly focused on privacy (eg. knowledge working for businesses). Its strong differentiator is its mail integration. It does offer adequate features to compete with Facebook / Twitter for their existing markets as well. And joins the party with a large number of people – who already have a google account.


27
Feb 09

Data Sans Frontiers : Data on the cloud : Facebook and its new statements

A little over a week ago after the Consumerist published its commentary on Facebook’s modified terms of service, I had deleted my data from my Facebook account and had written at length about what I perceived were the issues with the modified TOS : Why I deleted my Facebook data. Commentary on Internet data privacy rules. A couple of days after that Facebook under pressure from all the adverse feedback, reverted to its old TOS and assured to work with the community to work out a new TOS over the coming few weeks. Earlier today, it released a proposed Facebook Principles and a proposed Statement of Rights and Responsibilities for community review as a part of that process. This was covered by TechCrunch, Silicon Alley Insider, Mashable and Inside Facebook.

Unlike my earlier post, this does not critique Facebook’s actions but instead attempts to analyse the statements in the context of a newer dimension of data thats mobile on the cloud. This brings in both a set of challenges and opportunites and I shall try carefully to not fall into the FUD zone as I discuss these challenges. Finally it also discusses these statments and its implications on user’s and their awareness education challenges. In this exercise I treat Facebook as one of the early providers who is facing and attempting to address these challenges of “mobile data on the cloud” in terms of its privacy and security implications. But in the mashup world, it is likely to be a challenge that both the users and a number of other service providers have to eventually start dealing with.

Allow me to add my annotations on these statements.

Proposed Facebook Principles

A very nice and clear enunciation.

  • Point 1 : Note the specific mention of “service”. Thats what in my opinion is leading to many of these challenges.
  • Point 2 : Perfect in principle. However one technical issue needs to be resolved. How does one define “received information“. If my status update is seen by another user and it has appeared on his wall, has he received information ? Probably not since it is quickly clarified that this is particularly outside the Facebook Service. So we are probably talking about an external application to which facebook feeds the data, another user who might have downloaded some data on his desktop, potential third party services such as search engines (which usually aren’t allowed to scour this data) or other analytics services. I think its a fair statement. The only suggestion I would have is that there probably needs to be some amount of user (re)education to understand its implications.
  • Point 3 : Clearly refers to the fact that information will be shared with other users and services including through tools (desktop apps / mobile apps ?). Sets up the ground for API usage.
  • Point 4 : A great point. Establishes a level of symmetry amongst the parties which was one of my sore points in the earlier modified TOS
  • Point 6 : Clearly documents API usage to access data
  • Point 10 : Notes that the data is not just mobile across organisations (ie Facebook and its applications) but also across geographic boundaries.

OK, lets quickly review the next statement.

Proposed Statement of Rights and Responsibilities :

Point 2 is an important one to note, especially 2.2 and 2.3. Point 2.2 is wonderful to the extent that it clearly defines that facebook eventually will delete data that a user deletes or in case the user deletes the account. It also specifies that content shared with others may remain until they delete it. Now this content is in all likelihood going to be third party applications and services. Here’s an interesting tripartite arrangement – theres now going to be (for practical purposes) a mini-TOS between the user and Facebook which this statement covers, between Facebook and the third party provider, which I think is likely to be covered within this document as well (well, at least parts of it) and probably one between the user and the third party service. Its the last one which could be worrisome, since the user may now need to worry about each TOS with each third party provider. Most users are unlikely to review each of those terms with the level of detail, yet find their data moving to the third party provider. However, how and when that could get deleted is also addressed later in this statement. Point 2.3 also clearly documents the fact that subject to the user privacy and application settings Facebook assumes a whole bunch of capabilities around such intellectual property. Unlike in the modified TOS, this gives the control to the user to decide how the intellectual property will be treated. Since the control is with the user, I think it is a fair clause to ensure that Facebook itself is not at the receiving end of any intellectual property rights dispute.

In point 3 Facebook attempts to secure the fact that its users do not harvest information or otherwise maliciously gather access to store information that they shouldn’t get access to store. Why the focus on store ? The clauses around using the API are likely to have strict conditions around what data can be stored by the third party application and for what duration (which is true today as well). So its the social or screen scraping or other non-API ways of collecting data that Facebook is trying to secure against.

Point 5 sets up the environment for users to respect property rights of each other. Point 5.7 especially ensures that services clearly document their privacy policies when collecting data and inform the user that the data is being shared with the service and not with Facebook. Point 5.8 ensures that users don’t post other user’s sensitive information and then let it stream over the cloud potentially into other applications and services. Quite reasonable in my opinion.

Point 9 is probably one of the most interesting sections. The important point here is that Facebook has clearly communicated with the user, the undertakings of the applications, websites and services. Coupled with 5.7 and 5.8 above, it essentially creates an environment where the user is clearly aware of the boundaries between Facebook and other services, and that once the data crosses that boundary, that data for all practical purposes is governed by the agreement between the user and the other service. 9.16 was one which did arouse my curiosity a bit. We now start seeing the outlines of why the TOS needed to be modified in the first place.

Finally point 12 also goes to a great distance in assuaging the concerns raised about unilateral and quiet change of TOS earlier. It allows for upfront communication with the users, a reasonable notice period and curiously a vote based user veto (not sure why this really was required, but then I would be surprised if 30% of the user base actually voted).

So what about data sans frontiers ?

In the earlier modified TOS, Facebook had attempted to secure a very large number of rights in order that it would stand protected (if and) when large parts of user’s data start getting shared with other applications, websites and services. Thanks to the user reactions, it has now crafted a very different statement. In this statement while Facebook now assumes far fewer rights, and those it assumes to me seem like part of a fair and symmetric relationship. The way I read and interpret this is that under this statement, Facebook clearly defines a set of boundaries or frontiers (ie. the Facebook Service), and undertakes and provides a mechanism to properly share and control the sharing of such data within such frontiers. However it also makes it abundantly clear, that the user is now adequately aware that it has far lesser control the moment the data crosses such frontiers, and at such a stage this data will now get controlled by the third party services, that the undertakings by the third party service are clearly specified and the user is fully in the loop on this issue. Again seems fair from a corporate perspective and in terms of securing itself from misbehaviour or other inappropriate activities or accidents on the part of the third party services.

The catch is now that the onus is on the user. He has to clearly understand the implications of (perhaps even more detailed) privacy controls, and agree to the fact that once the data crosses the facebook frontiers, facebook has taken adequate precautions in terms of ensuring that the appropriate undertakings having been provided by the users and the services, and that any issues that crop up further could perhaps be bilateral issues between the users and the third party service.

I don’t know that all users are actually in a shape to understand all these implications, and suggest that some mechanisms be put in place to provide users some tutorials or presentations which explain these in as easy and lucid manner as feasible. Users will need to exercise the Caveat Emptor clause before subscribing to / using other services which integrate with Facebook. Users will need to be aware that based on their privacy settings and application requirements, their data is now moving from host to host, company to company, and country to country. On the whole while this does place a far bigger burden of exercising caution on the user, it also puts the user in control and is a far more symmetric statement than the earlier modified TOS.

Finally in an increasingly mashup and service integration driven world, I fully anticipate many more companies and users having to deal with these very issues in other non Facebook contexts as well. This statement is likely to also play a role in the ongoing discussion about the capabilities and the risks of having data in the cloud. If these statements can be agreed upon in a format that is acceptable to all, there’s a good likelihood it will provide the precedent for many more service arrangements being drafted in the future in a relatively similar and consistent fashion.

A programmer is unlikely to be a good lawyer : I am a programmer and have very lay understanding of legal matters. This opinion is based on my understanding but such an understanding could be wrong or inaccurate when looked at by a more skilled person. It is most certainly not a legal opinion and could contain discrepancies, inaccuracies or improper assessments on my part. If you note or find any, please add your comments so that others can benefit from your views as well.


16
Feb 09

Why I deleted my Facebook data. Commentary on Internet data privacy rules.

Update: Facebook has since reverted the change in terms of service. Cool. On Feb 18th, a message on the home page said :

Terms of Use Update

A couple of weeks ago, we posted an update to our Terms of Use that we hoped would clarify some parts of it for our users. Over the past couple of days, we have received a lot of questions and comments about these updated terms and what they mean for people and their information. Because of the feedback we received, we have decided to return to our previous Terms of Use while we resolve the issues that people have raised. For more information, visit the Facebook Blog.

Mark Zuckerberg also blogged about the same issue in Update on Terms.

Original post begins here.

Facebook published a new Terms of Service on February 4th 2009 which has a strong implication for how internet / cloud based data privacy is likely to be viewed. This was very well publicised here – Facebook’s New Terms Of Service: “We Can Do Anything We Want With Your Content. Forever.”. There was some consternation on the net especially on twitter about this change in facebook rules. While I did not use facebook much, I was sufficiently appalled at the change in rules to go and delete pretty much most of my data one line at a time. It is unclear to me if the old data is still available to facebook for sublicensing from a legal perspective (I know all the data will be there in their archives), but I decided it probably wouldn’t hurt to nevertheless to go delete most of it. I didn’t actually delete the account since Facebook still helps me keep in touch with my friends. But it is quite safe to assume that any interactions with them with an assumption or requirement of any data privacy will no longer be done on facebook.

Whats wrong with the new terms of service ?
Some people in forums argued that most of the data on internet is likely to be there forever. So one just needs to be careful and not worry about it. I don’t quite agree with that line of thinking. When I blog, tweet, post to usenet or forums, I am upfront aware of the fact that that data is going to be cached by google and other search engines and that once I press the publish button, there’s often no way to revoke it. However in case of Facebook, there is a general expectation that the data will be shared only within a network of friends, a network that I have control over. There is an expectation that that data will not get cached by search engines and short of an accidental data breach or some intentional malafide activities that data will not become public. What is unnerving with the new terms of service is that Facebook changed these rules at will without even sending me an email about the same.

Asymmetry of Privacy Expectations :

It is interesting to note how asymmetric some of the terms are. For example in the section User Content, the following is to be found.

By using or accessing the Facebook Service, you represent, warrant and agree that you will not Post:

* User Content that violates the law or anyone’s rights, including intellectual property (“IP”) rights or other proprietary rights (such as rights of publicity and privacy);
* any Contact Information or private information of any third party;

Further down in the section Licensing, it states,

You hereby grant Facebook an irrevocable, perpetual, non-exclusive, transferable, fully paid, worldwide license (with the right to sublicense) to (a) use, copy, publish, stream, store, retain, publicly perform or display, transmit, scan, reformat, modify, edit, frame, translate, excerpt, adapt, create derivative works and distribute (through multiple tiers), any User Content you (i) Post on or in connection with the Facebook Service or the promotion thereof subject only to your privacy settings or (ii) enable a user to Post, including by offering a Share Link on your website and (b) to use your name, likeness and image for any purpose, including commercial or advertising, each of (a) and (b) on or in connection with the Facebook Service or the promotion thereof.

As you can see, you undertake to not violate anyone else’s IP or other proprietary rights, but information about you will not be treated with the same level of respect by Facebook, though its done quite legally by documenting the same in the Terms of Service.

Moreover anything you post or any information on your stream is now sub-licensable by Facebook. Now why would I exactly want to sign away all rights on status updates, photographs etc. on content which I posted assuming that it was secure and private ?

But the earlier terms were also quite onerous. So how come you did not complain ?

Apparently under the earlier terms, facebook also had the rights on the content, so whats the big deal ? Two main issues.

  1. The earlier TOS did not grant Facebook the right to sublicense the content : The possibility of sublicensing means you have no control or idea on who the eventual user of that data could be. I still get angry at so many commercial parties at having leaked my email and phone number data. The likelihood of a similar scenario where facebook sells that data for commercial purposes now cannot be ruled out, purposes on which I will have no control on that data.
  2. The earlier TOS had an escape clause of deleting the account Basically Facebook did not have the right on the data once you deleted the account. This is important as can be seen by another case on Twitter Privacy Disaster At Twitter: Direct Messages Exposed (Update: GroupTweet Is Likely Culprit). In this case private messages were apparently accidentally made public due to confusing software usability. The person immediately responded by deleting the account. This is a useful kill switch to have in case one makes a terrible terrible mistake of putting out something accidentally. This kill switch is also no longer available.

Bait and Switch : By not informing users of the change in terms of service especially since these were so important, I think this creates an impression that the user is a victim of bait and switch (even though the real underlying causes of the change which I am unaware of could be different). Facebook should’ve informed the users about the change in rules, offered a button to delete all prior data / photographs / content or at least made clear that the earlier content will continue to be governed by the earlier TOS – something thats a little unclear in this situation.

Implications for Internet Web sites and users : I think sites should very clearly document how they will control and use the data that they gather. Many of them do by explicitly document the same. Moreover any substantial changes to the same should be communicated to the users. Finally users need to be now aware of potentially changes of Terms of Services on a number of web sites that they interact with. Data that they assume to be private may no longer stay so and the user may not be any wiser about the same if the Terms of Services are changed without him being explicitly informed.


Updates :

Why did I delete the data ? Seems some readers are thinking I deleted the data believing that that will get rid of it. Thats not why I deleted the data. I am fully aware the data is likely to live perpetually in facebook archives and be accessible to facebook. I deleted it because that data had been submitted and generated under the old Terms of Service. Letting it be around to me seemed like an implicit acceptance of the new Terms of Service around old data, which I was uncomfortable with. So I deleted the data at the first available opportunity on realising that the Terms of Service around that data had changed. Any new interactions I do with facebook will be under an awareness of and therefore an acceptance of new Terms of Service.

Response from Facebook : Mark zuckerberg attempts to address the issue on facebook blog : On Facebook, People Own and Control Their Information. I could not find any rationale to why Facebook needs the privilege to sublicense the content. I also thought the way the blog post was written and the way the Terms of Service are structured are very very different. In my opinion its the Terms of Service that count.

This topic has been also getting a lot of traction on other blogs. Am quoting some other interesting opinions on the topic on the internet along with link backs to the posts below

  • cnet News.com : The Open Road : Facebook changes terms of service to control more user data :

    Google has had its own problems with user privacy, but this Facebook move calls into question the wisdom of clouds or, rather, storing one’s data in others’ Web services like Facebook. We need to come up with new licenses or new mandates for open data in the cloud. Facebook shouldn’t own our data.

  • Mashable : Facebook: All Your Stuff is Ours, Even if You Quit :

    The possible implications of this TOS change go beyond these concerns. Sure, you can choose not to use Facebook at all, but that doesn’t mean a thing. Someone can still take your photo, slap it on Facebook, and now neither you nor the author of the photo can stop Facebook from using the photo in whichever way they please. Looking at it globally, millions of people are uploading bits of information on everyone and everything, to a huge online database, and by doing so they’re automatically giving away the rights to use or modify this information to a private corporation. And not only that; they now also waiver the right to ever take it back from it.

    Facebook should take a long, deep look into how it treats its users. Until now, users had options with regards to how the data they generated on Facebook was used. Now, they have no options whatsoever, rather than quit the service altogether. It’s a major difference; I’m not going to take it lightly, and neither should you.

  • Wet Asphalt : The Facebook Freakout :

    You are only granting those rights “on or in connection with the Facebook Service or in the promotion thereof.” What does that mean? Well, it means that you are licensing the use on Facebook branded websites or any other media and the Facebook Platform, which is the legal name for the APIs that allow third parties to create Facebook applications. So if there was a Facebook TV show, they could use your stuff on that. Or if they launched a Facebook concert series or a Facebook magazine, they could use your stuff in that. Presumably, if there were a Facebook dogfood, they could use your content on that. Or if they wanted to make an advertisement FOR any of those things, they could use your stuff in that. Precisely WHY Facebook would want to do any of those things, I leave to the reader to speculate on. What they most emphatically CAN’T do is what Walters claims, that “We can do anything we want with your content forever.” They can do anything they want with your content ON Facebook or to Promote Facebook forever. But if they said that it probably wouldn’t cause the internet panic and generate hits for the consumerist and readers to stroke Walter’s ego with diggs and trackbacks and twitterposts either.


15
Feb 08

A Developer’s Comparison of Open Social and Facebook platforms

h3. Acknowledgement

There are a couple of helpful posts that set me off on the path to blog this so here’s the acknowledgement :

* “Facebook vs. OpenSocial”:http://blog.widgetbox.com/2007/11/facebook-v-open.html
* “OpenSocial and Facebook Platform side by side comparison”:http://www.iosart.com/blog/2007/11/03/opensocial-and-facebook-platform-side-by-side-comparison/

h3. Introduction

I have been spending some time on the Facebook and OpenSocial platforms, and while these both attempt to solve the same need, they end up doing so quite differently. For anyone interested in web based software design, the differences are both curious and interesting, and serve an interesting contrast of how different means can get used to attempt to reach similar ends.

h3. The Facebook platform

The facebook platform primarily allows the hosted applications to access facebook data through a variety of APIs. The hosted application can primarily draw itself onto a “Canvas” which is the primary channel of interaction, and can also render its own part of the profile, and plug into the messaging infrastructure (news feeds, mails etc.). When a user is working with the canvas, the canvas occupies a large share of the screen and thus dominates the interaction with the user.

h3. The OpenSocial platform

The Open Social platform does not really require the applications to be hosted (they can be purely client side applications using HTML, XML and Javascript). The application presents itself as a gadget and can get information about the network graphs fed into it at runtime. When I refer to a client side application I shall be referring to the gadgets with type=html whereas when I refer to an application as a server side application, I am referring to those applications which are hosted with type=url.

Now for some of the important differences.

h4. 1. Application Structure

OpenSocial applications can be both client side and server side. Most of the specification and almost all the examples are those of client side applications. These typically require a high competence in HTML, XML and especially in Javascript. The applications can also be server side but this does not seem to be a predominant mechanism of application serving as yet.

Facebook applications are all hosted on a web site. These typically require a reasonable amount of server side development using a variety of languages. PHP and Java client libraries are provided and supported by Facebook. However client libraries in other languages are also available.

h4. 2. Application predominance

In facebook one application is predominant at a time since the canvas it is provided occupies a majority of the rendered screen space. It is not yet clear how most OpenSocial applications will get presented, though it is quite likely that many of these will coexist on one screen with different independent spaces assigned to them

h4. 3. Control

In facebook, the facebook site itself acts as a reverse proxy between the browser and the application with some substantial mod_rewrite functionality. It thus intercepts the traffic and actually changes the data stream on the fly (eg. by changing all the javascript variable names). The facebook site is always firmly in control.

In case of OpenSocial, the application is provided a space for its gadget to be hosted, and after that the application is firmly in control ie. the browser communicates directly with the application.

h4. 4. Development Skills

Facebook application development skill requirements are likely to be more similar to those required by the conventional server side application development. However the developers will need to learn the facebook platform apis and technologies (eg. rest apis, FBML, FQL etc.).

With OpenSocial if the application is a server side application, the development skill sets are likely to be similar to those of typical server side application development with a lesser requirement to learn newer APIs. However if the application is a client side application and you don’t have serious javascript capabilities, be ready to invest in that quite a bit if you want to create a slick app.

In a scenario where one is using a client side Open Social app, it just seems like the entire controller is getting moved over to the client, and it takes some substantial skills and effort to work through all the interactions in Javascript. I like HTML+Javascript, but dont particularly look forward to writing any more than what is necessary. I generally found that it was relatively faster to work with creating Facebook apps especially in scenarios where a reasonable amount of server side processing was required (FBML is quite helpful).

h4. 5. Application or applet

While one can potentially build both applications or applets with both the platforms, seems like the focus of Facebook is to build applications while that of Open Social is to build applets (small focused functionality) which primarily seems to stem from the fact that OpenSocial borrows heavily from the Google Gadget infrastructure which itself was not focused on heavy duty application development.

h4. 6. Usage of IFRAMES

OpenSocial is likely to depend a lot more on the usage of IFRAMEs. While older facebook applications used IFRAMEs, many contemporary applications do not. Combined with the fact that due to Facebook acting as a reverse proxy, which ensures that the data stream is coming from a single domain, some of the difficulties associated with IFRAMEs especially for passing information across domains and usage of SSL with IE (where I’ve in the past faced some difficulties) can be avoided easily in Facebook.

h4. 7. Security

I am going to go on a limb here and make a conjecture here – Given facebook’s reverse proxy structure and given the fact that its platform had some reasonable time to develop (unlike OpenSocial which just seems like a lets make Google Gadgets into a platform API as fast as we can approach), its “probably” going to be tougher to build more secure applications under OpenSocial

h4. 8. Platform data is being pulled or pushed ?

In case of Server side OpenSocial applications, the relationship graph and user preferences are pushed into the application as a part of the URL itself (reminds me a little bit about dependency injections – except that it is being done for data). Additionally the application can communicate with OpenSocial platform through REST based APIs but these specifications are currently still in progress. In case of client side applications, this data is pulled from the OpenSocial platform and mashed up with the application data on the client side.

Facebook also supports the pull and push models but a little differently. While it has a well defined REST interface along with the corresponding language bindings into PHP and java, it allows the application to pull data from facebook as well as push it to facebook (eg. to write to feeds). However given the reverse proxy structure, in a way Facebook is really pulling the entire application content from the application before it mashes it up on its site (eg. processing FBML tags or changing javascript variable names) before sending it to the browser.

h4. 9. Standards compliance

Clearly OpenSocial could be “considered” to be more standards compliant. However that is a rather mixed blessing – All the proprietary facebook additions eg. FBML tags actually help reduce a fair amount of development effort with no equivalent capability in OpenSocial yet. There still are many things that Facebook platform supports which are as yet unaddressed by OpenSocial, so I am not so sure if the issue is so important yet. But as OpenSocial starts offering more capabilities in future versions this could start becoming an issue.

h3. Summary

Clearly there exist quite a few dissimilarities between OpenSocial and Facebook platforms. These differences are sufficiently large enough to tempt me to call them apples and oranges (though their end goal is to feed me). It would be wise to avoid the question “which one is better ?” However I can indeed state that as a developer having spent a large time on building server side enterprise applications, facebook just seems to be a lot more enjoyable to work with along with it likely to be more stable and more secure. But remember YMMW (some people like apples more and others oranges).