The term “ownership” simply brings too much baggage from the physical world, suggesting a win-lose, us-verses-them mentality that retards the development of rich, powerful services based on shared information.

Anyone up for sacred cow cheeseburgers?

I’m a member–and a big fan–of Steve Holcombe’s “Data Ownership in the Cloud” LinkedIn group and I love the efforts of the Dataportability guys and am a big supporter of the Privacy and Public Policy work group at Kantara. There is a lot of good work being done by folks trying to figure out how to give people greater control over the use of data about them (privacy) and gain access to data they use or created (dataportability).

Unfortunately, sometimes the arguments behind these efforts are based on who owns–or who should own–the data. This is not just an intellectual debate or political rallying call, it often undermines our common efforts to build a better system.

Consider this:

1. Privacy as secrecy is dead
2. Data sharing is data copying
3. Transaction data has dual ownership
4. Yours, mine, & ours: Reality is complicated
5. Taking back ownership is confrontational

Privacy as secrecy is dead

First, the data is pretty much already out there. The issue isn’t “How do we keep data from bad people,” it’s “How do we keep people from doing bad things with data?” DRM and crypto and related technology as the sole means to prevent data leakage and data abuse are failures. Sooner or later, the bad guys break the system and get the data.  Sure, there are smart things we can do to protect ourselves. Just like we wear seatbelts and lock our front doors, we should also use SSL and multi-factor authentication, but we can’t count on technology to keep our secrets. We need solutions that work even when the secret is out.

In fact, privacy isn’t about information we keep secret. It is about information we have revealed to someone else with expectation of discretion, e.g., when we tell our doctor about our sexual activities. It’s no longer a secret from the Doctor, but because it is private, we have rules that keep the information from being used inappropriately. Most of the time, with most doctors, it works. Those few who break those rules are dealt with through legal means, both civil and criminal, as well as social approbation. So, because we inherently need to release data to different parties at different times, we can’t control it through secrecy alone. Instead, we need to build a framework for preventing abuse when others do have access to sensitive information. Like in the case with our doctor, we want our service providers to have the data they need to provide the highest quality services.

Data sharing is data copying

Second, in the world of atoms, there can only be one of a thing, which is the reverse of the world of bits. With atoms, even if there are copies, each copy is itself a singular thing. Selling, transferring, or stealing a thing precludes the original owner from continuing to use it.

This isn’t true for information, which can easily be sold, transfered, and stolen without disturbing the original version. In fact, the entire Internet is basically a copy machine, copying IP packets from router to router, as we “send” images, web pages, and emails from user to user and machine to machine–each time a new copy is created whether or not the originating copy is deleted. To think of bits as if they were ownable property leads to attempted solutions like DRM that try to technologically prevent access to the information within the data, which is only good until the first hacker cracks the code and distributes it themselves. Instead, if we build social and legal controls on use, we can give information more freely, but under terms set by each individual when they share that information. Enforced by social and legal rather than purely technological means, this makes the most of the low marginal cost of distributing  online, while retaining control for contributors.

Transaction data has dual ownership

Image via Wikipedia

Third, much interesting data is actually mutually owned… which means the other guy can already do whatever the heck they want with it.  Consider web attention data, the stream of digital crumbs representing the websites we’ve visited and any interactions at each: all our purchases, all our blog posts, all our searches. Everything. Some folks argue that we own that data and therefore have the right to control the use of it. But so too do the owners of the websites we’ve been visiting. We don’t own our http log entries at Amazon. Amazon does. In fact, in every instance where two parties interact, where we engage in some transaction with someone else, both parties are co-creating that information. As such, both parties own it. So, if we tie the issue of control to ownership, then we’ve already lost the battle, because every service provider has solid claims to ownership over the information stored in their log files, just as we, as individuals, own the browsing history stored on our hard drive by Firefox, Internet Explorer and Chrome.

In the movie Fast Times at Ridgemont High, in a confrontation with Mr. Hand, Spicoli argues “If I’m here and you’re here, doesn’t that make it our time?”  Just like the time shared between Spicoli and Mr. Hand, the information created by visiting a website is co-created and co-owned by both the visitor and the website.  Every single interaction between two endpoints on the web generates at least two owners of the underlying data.

This is not a minor issue. The courts have already ruled that if an email is stored for any period of time on a server, the owner of that server has a right to read the email.  So, when “my” email is out there at Gmail or AOL or on our company’s servers, know that it is also, legally, factually, and functionally, already their data.

Yours, mine, & ours: Reality is complicated

Fourth, when two parties come together for any reason, each brings their own data to the exchange. We need a framework that can handle that. Iain Henderson breaks down this complexity in a blog post about your data, my data, and our data, talking about an individual doing business with a vendor, for example, someone buying a car.

“My data” means data that I, as an individual have that is related to the transaction. It could include the kind of car I’m looking for, my budget, and estimates of my spouse’s requirements to approve of a new purchase.

“Your data” means data that the car dealer knows, including the actual cost of the vehicle, the number of units in inventory, the pace of sales, current buzz from other dealers.

“Our Data” means information that both parties have in common. That could be Shared Information, explicitly given by one party to the other in the course of the deal, such as a social security number so the dealer could run a credit check. It could be Mutual Information, generated by the very act of the transaction, such as the final sale price of the vehicle. Or, it could be Overlapping Information, which each party happens to know independently, such as the Manufacturer Suggested Retail Price (MSRP) of a vehicle (which we found online before heading to the dealership).

The ownership of “your” and “my” data is usually clear. However, ownership of the different types of “our” data is a challenge at best.  To complicate matters further, every instance of “my data” is somebody else’s “your data”. In every case, there is this mutually reciprocal relationship between us and them. In the VRM case, we usually think of the individual as owning “my data” and the vendor as owning “your data”, but for the vendor, the reverse is true: to them their data is “my data” and the individual’s data is “your data”. Similar dynamics occur when the other party is an individual. I bring my data, you bring your data, and together we’ll engage with “our” data. We need an approach that respects and applies to everyone’s data, you, me, them, everybody.

