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

LBS : Could the 5o9inc approach be a solution to the privacy problem for location based services?

If you read my books, I have been sceptical of ‘Location’. In fact, I remember starting a talk with a slide called ‘Location, Location, Location?’. The ‘?’ is not a typo. It’s to say – ‘Where is Location?’(Considering all the hype around it!)

Location based services(LBS) are one of the most useful and intuitive mobile applications. Everybody understands ‘Find my nearest’ and everyone agrees that it is useful to know your nearest restaurant/gas station/ATM etc when on the move.

Understandably, LBS apps have been hyped almost from the very beginning and regrettably, location based services are still(largely) not here with us as mass market applications.

The main inhibitor to LBS is privacy and security.

In the context of LBS, privacy and security has many facets – for instance statutory and legal, working with trusted third parties, encryption of security information etc.

Due to my interest with LBS, I have been having long discussions with Peter Cranstone CEO of 5o9inc – who has been outlining me their product.

I am now fairly convinced that it fulfils a gap within the LBS value chain.I outline their solution(as I understand it) below and I seek your thoughts and feedback.

Leaving aside the legal issues for the moment(which are being addressed by the relevant regulatory body in each country – for instance – laws about protecting minors), there is still the problem of protecting the location information especially in the context of GPS(which is now driving LBS services) : for instance phones like the Nokia N95 now have inbuilt GPS

The problem 5o9inc is addressing is: how to keep the location information(and for that matter any other private data elements) secure between the phone (where that information resides) and the web server(where that information is typically processed).

This is a very real problem which we will hit as GPS and other location based solutions become mainstream

Peter is an expert at security/encryption based applications, having co invented co-invented mod_gzip(in fact, I think the approach they have taken below mirrors the mod_zip approach but in the wireless context)

The solution could work in a number of scenarios:

a) Consumer: between the device and the web server

b) Enterprise with a mobile work force and

c) The Enterprise with mobile customers hitting their web site (search, retail, ecommerce etc).

It works as follows: The client’s data is held in an encrypted database on the mobile device. Every “field of data” that he/she wishes to transmit to the content provider remains under their control. The client side app allows the user to check or un-check the data field that gets transmitted. For instance they can share name, address, phone number, email address and current real time GPS location. If they wish not to share the GPS location simply disable the field. When the data leaves the mobile device and 5o9 applies encryption to protect it during transit. It’s transparent to routers, firewalls, Carrier portals etc. The data then shows up at the web server. It’s unencrypted and then is available for back office applications.


Thus, it functions like a tollgate between the device and the web server.

Physically, the application is a mobile browser plug-in and a web server module

I can see applications for this service both at the enterprise and the consumer level.

For consumer uptake, it is designed to work with parties like device manufacturers, browser vendors or Operators because it does not change the underlying infrastructure (again mirroring the approach they took with mod_gzip).

Thus, it appears to solve a very real problem taking a relatively pain free approach (i.e. not changing the underlying architecture).

Seek your views and feedback on this approach?