May 25, 2010

Presence: Better You Pull, For I ain't Pushing it

I posted the following at EnThinnai blog. Please post your comments there.

To data almost all Presence serving system push a user's Presence status to others. It is widely considered to be an efficient mechanism rather than individuals periodically polling the Presence status of all of their friends.But this is based an a oversimplified analysis that does not take into consideration accepted social etiquette and potential security and privacy issues. It is better that buddies pull the Presence information of a user directly from that user's Presence server. To further enhance the user experience, Presence server must allow for buddies to subscribe for changes in a user's Presence status with the approval of that user.

Presence service is universally designed as a Push service. Typically, User Clients report the user's network connectivity and keyboard status to a central server which in turn pushes to all the buddies of that user. Some services further allow users to customize the status info, either globally or to a particular buddy. I contend that this is not a preferable method as it is insecure and introduces anti-social behavior.

Consider the following scenario: Abel and Betty are buddies with each other. This allows Betty to constantly monitor Abel's Presence status, so much so can reconstruct Abel's timeline. In real life, even if Abel and Betty are close friends, Betty's behavior will be considered abnormal as dramatized by Lucy and Holden:

Indeed the situation is worse. The real comparison would be the case where Betty were to observe Abel using a periscope without Abel knowin about it. That would be a real anti-social behavior. But that is exactly what the Push system allows.

This problem further compounds when Presence information is shared between federated networks. How does one network ensure that the other network maintains the confidentiality of the shared information? Specifically, if Abel is sharing different status information with Betty and Charles belonging to the same federated network, the expectation is that Charles will not be able to access the information shared with Betty. What about all other members belonging to the federated network who are not Abel's buddies? Andy Zmolek points out this scenario in one of his blog posts.

This can be ensured only after extensive testing, leading to a time consuming routine before two networks can federate. But this is counter to the objectives Unified Communications and Collaboration (UCC) of which Presence is a component.

Given these issues, I wonder why Push system is still being used. I have raised this point with a few people. The consistent response is Push is considered to be an efficient way of distributing seldom changing Presence info; otherwise all the clients will be polling all of their buddies' Presence info, overloading all the servers. This is true only because they have fixed a specific use case scenario where the user is able to ascertain the Presence info of all of their buddies with a single glance. For this small convenience, we are paying a huge price.

But there is an alternative that addresses the concerns described earlier with a small change to the user interface. The alternative is for Betty to query Abel's Presence server whenever she needs that information. Since Abel's server will log all such requests, Betty will be discouraged from stalking Abel, except when she is desperately trying to contact Abel.

Federation is not a big problem anymore since the server belonging to the federating network is not involved in this transaction. Of course Betty and Charles can exchange and compare the information they received. But that happens in real life as well. We as social beings have developed social norms to handle such situations.

Finally if the User clients have a simple mechanism for a user to query Presence information of a single or a group of buddy, then this would be an acceptable compromise for other benefits. But there is one technical issue. Since Betty will be querying Abel's server, it must be able to authenticate Betty. Here my suggestion is to use OpenID/OAuth. By the way this is how EnThinnai serves Presence information of its users.

Pulling of a user's Presence information can be further enhanced by allowing for Betty to subscribe to Abel's Presence information. For example Betty would like to be informed when Abel's Presence info changes or it contains a specific string and the like. Of course such a subscription needs to be approved by Abel before the updated information is delivered to Betty. Of course this mirrors what happens in real life interactions.

In summary, we should not push a user's Presence information, but instead buddies must be allowed to pull after they are properly authenticated. Servers should also accept subscription requests which will be responded to after the user has given permission. Finally, the server should log all requests and make it available to the user.

Posted by aswath at May 25, 2010 04:55 PM
Related Posts Widget for Blogs by LinkWithin
If you do not have an OpenID, then please use www.enthinnai.com/unauopenid/anyblog.

 

Comments



Copyright © 2003-2014 Moca Educational Products.