In these complex Venn diagrams of ownership, it is more important who controls the data than who owns it.  We’ve already lost the crudest form of control–secrecy–and we are going to continue to lose more as we opt-in to seductive new services based on divulging more and more information: our purchase history, browsing activity, and real-world location data. But we still need to control how all this data is used, to protect our own interests while still enjoying the benefits of the great big copy machine that is the Internet.

Taking back ownership is confrontational

© Regien Paassen | Dreamstime.com

Fifth, we don’t need to pick a fight to change the game. There is a lot of data out there that many of us believe we should have control over. I agree. A lot of people argue that we should have the right to exclude other people’s use because we own the data, because it’s ours in some legal, moral, or ethical framework. The problem is, those other people already have it, and they also believe that they are legitimate owners. In fact, many of them paid for that data, buying it from data aggregators who compile all sorts of things about people, from both public and private sources. This entire ecosystem of customer data is a multi-billion dollar business and every single player “owns” the data they are working with. So if we focus our energy in claiming ownership over that same data in order to take control, we are framing the conversation as a fight, a fight against a powerful, well-healed, well-funded, entrenched bunch of opponents.

Most of these “opponents” are the very people we are trying to win over to our way of thinking. These are the vendors we want to embrace a new way to do business. These are the technologists we want to transform their proven, value-generating CRM systems to work with our data on our terms, instead of their data on their terms. Arguing over ownership puts these potential allies on the defensive, when what we really want is their collaboration.

From Ownership to Authority, Rights, and Responsibilities

Rather than building a regime based on data ownership, I believe we would be better served by building one based on authority, rights, and responsibilities. That is, based on Information Sharing.

• Who has the authority to control access and use of particular information?
• What rights does a party have in using and distributing a piece of information?
• What responsibilities does an information user have to others with respect to that information?

Let’s stop arguing about who owns what and start figuring out how we can share information in ways that allow everyone to win.

When we collect all of our information into a single conceptual repository, and then share access to it with service providers on our own terms, we create a high quality, highly relevant, curated personal datastore. This allows us to bootstrap a control regime over all of our data in a way that creates new value for us and for our service providers. Now, instead of iTunes Genius or a Last.FM scrobbler only having access to our media use with their service, they can provide recommendations based on all the information stored in our personal audio datastore. We get better recommendations and they get better data to drive their services. This personal datastore is entirely under the authority of the user, sharing information with service providers according to specific rights and responsibilities.

The Information Sharing approach neatly sidesteps the complexities involved in privacy and dataportability issues of the information already known by service providers. These remain serious issues, worth addressing. Resolving them will require long term investment in the legal, regulatory, moral, and political systems that govern our society. Fortunately, sharing the information in our personal datastore can begin almost immediately once we have working specifications.

This controlled sharing of information will dramatically increase our comfort level when revealing our intentions and interests. We would have control over the use–and would be able to prevent abuse–of that information, while making it easy for service providers to improve our lives in countless ways.

At the Information Sharing Work Group at the Kantara Initiative, Iain Henderson and I are leading a conversation to create a framework for sharing information with service providers, online and off. We are coordinating with folks involved in privacy and dataportability and distinguish our effort by focusing on new information, information created for the purposes of sharing with others to enable a better service experience. Our goal is to create the technical and legal framework for Information Sharing that both protects the individual and enables new services built on previously unshared and unsharable information. In short, we are setting aside the questions of data ownership and focusing on the means for individuals to control that magical, digital pixie dust we sprinkle across every website we visit.

Image by hegarty_david via Flickr

Because the fact is, we want to share information. We want Google to know what we are searching for. We want Orbitz to know where we want to fly. We want Cars.com to know the kind of car we are looking for.

We just don’t want that information to be abused. We don’t want to be spammed, telemarketed, and adverblasted to death. We don’t want companies stockpiling vast data warehouses of personal information outside of our control. We don’t want to be exploited by corporations leveraging asymmetric power to force us to divulge and relinquish control over our addresses, dates of birth, and the names of our friends and family.

What we want is to share our information, on our terms. We want to protect our interests and enable service providers to do truly amazing things for us and on our behalf. This is the promise of the digital age: fabulous new services, under the guidance and control of each of us, individually.

And that is precisely what Information Sharing work group at Kantara is enabling.

The work is a continuation of several years of collaboration with Doc Searls and others at ProjectVRM. We’re building on the principles and conversations of Vendor Relationship Management and User Driven Services to create an industry standard for a legal and technical solution to individually-driven Information Sharing.

Our work group, like all Kantara work groups, is open to all contributors–and non-contributing participants–at no cost.  I invite everyone interested in helping create a user-driven world to join us.

It should be an exciting future.

This material is based upon work supported by the National Science Foundation under Award Number IIP-08488990. Any opinions, findings, and conclusions or recommendations expressed in this publication are those of the author and do not necessarily reflect the views of the National Science Foundation.

From cable TV to YouTube, from newspapers to blogs, from Wal-Mart to eBay, from Ma Bell to the Internet, the shift from centralized, structured systems of authority to emergent, collaborations between individuals has been reshaping our political, social, and economic world for generations. This is a trend that has driven—and been driven by—the massive success of the Internet, email, the World Wide Web, eBay, Google, RSS, FaceBook, YouTube, and Twitter. Each of these examples took an existing model and made it more user driven: networking, messaging, electronic publishing, buying & selling, content discovery & advertising, news aggregation/syndication, online video, status updates.

The conclusion: companies which find ways to be more user driven are more valuable, more profitable, and more successful.

What does it mean to be “user driven”? At its most basic, it means putting the user in charge, in some way. Fully realized, it means putting the user at the center of the system, as a point of integration, origination, and control. We call these fully realized systems “User Driven Services”.

User Driven Services put users in charge. Users start each interaction, manage the flow of the experience, and control what and how data is captured, used and propagated.  Users are the cause and the controller, working with service providers to co-create collaborations that create value for all parties.

From self-serve gas stations and soda fountains to ATMs and self-checkout grocery stores, companies have been putting users in charge of different aspects of their services for years. With GetSatisfaction—which allows users to self-organize for cooperative customer support—and Facebook—which provides social context for user-generated content—users are not just self-servicing, they provide the core content behind the user experience. Now, through user-centric Identity and API access to most popular online services (Flickr, Twitter, Facebook, etc.), users can direct which parts of their experience are serviced by which providers, allowing unprecedented realtime flexibility in service creation.

