Friday, July 4, 2008

My representation in remote systems, the present

Warning: rant ahead....


I, the one represented, allow you, the receiver of information about me, needed to fulfill a service for me, to acquire and store indefinitely, some attributes describing me as an individual, in the hope you will record them accurately and use them solely for the purpose as intended in our agreed initial context.

From there on, I have no control over the system you use to store these records, describing me. Any subsequent change which I wish to effect (an act of self expression, creating my self representation) can only be realized with your consent. Any error or conscious mis-representation is not noticed by me directly. You can alter data representing me at will, thereby doing dishonor to my intentions, without me even knowing it happened. I am not consulted or notified if such change should occur.

I am powerless to express myself unless my intentions are reflected in your records. Once acquired, you value the recorded version, supposed to be representing me, above my subsequent direct communication of my intentions (as in, 'no sir, our computer says here bla bla bla'), even though I should be considered the ultimate authority in describing myself.

Even when it were entirely feasible and economical to consult me each and every time you need to acquire some information of me, you prefer to use the version in your system as it was recorded once in the past. That may be out of date, or not reflecting my current intentions in some way, but you don't really care. You don't verify or check at regular intervals with me. I can try and fix your records (which, for you, are the truth about me, but for me, they are not), but you might not let me, or you are incapable because of "call-center issues".

To make things worse, I have this issue with 200 different organizations, each treating me the same way as you did above, thus leaving me practically powerless to express my intentions across them all. (even a single one is hard, let alone 200). Such is the way I am reflected in society, through the eyes of the many organizations that deal with me: Disparate views, often not consistent, and not governed by my intentions. I am most incapable of expressing my desired representation in a consistent manner, such that it reflects the way I wish to be known. Where is the justice in that?

Oh and by the way, could you take more care with my data?

Sunday, May 4, 2008

On the OpenID attribute exchange protocol

OpenIDImage via WikipediaThe process for new attribute creation (a 5 point list, proposed by D. Hardt) is broken. It assumes central control (or at least some barrier for me) over what can be postulated about me. My position on this is explained in The Profile Problem.

I would rather not see the openID initiative which is applauded for its decentralizing effects on Identity, become a centralized point for attribute definitions.

Luckily, (apart from the openID attribute namespace) anyone can define attributes as they see fit. But when everyone starts defining attributes, how do we make sure this still results in a usable system of exchange (where usable means no centralization of any kind is needed to take off).

Off course the openID namespace attributes will mostly be identifying attributes, which are attributes whose values are supposed to be unique for one person. However the non-identifying remainder of the set all possible attributes is much larger and possibly much more interesting in the lives of most people. So this is where most of the action will take place, between common folk.

Let's suppose that everyone gets his own namespace (or comparable mechanism) for creating whatever attributes to describe him or her self; This way, no central authority on 'official attributes' stands in the way of full self expression of the individuals describing themselves.

In order to exchange attributes meaningfully, the two parties must agree on the semantics (they must agree that the attributes, although maybe called differently by both parties, actually are one and the same thing). But if attributes can be dreamed up by anyone, how do we do that?

Basically there are two options. The first is that both parties decide that their attributes to be exchanged both conform to an externally known (official) attribute definition. The other option is to create an ad-hoc attribute just for the pairing of the two personally defined attributes, and use that as the underlying definition to agree upon. A new attribute definition will be instantiated, specifically for this one-on-one mapping. Both parties designate their attributes to be one of that kind.

It would not be unreasonable to expect well defined attribute collections for general use to
appear soon. If both parties designate their (personally defined) attributes as a known external uri, semantic matching is automatic. If not, human intervention is needed to decide, but that's nothing too dramatic. A simple instant message "Hey, your sending me this http://..../foobar property, it has value 14. What is it?" If an understanding is reached, both parties will have semantic agreement, and both attributes will be defined as being of a (newly created) special attribute which is defined purely for this one-on-one purpose.

The key point here is that all attributes that I create are in my private namespace, and that semantic matching occurs on a different layer, between each of the 2 identities involved.

In the end, each person would still have his own idiosyncratic world view defined by the attributes he makes up. These describe himself as well as other people he knows. Hidden from view are the mappings based on semantic agreements (the underlying attributes) via well known or ad-hoc attributes.

The result is decentralized attribute collections (they are personal, but allow for consensus via intermediate maps or via plain old human consensus).

Let's fast forward from here.

I can imagine that certain groups of people (say, project team members) might want to share some pretty interesting attribute sets, which are not 'standard' by any other means. The support of this kind of creativity is essential.

Quick creation of special-purpose attribute sets, and proposing those sets to others is where protocol thought should be focussed now. If I can quickly create, send out, and receive values of, self-defined attribute sets, all in a fully decentralized way, then we finally have a reason to ditch Lotus Notes forever (for which I should win the Nobel Peace Prize).

