Personal Zones: identity, devices and social proximity
Personal Zones: identity, devices and social proximityWe increasingly own more and more personal devices, for example, mobile phones, tablet computers, netbooks, laptops, TVs, and cars. We want to be able to access applications that work across these devices, as well as with our friend's devices. Distributed Web technologies are being developed to make this into a seamless, stress free experience.
Before diving into the technical details, let us first take a look at a practical use case. Sue is visiting her friend Bill's house, and is keen to share with him a movie, which another of her friends, Janet has just sent her a message with an enthusiastic recommendation and a pointer to a review. Sue is looking at Janet's message on her smart phone, and now wants to start playing the movie on Bob's surround sound big screen entertainment system in his den. Sue clicks on the share button in the web application and selects "find local devices" from the pop-up menu. She see's Bob's home entertainment system and selects it. A confirmation message appears on Bob's big screen, and he clicks ok on his remote controller. The movie starts and Sue sits down and moves closer to Bob, the lights fade as the music starts, ...
How does this work, and what is the connection to the federated social web?
The "find local devices" menu item invokes discovery protocols over available local interconnect technologies. Over WiFi, these include multicast DNS, the Simple Service Discovery Protocol (SSDP) for UPnP devices, and the Service Location Protcol (SLP). Sue's phone also features Bluetooth, which includes its own discovery protocol. What is new is the means for web applications to invoke these local discovery protocols.
The discovery protocols are blind to where devices are, and what social relationships that they take part in. The Bluetooth library, for instance, might find the next door neighbor's devices as well as those belonging to Bob. Some protocols like Bluetooth and multicast DNS allow you to assign human meaningful names to devices as a work around. The network itself can scope search, e.g. the SSID for a WiFi network. Together this is good enough. However, Bob, will want to check that the request comes from Sue's phone and not an evil hacker.
One solution is for Bob to authenticate Sue's request on the basis that Sue is in Bob's social graph. To understand how this is done, we first need to look at the concept of a "personal zone".
A personal zone is an administrative zone that encompasses your personal devices and cloud based services. The zone supports synchronization and a single sign-on mechanism. This reduces an N times N peering problem to linear authentication, where each device authenticates itself to the zone. To allow your apps to communicate across Firewalls and Network Address Translation (NAT) boundaries, there is a cloud based social agent that facilitates establishing connections. The social agent also acts a proxy on your behalf, exposing your social graph, and your personalized services to those with the appropriate authorization. You can purchase and install third party apps for use in your personal zone. This includes apps you run on your devices, and services run by your social agent and exposed to others.
As a friend of Bob, Sue can access information about Bob's devices (at least the one's he chooses to allow this for). This enables Sue's devices to communicate with Bob's even in the absence of a shared local network connection. This also opens the way for context based discovery, e.g. finding devices near me, based upon my current location, and social proximity, as determined from metadata exposed to Sue, by Bob's social agent. Returning to the current example, the app on Sue's phone can make use of the social graph in her personal zone to authenticate the request to the app running on Bob's TV.
Sue gets an email from an old friend Anabela and decides to add Anabela to her social graph. Sue find's Anabela's social agent based upon Anabela's email address, using either Web Finger, or DNS-SD. This takes the domain name for the email address and performs a lookup, either by mapping it to a URL with a well known path, or by retrieving the DNS TEXT record and looking for an entry giving the URL for the search service operated by Anabela's email provider. This maps the email address to the URL for Anabela's social agent.
At the same time Sue thinks of another old friend Henrietta. Sue doesn't know Henrietta's email address, and instead makes use of the distributed social search service, provided collectively by the Web of social agents. This could be based on Distributed Hash Tables (DHTs). The challenge is to allow for search based upon matching context, and to preserve privacy whilst doing so. For example, there could be many Henriettas, but the one that went to the same school in the same year is much more likely to be relevant. The search service should be able to perform ranking based upon social cues, without allowing users to invade other people's privacy.
Webinos is a European research project working on developing an open source platform for Web applications spanning devices such as mobile, desktop, home media (TV) and in-car units. We are working on realizing the ideas described in this paper, and look forward to being able to demonstrate our progress at the Federated Social Web conference.
We increasingly own lots of devices and want to use apps that run on these and those of our friends. Personal zones provide a means to manage our devices and cloud based services. This includes a social agent that acts on our behalf to enable apps to be aware of social proximity, and the agents collectively, support distributed search ranked by social relevance. The EU Webinos research project is working on realizing this architecture as an open source platform.
See also slides from panel session Privacy on the Federated Social Web (FSWE agenda)