User Driven Services are redefining how we interact, how we manage our businesses, and how we engage in both public and personal conversations. Businesses and organizations that want to thrive in this new reality would do well to help co-create a new mutually beneficial marketplace for products, services, and ideas. Individuals, participating in this rising tide of personal power, have an opportunity to coordinate with each other and with service providers to craft a future that meets all of our needs, as individuals, entrepreneurs and business people.

Terminology

A few key terms:

System: a group of independent but interrelated elements engineered to operate as a unified whole.

(The systems to which we refer are not natural or conceptual systems, but rather, operating mechanisms designed and implemented to perform intended functions.)

User: any individual interacting with a system.

Service: a value generating experience available to users through interactions with a system; also the system providing such experiences.

User Driven Services: services that maximize value creation by maximizing user control and authority.

Characteristics

User Driven Services have the following characteristics:

1. Impulse from the User
2. Control
3. Transparency
4. Data Portability
5. Service Endpoint Portability
6. Self Hosting
7. User Generativity
8. Improvability
9. Self-managed Identity
10. Duty of Care

We will explore each of these characteristics in a series of articles over the next few weeks.

No longer is it sufficient for companies to package a value proposition on their website and then drive traffic to it through ads, search engine optimization, and reciprocal links. Today companies must find ways to provide a value proposition wherever the user might be: on Facebook and Twitter, on their iPhones, and even through 3rd party applications accessing deep into the company’s datasphere through APIs and webhooks.

The Internet is reconfiguring around the user, wherever people happen to be.

I’ve been talking with folks in the VRM community about this topic over the last few years. VRM is, at its core, about starting with the user, re-engineering systems to maximize user freedom and control, and placing the user at the point of integration.  Or, as Doc Searls puts it, creating tools for “both independence and engagement”.

For example, I’ve led several discussions at various VRM workshops on what I call “user driven search“: what would happen if the user were truly in control of all the data related to their search and could engage any Search provider they like with the full scope of that information and under the user’s terms?

In the last several months, I have been advocating a new term has that captures the core direction of both VRM and User Driven Search: “User Driven Services”.

When you configure your services around the user as the primary point of origination, integration, and control, you are building User Driven Services.

Over the next few weeks, I’ll dive into what we mean by User Driven Services; consider it a warm up for both the VRM West Coast Workshop 2009 and the Internet Identity Workshop.

More …

• Teleconference 2008 06 18
• Teleconference 2008 07 02
• Teleconference 2008 08 13
• Teleconference 2008 09 24
• Teleconference 2008 10 08
• Face to Face 2008 October

The premise is simple: if users know they are safe giving personal data, they will give it more freely. Limits on long term data mining (and its attendant offensive behavior of junk mail, spam, and telemarketing) paradoxically increase data sharing and enhance the ability of vendors to provide more meaningful engagement at the moment of the transaction. Less long term data retention leads to more real-time data provided by users, resulting in better customer experiences, and more profit for vendors.

Until recently, this was a theoretical argument, a belief by those of us promoting VRM. As Doc Searls puts it, “A free customer is more valuable than a captive one.”

Now we have evidence of just how valuable that can be.

Jared Spool shares with us the real-world example of a redesign in the direction of the “One Night Stand” that created $300 million in value in the first year: [excerpt edited for brevity. see full article for details]

Now that’s real money.

Hat tip to Abhijit Nadgouda of iface thoughts.

I had heard a bit about this before and it sounded great… but there’s always such a drive to just start coding! Before I reach Carolyn Snyder’s excellent Paper Prototyping, I hadn’t realized what I was missing.

The key difference from what you might be thinking–and definitely what I was thinking–is that paper prototyping isn’t just about doing mockups of the UI and asking users for feedback. It means recreating the a subset of the core user experience using a paper-based model, with a human “computer” and the user interacting not with the facilitators or testers, but directly with the pieces of paper, by pointing for hovering, touching for clicking and writing for typing.

The results were amazing.

We took two weeks to develop & construct a paper prototype for our upcoming Search Map software, which is the first implementation of the SwitchBook approach to User-driven Search (which is the focus of our work with the VRM community). That was followed by one week doing the actual testing.

To build out a paper prototype like this you have to have a critically specific definition of what it is you are building. Depending on how early you are in the gestation of your software idea, this might be impossible. But if you have a pretty good idea of the basics, the paper prototype will force you to actually write down both

• a subset of tasks in sufficient detail for the user and the prototype to do with paper assets, and
• create the pieces of paper that represent every window, every menu, every dialog box, every state in the interface.

It felt like we went through three revisions of our core UI before we actually had any users. We found there were so many assumptions hidden in our initial requirements documentation that we were missing key parts of the user experience. And then, by mapping out those parts of the experience, we made significant leaps in simplifying and unifying the overall design.

Prior to the actual testing, we first did a dry run with a fellow associate as a user. This was eye opening. Not only did we identify a few assets we were missing, we realized we had several key assumptions that we had overlooked in our design. These assumptions led us to revise the paper prototype significantly, leading to an even better run through with the live testers.

This pattern repeated itself for everyuser. Snyder strongly suggested doing just a handful of tests, no more than two per day. So, 4-6 testers over two-three days. After two weeks building the prototype, I was thinking we should have more testers to really get the value out of this thing. But after the trial run, I realized that there is so much opportunity to update & improve between tests, that you want to immediately assimilate each session and update the prototype.

That is the real beauty of the paper prototype.  Because it is just paper… and in particular just sketches on paper–not a beautifully designed custom UI–it is trivial to change. We were evolving in leaps and bounds between every test, taking out portions of the interface, creating new icons, adding buttons here and removing them there, even updating dialog boxes in mid-test.

It would be hard to overstate how powerful it was to engage in such rapid evolution based on real user feedback. With ~3 revs in the construction phase, 1 with our trial run, and 4 more revisions from each test, I estimate a good 8 substantial revisions to our design in just three weeks.