Friday, May 2, 2008

How (not) to make friends

Social Networks world wideImage by Chewbacka via FlickrRegarding the social web and linking of 'friends', the currently available implementations such as Facebook etc. take the following approach:

First you identify who is your 'friend' (within the same network or application), this in turn determines which attributes they are allowed to see. Other classes of relationships like 'acquaintance', 'co-worker' 'school-mate' 'best friend' are now being proposed on the Data Portability forums to manage this.

This not only smells like bad design, but it appears to me to be an inversion of what happens in reality.

It is not the appointing of a 'friend' class to someone which determines who can see which of your attributes. It's the other way around: by allowing different identities to see different subsets of your attributes (gradually and over time), you define your relationship with these other identities. In other words, someone might become a friend after you decide he may see some of your attributes.

You don't have to decide on the relationship type upfront if you could granularly disclose attributes to various other identities (and maybe have the favor returned to you).

Off course people don't want to be bothered continuously with such fine-grained control over their individual attributes. As usual, software programs can ease the burden and help with common tasks.

Not many people currently craft their HTML documents and HTTP requests by hand to publish or read on the world-wide web. Still, inter-operability of all the different software is possible, thanks to the underlying standards. Sadly, we don't have these for identities and their attributes yet.

Thursday, May 1, 2008

Notification for feed consumers

The rss feed for this site has been changed to http://feeds.feedburner.com/egosphere.

Please update your rss clients.

Tuesday, February 12, 2008

Information sink vs information source

How Sticky Is Membership on Facebook? Just Try Breaking Free - New York Times

Another example of how most applications act like information sinks. It's easy to enter your information (data about you), but once you do, you lose control. The Facebook application (like almost any other online application) is an information sink.
Image via http://images.macworld.com
To me it seems the only approach to preserve control over your data is to leave those applications alone. That's why I'm not on Myspace, Facebook or others (Linkedin being the exception, for some reason).

Ideally, I would like to have the ability to create an information source, totally under my control, in which I design and edit my profile. A generic protocol for addressing and disclosure would then allow other applications and people to use this information source for many different applications (which would then basically become views on my data, and that of others in the aggregate).

What do you think?

Tuesday, February 5, 2008

DataPortability and the Web Worker

One of my favorite blogs, Web Worker Daily, struck a nerve when posting about the DataPortability initiative. I couldn't resist to comment.

Friday, January 11, 2008

DataPortability - bad name for a real problem

Image: (c) corbis
It's about you

The recurring theme in social web data is that the data concerned is about an individual (ie. you). Anything that describes (a part of) you or your actions or preferences or you name it, qualifies to be part of your 'profile'. It doesn't matter if you typed it in yourself, or if it is generated by some system. (As long as something pertains to you, represents you, it should be under your control. I'm taking an extremely user- or identity-centric approach here).

Currently almost any data describing you is not under your control. See The Profile Problem of which the Scoble vs Facebook case is an example (not the latest, methinks).

Let me be clear: I totally agree with the problems that DataPortability tries to solve. Only the name of the project is misleading to say the least.

