Category: Internet and Social Media

Google Buzz Test Drive Report

Posted by Dhananjay Nene – February 10, 2010

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.

Opera Unite : A model for server disintermediation on the internet

Posted by Dhananjay Nene – June 16, 2009

Since Opera Unite got introduced a couple of hours ago. I had a chance to do a quick review of the functionality. As I begin to play with it, couldn’t but help write a short post on what it seems to be doing.

Here’s what my preliminary look into Opera Unite suggested :

  • It has a web server bundled into the browser.
  • It allows you to write (what would be in current parlance be called) serverside apps using javascript which are hosted by the web server.
  • Sample applications include photosharing apps to share photos on your desktop or fridge which allows internet users to post notes to you.
  • It allows these apps to be accessed across a router on a dynamic IP using a subdomain on a centralised operaunite service ..operaunite.com (not sure yet whether across a firewall as well but seems so)
  • It allows these applications to be shared / published using the config.xml file (similar to google widgets ?). There’s also a central opera directory for the same, but I don’t think sharing is restricted to that service alone (apple are you listening ?)
  • These applications can be further installed by other users of Opera Unite (which is the web server service running inside the Opera browser).

So why is this such a big deal ? Without going into any further elaboration let us just imagine user’s used it for following (for desktop-to-desktop or peer-to-peer) communication :

  • Send mails to each other – disintermediates email services
  • Send short burst messages to each other – potentially disintermediates twitter
  • Share files with each other – disintermediates ftp servers and shares characteristics with gnutella, kazaa etc.
  • Share resume, product profiles etc. – disintermediates traditional static web hosts
  • Build networks of other interested users – disintermediates linkedin, facebook

The constraint it introduces is that there is no global list of user ids to search from – you need to know the URL upfront (like the facebook vanity URL).

The possibilities are many. As are the interesting uses this model could be put to. And the characteristics of improved privacy, data ownership and control (including fine grained access control or selectivity). And there does remain a potential for malicious actors and virus writers to ride on popular apps to exploit vulnerabilities to tend to their nefarious needs.

As I put it differently in another tweet – this opens up the possibility for a google wave without the google in it.

References :

Twitter / HTTP / REST API Invocation Infrastruture using data pipelines

Posted by Dhananjay Nene – March 17, 2009

This blog post is not about twitter API programming, though thats what it does deal with. It focuses on the intermediate level infrastructure (ie. higher than the HTTP/REST APIs exposed by other sites but lower than the class libraries that surround those) necessary to work with HTTP/REST based APIs being offered by various web sites.

I have been working on scouring and analysing twitter data for which I have been having to work with continuously accessing twitter on a sustained basis for a number of days. I started refactoring my code recently, and this blog post details the results of that exercise. More specifically in the context of invoking HTTP APIs it deals with the following aspects (many of them which are specifically introduced due to twitter.

  • Ability to make HTTP Calls and deal with HTTP error conditions
  • Ability to deal with Connection and other failures and allow for auto retries
  • Ability to make HTTP Calls in bulk in batches
  • Ability to spawn HTTP Calls across multiple threads
  • Ability to respect and deal with API Rate Limitations

I have specifically focused on creating a pipelined design which might be an interesting design aspect for many in this situation, and have primarily relied on python based generators for the same though similar functionality could be built using Iterators in other languages as well.
More…

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

Posted by Dhananjay Nene – February 27, 2009

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.