Our timing for this exercise was just about perfect. We just started a 6 month dev cycle in January, after over a year of internal development (largely on the server side with a basic architectural prototype on the client). The core experiential basics had been fairly stable, and we were ready to integrate a lot of conceptual learning into a new rev. So, we had a lot of detail about what we wanted to do, and were in a good point to take a moment, document our requirements rigorously, and sit down with users to see what really works. For the record, we spent about three weeks in requirements engineering prior to working on the paper prototype (which was another three weeks of effort). I don’t know if I’ve ever spent a more useful 6 weeks in any programming project.

We also quickly saw the limitations of this approach. Of course, it was slow. We joked that the McKinney 5000 was operating at about 110hz. (Sam McKinney acted as our “human” computer for the testing–and did a great job I must say.) A good portion of our user experience depends on finding “flow” during advanced searches across many different websites and different search providers. Just keeping track of the user’s behavior was a breakneck task… simultaneously updating the screen to indicate the real-time feedback and recommendations from our server was even harder. The result is that although we got to test our core workspace, the technique was too slow to really test the work flow.

So, Carolyn Snyder, thanks so much for the easy and thorough guide to paper prototyping. It was an amazing exercise for our whole team. And for those of you who are working through the details with disruptively innovative software, I encourage you to try it. I think you too will be amazed at your results.

p.s.

My apologies that we didn’t get any pictures of the experience. We were so busy doing it, nobody stopped to capture the look & feel of the interactions.

Problem Domain

The distributed nature of the web is a big part of its power–nobody needs to ask permission from a central authority to use it or create with it. However, that disaggregation limits the cohesion for sophisticated uses, leaving users to hobble together ad-hoc mash-ups of value from multiple, diverse service providers.

For example, the average travel planner spends 29 days from their first query to their first purchase. No tool I know of facilitates that entire process effectively.

Solving this problem in a general way—while retaining the authority of the individual and the flexibility of open systems—is perhaps the greatest opportunity for VRM. The personal datastore and VRM relationship services are two prongs of an architectural shift for enabling this kind of aggregation while remaining open. Once you put the user in the driver’s seat, with coherent controls over the flow and the data, the experience can integrate around the user, even as they drive anywhere on the Internet.

Solution

Kynetx’s solution is built on one primary capability:

A rules engine (and language) for contextual customization based on strong identity-based claims, using the user-centric Identity of Information Cards.

