Presence: Better You Pull, For I ain’t Pushing it
May 25th, 2010 by Aswath
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.
Aswath, pulling definitely seems to be an attractive proposition. However, there are some problems even with this approach and taken to extreme may even defeat the purpose of presence services.
Consider the following scenario. I have some friends, who are not close enough for me to pull their location on a regular basis, but whom I would love to meet if they are in the vicinity. The traditional push approach could help me in this regards. The pull approach may limit the number of connections being established.
Pull definitely sounds better in terms of reducing the noise, but is not the perfect solution for the problem at hand. Presence/location based services still need to figure out how to make use of this information.
I have added subscription capability for situations like this. So in this case you would have subscribed that you be notified when they are in your locality. When this friend is in that locality, would be informed of this subscription and will decide to notify you or not depending on circumstances. Doesn’t this address your concern?
Aswath,
You are correct in the sense of push being a problem. Also consider the issue of mobile devices, where use of network resources is costly and also consumes battery a lot more than pull.
That said, pull brings with it an issue of having the most up to date information – as close to realtime as possible (i.e – it can’t be done with pull). And the fact that pull provides a user experience that is inferior – I open the buddy list and have to wait for my queries on status information to see the updated status.
I think Microsoft OCS is doing both – at least from the way it interacts with me:
* I have a buddy list, whose statuses gets pushed to me.
* When I search for other people in the directory, it pulls their status information, which takes a few seconds. I have to wait, but I get the status that I wanted to know.
Tsahi
Tsahi:
You are correct in the immediacy of pulled Presence information. But I submit that we don’t want to see the presence info of all our buddies when we open the buddy list. Most of the time, we are interested in the Presence info of a single person or a small group of buddies. I think this is a good compromise given the other concerns identified in the post.