The name Data Portability (and some of the things I've read on their website and forum) gives me the feeling that they want to be able to extract and import 'user data' from and into various existing social-web applications, just like Scoble did. That's a nice problem to solve, but it all depends on what level of abstraction the standards are formulated.

Let's do a thought experiment, Imagine a less-than-world-wide web where pre-existing publication platforms were hosting content, each in its own proprietary way. At some point the need for inter-operability (linking) and re-usability of this content becomes apparent.

Thanks to Tim Berners-Lee, and lucky for us, we don't have this situation on the current world-wide (webpage) web. We're not porting documents from one web-server implementation to the other, and we don't need or want standards to do so. Instead we have the HTML standard for the document format, the HTTP protocol for accessing and creation, and the URL for addressing.

These are key components. But on the social web, we do have this situation.

The problem isn't then that we can't port or migrate data (we really shouldn't be wanting to go that way), the problem lies deeper in that there aren't any standards for representing, addressing and manipulating this type of content.

Similar to the standards that make the world-wide web so successful, I sincerely hope that the DataPorters want to come up with a similar addressing standard for identities and for individual attributes. Already OpenID covers the part of the solution.

Once identities and specific attributes are uniquely addressable, data at these addresses should be in a standard document format (like HTML documents which resides at url addresses, 'attribute documents' should reside at attribute-url's). I would like to have an addressable document in a standard document format for each of the attributes that are part of my self-representation. (Unlike web-pages, these attribute-documents shouldn't be automatically world-readable, the documents themselves should include disclosure settings, and part of the access protocol should be the decision to disclose or not, depending on the 'requesting party'.)

It follows then that we also need a protocol for sending messages to create, retrieve, update, remove and share (disclose) these attribute-documents (defined by their unique addresses); HTTP does this for viewable documents and we should have something similar for identity-centric attribute documents.

Once the standards are there at the right level of abstraction (the attribute level imho), the rest is easy. You could implement a Facebook in no time, and it would be inter-operable with any other such system (no need to shovel data to and fro).

Conclusion

It seems to me that trying to make current proprietary social-web applications inter-operable after the fact, by devising a standard at the application level, is a waste of effort. Too bad we have existing applications without standards, but this still leaves us with the need for low-level standards for the identity-attribute domain. Once we have that, data portability is a non-issue.

Thursday, January 10, 2008

The Profile Problem

Ama-gi written in Sumerian cuneiformImage via WikipediaProfiles are used extensively on the web and in the enterprise. With the rise of 'the social web', the number of profiles you can use to describe (parts of) yourself is greatly increased.

On the web, each site or service needs to know something about you. This is your profile (for that site or service). In an enterprise setting, a company keeps a profile about all their employees or customers (i.e. you) in their identity management system.

When seen from a perspective of personal freedom, the current practices pose a few problems, which will be discussed next.

Problem 1: You don't have control over the data that describes you.

This is the most important problem. Apart from the specific elements you are allowed to store (see Problem 2), the data you entered is stored on a system beyond your control. It might be difficult to make changes, or to correct errors. You might be dependent on the service provider or others to have your data changed or deleted. You don't control the security that surrounds your data. You can't choose the systems on which your data is kept. You're not allowed to re-use your own self-representation.

Problem 2: Profiles dictate what you can and cannot tell about yourself.

Most online services and enterprise identity systems come with a prescribed set of properties (like your name, favorite music etc.) that you need to populate with values concerning yourself. The profile dictates what is required and what is optional. There is often no room for extra information.

Problem 3: Lack of sharing control.

You often don't control who sees the profile, and, in cases where sharing is relevant, you can't control the parts to disclose in enough detail.

On the web, you are stuck with the options the site or service offers you for sharing with other users (as is common in many online community services). Can you share all, nothing, or parts of your profile? Which parts?

Problem 4: Duplication of effort.

This is not really a problem related to individual freedom, but it is worth mentioning anyway.

Each service has its own profile page for you to fill out. This is a duplication of effort for you, since you have to maintain the same set of properties over and over again at each site. It also is a duplication of effort on the part of all the service providers, who build and maintain a profile infrastructure, user interfaces and the data it holds.

Admitted, the enterprise identity management system solves the duplication of effort problem by using an enterprise-wide profile management system, so the duplication of effort is mainly seen on the web, not inside the enterprise. However, the first two problems remain. Do you have any more influence over your profile (say, as a customer or employee), now that it rests in an enterprise identity system?


What needs to be done?

Nowadays, with the proliferation on-line services an social media, the need for a solution for these problems is needed more than ever. The challenge lies in identifying what an acceptable solution looks like.

We should take a step back from technical issues, and investigate the essence of self-representation, since a profile for an on-line service is just that. Taking the person being represented as the starting point, issues of personal freedom, privacy and control become relevant.

In any case, to prevent the problems identified above, the proposed solution should minimally have the following characteristics:

It should work with arbitrary attribute collections. It should allow for fine-grained disclosure (sharing) options under the users control. The data should be stored with a provider/technology of choice.

Starting from there, one can see the need for standards which allow an individual to manage the the definition, modification, querying, and disclosure of personal attributes.

Monday, January 7, 2008

The Rise of Networked Individualism

In The Social Affordances of the Internet for Networked Individualism, a very interesting analysis is done of the shift from a group-centered towards a person-to-person society. See especially the chapter The Rise of Networked Individualism.

Attention Profiling: APML

Attention Profiling: APML Beginner's Guide - Robin Good's Latest News

The APML standard proposes a unified format for capturing a persons interests. The main idea is to keep the user in control of his data (good). It focuses on certain types of data, mainly those that describe a users preferences and interests. One of the goals is to make recommendations and filtering easier and to prevent information overload.

I would say the user-in-control approach is very good, but why limit to certain kinds of data? Do we really need a standard format for each domain or application? My point of view would be to create a standard at a more general level. It should be generic enough to let the person describe himself however he/she wants (see The Profile Problem) and for describing detailed disclosure policies. I will elaborate in another article.

Data portability

Recently I came across the data portability concept. Finally, it seems that the idea is gaining hold that you should be the owner of the data that describes you. Not Facebook or any other organization which tools you use.

This article covers some of the issues: Are You Paying Attention?: Top 3 Privacy issues for Data Portability on Social Networks

Now to argue one step further, I think you should not only be the owner of the data describing you, but also the designer.
Creative Commons LicenseExcept where otherwise noted, content on this site is licensed under a Creative Commons Attribution 3.0 License