This puts Kynetx squarely in the web augmentation service business. Adaptive Blue (and their Glue product) is perhaps the most sophisticated approach to this space, but Yahoo’s Toolbar also augments web pages, as does Skype (putting its SkypOut button on any phone # it recognizes), and the granddaddies of all web-augmentation services are the ad blocker plug-ins that remove banner ads on websites.

I distinguish web augmentation from web media enhancements, like PDF and Flash and Java, in that the latter are embeddable or downloadable extensions to the core HTML/http architecture of the web, while augmentation services provide third-party manipulation of website presentation on behalf of the user. They actually tweak the web page as the user sees it, rather than offering websites a new way to package content or functionality.

Web augmentation isn’t new, but it is gaining adoption and breadth. There is a low-grade market war going on in this space. While browsers define the official battleground of the World Wide Web; augmentation services are the guerilla warriors of next generation browsing. The approach that reaches ubiquity first will create significant value throughout the architecture: for users, software vendors, and service providers.

So, the question that comes to my mind is where does Kynetx fit into all of this?

The value proposition of a rules-engine for customization is powerful, if that engine makes it easy to leverage strong identity. Every website will, imo, want to take advantage of the unique value of user-centric identity and  Information Cards in particular. However, rewriting your customization to do that will take resources and that will slow adoption. If Kynetx can simplify how websites plug- in to the Identity meta-layer that sounds like a real value.

Gaps

There are however, several gaps that I see in Kynetix’s approach mapped out in the white paper.

First, who are the target developers: websites or Third party services. Or both?

It’s not clear to me if the primary authors of KRL rulesets (and hence Kynetx’s customers) will be the destination website developers or third party augmentation services. For example, . Adaptive Blue’s Glue augments web pages so that things like movies can be recognized across domains for social commentary, ratings, and sharing. That means that Glue modifies the presentation of web pages at IMDB, Netflix, Amazon, Blockbuster, etc. In this pattern, it is the third-party, Glue, that would be running KRL rulesets, not the websites.

Is this the intended architecture for Kynetx? Is the point of the Kynetx Information Card to provide authorization by the user to allow services like Glue to augment their web experience, while the rest of the plug- in handles injection into the web page within the browser?

Or, is the main point that web services themselves would leverage Kynetx’s Information Card approach to manage third party identity for customization? For example, so Hertz could seamlessly provide AAA or AARP discounts if, and only if, the appropriate AAA or AARP information cards (KIX) are presented by the user? In this case, Hertz writes the customization, but doesn’t need to know upfront what the user’s affiliations might be.

If the first case is intended, the white paper doesn’t do a good job explaining how this fits into a larger, open ecosystem, nor does it highlight this unique architectural opportunity. If a user wants Orbitz to help augment its travel planning experience, even when it is at Expedia or Southwest airlines or Hilton.com, it would be great to do that in a secure, authorized, privacy-sensitive way. But it isn’t quite clear if this is the point of Kynetx’s approach. (Although it is a great opportunity, one that r-buttons and SwitchBook see in the not-so-far future).

If the second case is the goal, it isn’t clear to me why Kynetx is better than other customization frameworks. With a card selector and cards issued from the right authority, users can already present AAA or AARP credentials to websites, which in turn can integrate that information into their existing CMS or other presentation code (Drupal, PHP, perl, Ruby-on-Rails, etc.). If the value proposition is in speed-to-market for identity-based customization, then the white paper needs to make that case first and foremost. If that’s the goal, then it also suggests a business model, which I talk about in a bit.

It could also be that both of these are part of the approach: allowing both the website developer and third parties augment the web experience based on strong identity. This is the general idea behind r-buttons and would almost certainly speed deployment. However, the white paper doesn’t address the issues of contention when multiple providers want to augment the same page. Given the open-ended javascript functionality associated with a KIX, this could be a challenge.

Second, isn’t re-aggregation actually about creating a coherent context?

While the Kynetx approach allows users to present a particular relationship at a particular website, that doesn’t seem to solve the stated problem. I don’t see how it actually achieves a cross-web aggregated experience. In fact, it seems that the best aggregated experience should combine many relationship cards at many different services. In the 29-day travel planning scenario, won’t users need to send their AAA and AARP cards to every site they visit? (Or some large subset?) Does the card selector require a ceremony for every website every session? Or just once and then it is a permanent approval, such as confirming once with Expedia that the user is a AAA member? Managing this A x B complexity with A Information Cards and B websites scales poorly if every site has a distinct ceremony–and even worse if each card presented at each site is a distinct ceremony.

This apparent model of KIX based aggregation seems to miss an opportunity, one that is near to my heart as the core of the Search Map architecture for User-driven Search. It seems to me that for a given web-based task–such as travel planning–what you need is a user-driven personal datastore that tracks the user’s progress across the Web. This datastore should be 100% transparent, 100% editable, and seamlessly transferable/accessible to authorized vendors under terms controled by the user. We call our version of this a Search Map, an electronic document that provides the user a concrete way to manage and express their Search intent. It is also a seamless way to manage and express user context.

In the white paper, Phil asserts that “users are freed from managing episode context themselves” as a core benefit. But, I don’t think this is actually a benefit. Attempting to achieve that goal could end up being more patronizing than useful, following in the footsteps of “Clippy” the Microsoft Windows help agent which tried to figure out the context and help users, but failed miserably. “I see you are writing a letter. Would you like assistance?” Ack!

It’s not that users don’t want to manage their context, it’s that they haven’t been given simple, value-producing tools to do so. Consider spreadsheets: it’s not that users want to balance the budget on a computer—doing budgets on a computer isn’t inherently rewarding. It’s that spreadsheets make it easy to get value out of balancing their budget on the computer. Managing KIX across 29 days of travel planning and potentially a hundred+ websites sounds like a chore… unless we have a coherent expression of the context (in something like a Search Map, perhaps) that is easy to use and immediately useful.

Third, over-centralization limits scale.

The Kynetx model, as I understand it, doesn’t scale to the full World Wide Web, because it centralizes two core functions: resolving requests for augmentation and the validation of injection javascript as safe, private, and secure. Both of these constrain the growth opportunity for a KRL-based approach to augmenting web services. First, it places the core usage-time server demand on a single service. Given the business model of charging for ruleset evaluations, there is no obvious incentive for Kynetx to release an open source reference implementation to make it easier for alternate KRE service providers. In fact, there is every expectation that Kynetx will be motivated to “win the market share” battle and be the primary KRE service. Which, unfortunately, makes it just another silo, and will face precisely the same sort of scaling issues that plague Twitter. Second, by making Kinetx the arbiter of “quality” it places a single entity in control ofwhat constitutes “safe”. Even with good intentions, such centralized moral authority is not just dangerous, it alienates potential innovation. Nobody wants to be forced to seek permission for their new functionality. That was, IMO, the primary reason the World Wide Web dominated AOL so quickly.

The way to reach web scale is to make it absolutely trivial for /anyone/ to play the game. Several open source implementations and open standards enabled anyone who wanted to, to set up their own web server and try out the World Wide Web as a service provider. And, despite that lack of central control, lots of companies made lots of money providing enhanced software to manage those systems. So don’t fall for the illusion that central control is required or desirable for a big financial win.

Signing software is understood technology; we can enable signed KIX functionality with a validated identity as a first step towards quality control. Then, by opening up the validation service–and separating it from the distribution/matching of those KIX functions, we can allow software developers and service providers the freedom to innovate and provide their own approaches to what is valid and what isn’t. Some providers will choose to accept ANY signed KIX and simply track reputation. Others will charge a fee for developers, but run through a quality control check and review. By opening it up, you allow users and developers the freedom to manage KIX quality however they like, without building a presumptive “download at your own risk” ecosystem.

With Kynetx the sole authority on “quality” for KIX functionality, we would have both a technical and a political bottleneck that would retard the adoption of a generalized approach to the disaggregated web experience.

[Btw, it would be great if there were a name for the javascript injected into the browser when a KRL rule fires after evaluating the context and the user identity. This is currently just the "associated KIX functionality", which is a bit wordy.]

Fourth, what about privacy and data rights management?

On the whole, it isn’t clear to me what data might be sent around in the claims of various Information Cards, but there is no discussion in the white paper about the data rights associated with that information. If I’m telling Hertz that I’m an AARP member, can they use that data to start sending me junk mail or SPAM targeting AARP members? Frankly, this is a hole in the entire user-centric Identity framework. OpenID Attribute Exchange and Information Cards allow users to use a third party service for the management and presentment of minimally sophisticated facets of identity (much better than username & password), but neither inherently enables users to specify a data rights regime for the claims or attributes so provisioned. In effect, we’ve made it easy for users to provide additional data about themselves, but missed the opportunity for users to easily control the use of that data.

Since Kynetx has a goal of seamlessly augmenting users’ web experience, isn’t it incumbant on them to assure that seamlessness both protects users’ right to privacy and prevents unintended over-customization based on supposedly private data? This is another manifestation of the “Tivo thinks I’m gay” problem, where Tivo analyzes viewing behavior and assumes things about the user, with no way for the user to manage their profile. The data rights problem happens because there is nothing to keep Tivo from telling Hertz, GE, or NBC they think the user is gay. The problem in the Kynetx approach happens when service providers start passing presumably private data to third parties—and users lack the means to control that leakage once the service provider knows certain data. This level of data rights control needs to be built in from the start for VRM and user-driven applications.

Business Model

At the core, I think the business model needs rethinking. Although a CPM-based pricing for KRL evaluations seems to align the value proposition directly with costs, it actually presents more risk and less control to potential customers than other models. It also presents greater risk and less stability for Kynetx itself.

What service providers and developers want to see in a technology platform is one with a free entry point (so you can get testing and trying it ASAP, even if a production system would need a for-fee license), a constrained, predictable cost structure, and economies of scale. Charging per evaluation offers none of these.

This model instead creates an artificial scarcity and then charges by the drop. What you want is to create abundance and sell buckets and hoses and pumps. Doc calls this the “because of” effect. Constraining KRL evaluation to support a pay-by-drink business model will artificially constrain adoption. Instead, run to ubiquity and sell the best tools for leveraging the system you’ve helped create.

At the same time, the evaluation of rulesets will have highly variable demand, with great spikes and drops far outside of Kynetx’s control. Tying revenue to that demand volatility means an unpredictable, wild revenue profile, flattening out only with insanely large numbers of users. This works for mega services like Amazon Web Services, but for a start up moving from initial revenue to predictable cash flow, it can be unsettling. In contrast, an IDE sales model or subscription based service with monthly fees bounds developer expenses and stabilizes the revenue curve.

I like the idea of KRL rulesets. Currently, SwitchBook is planning on using Javascript, RegEx, and XPath, for similar evaluations. That approach not only feels ad-hoc, it is. I’d like to see a unified approach that is flexible, cross-platform, and supported by a good development and test environment.

I think Kynetx could go far by creating an open source platform for KRL rulesets, then providing a robust IDE and testing framework for those who want to manage KRL rules to meet business needs. I think this is nicely pointed to in the mention in the White Paper of A/B testing with different KRLs. This is precisely the kind of sophistication that businesses will need to make the most of KRLs and which can easily be separated from the core infrastructure that enables KRLs in an open way for everybody. Also, the consulting opportunities to analyze, customize, and manage KRL rulesets is a huge business opportunity. Doing that well is likely to remain a black art for a long time to come; helping Fortune 1000 companies do it well should be lucrative.

As Dale Olds put it referring to Novel’s Bandit Project: First, enable an open identity-metasystem, then sell tools to companies to help them manage it.

Collaborations

I like the value proposition of platform-independent identity-based customization. It fits well with VRM’s r-buttons, MyDex’s Personal Datastore service, and SwitchBook’s Search Maps. I think there’s still some brain work to be done figuring out how we can all support each other and simultaneously build sustainable business models, but I’ve no doubt there’s a way if we all invest in exploring those opportunities. Although I focused on questions and concerns about Kynetx in this post, I have great respect for Phil and hope to work with him as both our companies–and the entire VRM community–build out viable solutions to these kinds of problems.

I’ve mentioned Google Notebook briefly in the past, as a tool for helping with user-driven searches (more) — or complex searches as I used to call them. Unfortunately, Google never connected the notebook with Search, despite it being a reasonable solution for keeping track of the kind of discoveries you find when doing advanced searches at a lot of different websites.

Instead, Google suggests you try one of their other products:

If you haven’t used Notebook in the past, we invite you to explore the other Google products that offer Notebook-like functionality. Here are a few examples, all of which are being actively improved and should meet your needs:

• SearchWiki – We recently launched a feature on Search that will let you re-rank, comment, and personalize your search results. This is useful when you’ve found some results on Google Search that were really perfect for your query. You can read about how to use SearchWiki in this blog post.

• Google Docs – If you’re trying to jot down some quick notes, or create a document that you can share with others, check out Google Docs.

• Tasks in Gmail – For a lightweight way to generate a todo list or keep track of things, we recently launched Tasks in Gmail Labs.

• Google Bookmarks – For a tool that can help you remember web pages that you liked and access them easily, take a look at Google Bookmarks. You can even add labels to your bookmarks to better organize and revisit them.

Sigh.

Google Notebook fit a unique spot in the Google product portfolio, and as you can see in the comments on the announcement, a lot of people will miss it.

It’s too bad we don’t have our Search organizer product ready, I’d love to swoop in and save the day for all those wayward soles stuck without their Google Notebook. The future holds promise… Still, there something to be gleaned from Google’s recent developments. As I’ve said before, Search is bigger than query/response. And at least some parts of Google know it. But I wonder how much of the rest of the company gets it.

Take SearchWiki for example. Google rolled this out in November of last year. If you use Google through a Google account, SearchWiki gives you three new icons on every result:

• promote
• delete
• comment

Promoting an item moves it to the top of the result list. Delete, predictably, removes it from the results and Comment adds a comment to that result.  The first two are private–only you see the effect of promotions and deletions, while comments are public.

It is an interesting experiment, if only because it shows how seriously Google takes Wikipedia as competition; the functionality is nearly identical to Wikipedia’s search engine, Wikia. (And many of us have noticed how often Wikipedia entries show up early in Google results.)

It also shows a growing belief that users can help improve Search if they are actively involved. We don’t know what Google is doing with all the user data of who deleted or promoted what, but it will be fun to watch and find out. It will certainly present a different reference frame than PageRank–the core algorithm behind Google–which focuses entirely on the authority of HTML authors and the hyperlinks they put in web pages. If they shift the focus of their ranking to the actions of every day users, Google would shift the moral authority behind their results from web page creators to web page visitors–a much more representative population. That’d be pretty cool.

Unfortunately, the problem with SearchWiki is that it pivots on keywords rather than a more durable concept of Search. It turns out that the promotions and deletions apply only to subsequent queries with the exact same keywords.

Seriously.

For example, let’s say you search Google for “travel” and delete Travelocity, Expedia, and CheapTickets, because you’ve already tried those sites and are looking for something new. Then after browsing a bit, you realize you want to see websites for air travel, so you change the query to “air travel”. Suprise!  All those results you deleted are back in the list.

This is more than useless, it makes you feel like all that effort to promote and delete was completely wasted. We know that keywords evolve during advanced Searches. As we explore more of the web, we learn more about what we are looking for and which keywords might work better. And yet, Google’s SearchWiki remains fixated on the keyword query as the central point for tracking user feedback for these kinds of advanced searches–because really, who is going to promote and delete results for one-off, simple searches like finding the phone number for a restaurant? SearchWiki seems like it should be most useful for Searches that take us to dozens and dozens of websites, over days, weeks, even months. And yet, its focus on keywords to track promotions, deletions and comments means SearchWiki is practically useless for anything but the most simplistic queries.

What advanced Searches call for is a tool that helps users track a specific Search across the entire web. One that tracks both explicit and implicit data about the search, lets users organize that data on their own terms, and then lets them share that data with anyone that might be able to help their Search. This combination of keyword queries, clickthroughs, and web captures would be an invaluable representation of their Search Intent. When captured on the user’s behalf, it is a great example of the VRM concept of the user as the point of integration. At SwitchBook, we call the resulting document a Search Map.

Search Maps put the user in charge of all the data related to their Search. Search Maps enable true  user-driven searches (more), where the individual’s Search intent is effortlessly created, easily managed, and expressed to precisely those who can help the most. It is co-created with the user, with full transparency and editability. It allows a complete view of a particular search, organized and confirmed by the user.  It can be sent to any online service that can explicitly acknowledge the user’s own Terms of Use, specifying just exactly how that data can be used. The result is a verified, accurate representation of what the user is looking for right now, ready to be used by any Recommendation Provider capable of respecting the user’s data rights and then responding intelligently to the content of that Search Map.

Search Maps are at the core of SwitchBook’s approach to User-driven Search. We’re working with Doc Searls and the VRM community to explore how Search Maps work, how they can meet the needs of users, and how they can appropriately protect users’ privacy and interests when used to manage and express Search intent.

We hope to discuss this more at the Spring 2009 VRM Workshop, tentatively scheduled for March 2nd, 3rd, and 4th, somewhere on the West Coast. If User-driven Search intrigues you, save the date and look for future announcements on the VRM discussion list. We’d love to see you there.

I am looking forward to 2009. There has been lots of change, both professionally and personally, this year, putting me (and SwitchBook) on a trajectory for amazing things in the year ahead.

One of my New Year’s resolutions is to create–and help to create–the world’s first VRM applications in 2009. There are more than a few in the works, at various stages of development. After a long gestation, I believe several are ripe for coming to market.

It’s fun working with a community of like-minded folks to create something grander and better than one could have alone. That’s a big part of the joy of open source and it is a huge part of what Doc Searls brings to Project VRM. It’s a great crowd. I’m excited about what we’re doing together and I hope you’ll join us in 2009, in some way, large or small.

Whether it’s user-generated content like YouTube, user-written and edited knowledgebases, like Wikipedia and Freebase, or user-centric Identity like OpenID and Information Cards, user-driven thinking is transforming our world. With VRM– Vendor Relationship Management–that revolution reaches the market, creating tools for individuals to get more value out of their relationships with Vendors. The goal is to create a user-driven market, where individuals engage with vendors on their own terms, creating mutually beneficial relationships that generate new value for everyone involved.

So what would it mean to apply user-driven thinking to Search? Traditional search is a mix of user-driven and vendor-centrism. While users can enter any query and be directed to content anywhere on the ‘net, we can’t share our search history with Search Providers of choice, nor do we have control over how our activities are tracked and utilized. There are few, if any, open standards for the searcher side of the experience and few options for moving beyond traditional query-response Search.

At the VRM Workshop 2008, we fleshed out some ideas, building on the thoughts introduced in my previous post, as well as ideas discussed at VRM 2008 in Munich and IIW2008a in Mountain View. What I love about the conversations at these unconferences is that they are so rich, literally creating value on a moment-to-moment basis. And these were no exception.

Here’s what has emerged so far regarding User-driven Search.

1. User Driven Search is bigger than query/response.

User Driven Search is more than what we type into the query box and the results we get back from Search Engines. It covers an entire set of activities that span the Internet, including searches entered at site-specific Search Providers like Expedia, the USPTO, and Circuit City, and all the web pages we visit in-between. It is inherently cross-silo—even non-silo—as it encompasses all of our online efforts around a given Search topic.

A recent Google/Comscore study found that the average Travel searcher takes 29 days from their first query until their first online purchase. These advanced Searches don’t take place all at one Search Provider nor do they usually happen all in one sitting. Users need tools that empower them to manage these advanced, multi-site, multi-session Searches.

2. Users should be able to activate and deactivate Search and tracking easily and at will

With User-driven Search facilitating advanced searches across the entire scope of our online activity, users need to be able to turn it on and off at will. Sometimes we want help and are willing to share to get it. Other times, privacy is preferred. We need to be able to turn off the surveillance and just do our thing. Unfortunately, traditional search and advertising networks don’t let us do that in any reasonable way.

There are ways to disable Doubleclick’s tracking and we can tell Google to stop personalizing our search results—if we also turn off our Search History. Yet most people have no idea this is possible and even more aren’t technically comfortable enough to mess with cookies or custom preferences. We shouldn’t have to jump through hoops to disable tracking, because if that’s the case, the vast majority of users will simply not do it, and even those who do will often opt-out completely, which means there really isn’t any choice at all. The decision shouldn’t be between using advanced search features or being treated like a digital transient. We should be able to get advanced features just when we want them and simply turn them off when we don’t. That choice needs to be transparently obvious and easy and available right in the Search interface.

3. Compartmentalization

When treating Searches that span more than single queries, users need to be able to separate them into their natural topical breakdown, in whatever way makes sense. Collecting our entire search history and/or clickstream into a single attention datastore literally destroys the context that makes the Searches relevant.

Users need a way to collect their Search-related activities into categories that make sense for them. We’d like to keep our summer vacation search activity together, yet separate from our financial planning Search. We’d like to collect our home buying search activity and store that in a different place than the queries and discoveries related to our child’s Search for information about George Washington. User-driven Search must deal with more than query/response and yet not so much that it encompasses our entire attention stream. It must capture the sweet spot of user-defined collections at a scale suitable to each Search individually, as determined by each searcher.

4. Visability and Editability

For users to drive Search, we need to be able to see and edit the all of the information used to provide results. Hidden or unauthorized data or tracking of our clickstream allow current Search Providers and advertising networks to analyze and guesstimate what we are looking for, but they don’t provide any way for us to contribute. Not only are they hiding in my virtual closet surveilling me—often without permission—they are missing a great opportunity to simply ask me what I want. By making all Search activity visible, Providers can say “Here’s the data we are using to try to help you.” By making that editable, they add “Can you help us improve it?” User interface challenges aside, there is no reason Search Providers shouldn’t ask for feedback and input. It is guaranteed to improve the quality of their view and ultimately their Search results.

Currently, Google, and its DoubleClick division, track your entire search history and just about anywhere you might go online, yet you have no idea what information they have on you, except for Google’s Search History—and you certainly can’t edit it. So when you track something down on a lark, or someone else uses your machine, irrelevant data gets bundled into your history, only to clog up the machinery that is actually trying to help you. Buy a book on knots for your young cousin and Amazon will be recommending Boy Scout titles for months. This is sometimes referred to as the “Tivo thinks I’m gay” problem. If users have neither visibility nor control over the data used for recommendations, they can’t correct these types of errors. We must have both visibility into the data driving advertising and search results, and we must be able to edit it as well.

5. Selectable disclosure on users’ terms

Having gone to the trouble to coordinate and maintain a collection of data for their Searches, users should be empowered to share that data with any service capable of responding intelligently. Search is a fundamental part of how we navigate the web; it makes no sense to restrict Search activity to any one provider. Just as your Search might take you to dozens of websites, it is also possible that it will bring you to dozens of Search Providers, from Google and Yahoo! to Amazon and eBay, even to microSearch Providers like Circuit City or Schwab. As users navigate across the web, their Search should go with them, seamlessly disclosed to authorized Search Providers as easily as possible.

Today, Google serves as a locked-in data silo for most people’s search history. There’s no way to send that history to Yahoo! Or MSN Live or Amazon or eBay to see what they might be able to do for you. As technologies for personalized search results improve, the value of that search history will continue to increase. We need to be able to send select parts of our search to providers of choice and we need to be able to do it trivially. As easily as we go from one website to another, we should be able to send our Search to a new Search Provider.

And yet, if we are to facilitate the easy transfer of this data, we also need to protect users’ rights, even as we expose more secrets to more people.

Schwab, for example, could greatly improve the ease of finding appropriate offerings if they could review the relevant parts of the current Search instead of relying on you entering just the right queries and properly navigating their site architecture. But it is unlikely that users are going to want to give Schwab any information unless there’s an understanding about just exactly how that information will be used (and the ability to select just what information is sent). We generally don’t want companies to start sending us junk mail or calling us with sales offers just because our Search shows that we are in the market for one of their products. But, if we could be assured they would use our Search just to provide better results and perhaps to improve their offerings, we are far more likely to share that part of our Search that could help them help us. We want explicit agreement for data rights access and we want it before we give them any data, and when we want to select what we send so they get just the parts that make sense, and not any personal information we don’t want to share. A User-driven Search solution must not only allow users to send select portions of their Search wherever they want, it must allow them to set the terms for exactly what recipients can do once they get it.

6. Impulse from the user as a specific statement of Search Intent

Recommendation systems presume that an analysis of your history is the best way to discover what you might want now. The NetFlix recommendation challenge and Amazon recommendations feature both use this approach. Not only does this place the user in a passive mode, it also has no facility for users to state what they actually want, right now. People have widely varying interests and easily switch between tasks even in the middle of a Search. Our past transactions may paint an interesting picture of who we are, but it rarely describes what we want in any given moment. What we really want from NetFlix isn’t the “perfect” movie for someone with my viewing history, we want the movie that’s perfect for the mood or situation we’re in right now.

Search systems, on the other hand, rely on a specific “objet de Search” as a trigger for directing efforts. The objet de Search is a keyword or other statement that explicitly represents the user’s intent in some way. At traditional search engines, the query serves this purpose, with the user essentially asking “what web pages have these words” in the hope that those words might be on the page that has what they are actually looking for. At structured Search Providers, like Expedia or Orbitz, the entries for departure, destination, date, and number of travelers in the combined form data comprise the objet de Search.

For User Driven Searches, we must move beyond the keywords and limited structured form fields to allow a more complex, more expressive statement of intent. This statement should include the entire range of Search activity for your given Search, including queries, Search Providers, clickthroughs, captures, and annotations. In short, it should bundle up the entire Search and present it to the Search Provider as an explicit statement of intent. This presentation must be independent of any data silo, unlimited by the offerings of any particular vendor. It should be a proactive statement of “Here’s what I’m looking for: here’s what I’ve found so far and where I’ve been. Got anything that might help?”

Most importantly, Search operates in the foreground, with an explicit impulse from the user. User-driven Search isn’t about background profiling and analysis to try to guess user intent. It requires an explicit means for users to state their intent in ways Search Providers can understand. Instead of predatorial “targeting” of users with particular demographic, psychographic, or behavioral profiles, User-driven Search operates exclusively on that objet de search, as the entire representation of user intent. No more guessing. No more secretive or unauthorized tracking. No more stereotypical clustering based on industrial-era models of consumer behavior. Instead, User-driven Search Providers respond directly to clear, unambiguous representations of confirmed user intent.

Towards an Open Standard

This is the kind of solution we are working on at SwitchBook. At the VRM Workshop 2008, I was excited to learn more about MatchMine from J Trent Adams; they are moving in a similar direction for media-based recommendations. There is currently no service we know of that fully delivers on the promise of User Driven Search, but I’m looking forward to working with Trent and others to develop the open standards and protocols to make it possible.

If you are interested in joining the conversation, send me an email. We’ll be setting up a listserv to talk on a more regular basis. All are welcome.

[Update 5/3/2009: "user-driven Search" to "User Driven Search"]

“The Social Graph” is a popular misnomer that has plagued the social networking portability conversation ever since Brad Fitzpatrick catalyzed the blogosphere with a vision about the Global Social Graph.

But in fact, “The Social Graph” has little real value outside of computer science elegance. Nobody but Big Brother, the TSA, the CIA, and [insert surveillance agency of your jurisdiction here], actually want that single, monolithic view of all the relationships in the world. That’s The Social Graph.

In contrast, my social graph is hugely valuable to me. Your social graph matters to you. And it might be interesting to discover where our graph (plural) overlap. But neither of us actually care about The Social Graph.

At the VRM Workshop 2008, here at Harvard’s Berkman Center for Internet and Society, it came out that “social graph” is actually plural.

Like fish.

The Social Graph is a misleading distraction, a handy buzzword we can all slip into our cocktail conversations. But the real value is in the personal, independent social graph we all have. Plural.

If you think about it, that’s the only way you can really make sense of it in our user-centric, user-driven world.