Blogtalk 2008 – Privacy and Revocation two sides of the same coin – A new privacy model for the social web

I'm going to BlogTalk 2008 in Cork!

I am speaking at Blogtalk 2008 at the invitation of Dr John Breslin whose team does some pioneering work on the semantic web. This talk is the first of my ‘research/PhD’ talks – so dont heckle me if I make mistakes :) – however I am truly passionate about this topic and its taken me some time to come to the exact area I want to focus(My PhD is at ucl under the supervision of Dr Miguel Rio )

Overall I am interested in privacy and reputation systems. The specific area of work I am looking into is as follow(and is also the topic of my talk at Cork/Blogtalk conference). I am using Google opensocial APIs for this talk(and also a paper based on the same talk which will be submitted at this conference)

The topic is as follow

Privacy and revocation: two sides of the same coin – A new privacy model for the social web using a dual social networking and a network layer model

Conventional privacy models lean towards a closed, digital fortress. These can take many forms – linkedin introductions, signed applications, third party trust endorsers etc etc. However, these methods don’t fit the current open web ecosystem and more importantly a future web based ecosystem where there is a tendency to give up privacy especially by the younger generation.

Social networks are increasingly going to be the primary form of interface to the Web for many of us. For many teens, that’s already the case with facebook. Unlike the Open Web, the social network has some form of structure (profiles, messages etc etc). This structure can be used to create a model of ‘Innocent until proven guilty’ as opposed to the existing digital fortress ecosystem based on (‘guilty until proven innocent’)

In this session, we examine the proposition that – privacy and revocation go side by side i.e. ‘I will be open to contact but in return – I choose to exercise the right to terminate that contact instantly if I need to’ (maximum privilege and instant revocation). In other words, strengthen the revocation – not the moat bridge .. Let people cross freely at the moat but always have the revocation engine as a defence mechanism

We will take a social network (social graph) and also a network levelperspective(certificate revocation, Identity etc)

Admittedly, any revocation engine may not work in context of the whole web but it may well work within the context of a social networkcoupled with network layer functions like Identity, certificate management function. Already, the spam features of Gmail work in a similar way(except Google does the revocation implicitly on our behalf).

The same mechanism can work within the context of any social network – mobile, P2P etc. In fact, revocation models already exist in networks like Qualcomm – however note that I am speaking of revocation by the individual and not by the provider)

This talk examines the impact of revocation and revocation engines as a privacy and security mechanism within the social network. We use examples from Google Open Social APIs to implement the model of maximum privilege and instant revocation.


a) At a network level, revocation is concerned with certificate management and it’s implications

b) I will lay out some ideas – but I cannot cover all the aspects. So, any comments/feedback welcome since these ideas are being developed.

c) Google Open social APIs will be used to illustrate

d) Note that the locus of control rests with the user. I am advocating a model where the user has control(not an external provider like an Operator)

e) What can be revoked? – Both the application and the individual. To revoke applications – we need a lot more information about networks, application ids, application components, application wrappers etc

f) To revoke individuals – we need information about Identity, weak identity, certificates, their social network, degree of trust

g) Ultimately we need a page rank like algorithm(a trust matrix) along with a mechanism to revoke both applications and people. This spans many domains

h) I also intend to ultimately focus on P2P(peer live)

i) Other components like a learning system, PKI, Global incident handling (threat broadcast) are also a part of this concept

If you are interested in this topic, see books like this one

Trust, Complexity and Control: Confidence in a Convergent World (Hardcover) by Piotr Cofta (highly recommended) and / or email me at

ajit.jaokar at and meet me at Blogtalk

Mobile browser plugins: The browser as a platform la facebook platforms ..

Note: I changed the subject because the blog is emphasising Mobile browser plugins – which was not obvious from the previous heading

I have talked about browser plugins before in context of offline browsing. However, the concept of plugins could be an interesting idea in itself – independent of its use in offline browsing.

If browser plugins take off , then the browser becomes a platform much like the facebook platform. The analogy is not accurate of course since browser extensions are software extensions whereas facebook applications are extensions of the platform itself – which includes the software and the data i.e. people

Having said that, the idea of extending a browser could have some interesting implications – especially taking the idea of open source into the equation

If we take the vibrancy (and the irritability!) of facebook applications and extend that to browser extensions, then the act of extending browsers via plugins can have both positive and negative implications – for instance ..

a) People can create their own extensions – ideally very easily. Much like facebook apps

b) These extensions should installable at any time and by anyone(i.e. not determined at POS)

c) It should be possible to tell others what plugins you are already running(i.e. capability exchange much like what we see at WURFL)

d) Irritating applications should be removable(much like some facebook apps!)

e) It should be possible to ‘send’ extensions to others(again like facebook apps)

f) There should be a minimum set or configuration to start off with

g) The whole ecosystem should be open sourced – so that it takes off faster.

h) The plug-in interface should be defined separating the interface from the implementation

i) Testing and certification should also be decentralised i.e. not controlled as a revenue model – else things wont take off fast because developers wont have any incentive to work with it commercially

I am aware that as I mentioned in my previous blog, the missing link is access to device APIs from the browser – and by extension the security implications of the same i.e. merely having the ability to add these plugins on mobile browsers may have limited usage if the plug-in itself can do little .. But it’s a good start? No?