May 15, 2012

Standard Information Sharing Labels

Standard Label for Facebook

Some years ago, based on an idea that came up on a train ride to the airport from OSCON, Kaliya Hamlin, Aldo Castaneda and I put together a The paper for the W3C Workshop on Transparency and Usability of Web Authentication was accepted for presentation on identity rights agreements. The idea is that you ought to be able to mark up data you share to let people know how it can be used. Think Creative Commons for personal data. Recently a number of people, including myself, Drummond Reed, and Marc Davis, discussed a similar idea at a WEF Tiger day.

Joe Andrieu has a proposal that is slightly less ambitious and serves as the launching pad for more complete solutions. Joe’s idea is simple and easy to understand. Just like we have a standard label for drugs so that people can more easily understand how to take a drug and what it does, we should have a standard label for sites that want you to share your personal information so it’s easy to understand what’s going to happen if you say yes. Contrast this with the current EULA model where people are faced with 70 pages of information in a non-standard format that they need to understand if they’re to truly be smart about what they share.

Joe has a Kickstarter project for Standard Label to get money to design the label. If you care about understanding what you’re sharing and think people should be smarter about what they share, then I encourage you to support this project, even if you can only give a $1, give something so show you’re behind the work. Here’s the video from the Kickstarter page.

Now, go and back the project!

Posted on 4:45 PM | Comments () | Recommend | Print
Add to del.icio.us | digg | Yahoo! MyWeb
Related:

Rich Sharing and Personal Channels

[]

The Social Web has shown us the power of connecting. Facebook has friends, LinkedIn has connections, and Twitter has followers. These channels allow their owners to communicate with others, although their capabilities vary greatly. But the resulting relationship graphs are stilted because their proprietary nature makes interoperation and extension difficult—in spite of all of the money and time invested in creating APIs to access them.

I look forward to a relationship network that is based on open standards just as the email network and indeed the Internet itself are. The power of the Internet to serve an untold variety of purposes in a flexible way is a direct result of the open standards upon which it is based. Relationship networks based on open standards will provide unprecedented value and opportunities for people because of the new applications it will engender.

This paper will describe something called a personal channel, based on open standards and protocols, that can form such a relationship network. Personal channels link personal clouds, the subject of an earlier white paper. This paper assumes a knowledge of personal clouds, their features and their capabilities. We will share that channels have properties necessary to induce rich sharing, a hallmark of flexibility without which they would not be able to accomplish all that is needed.

Personal Channels

Long ago, personal computers were interesting in their own right. That changed in the 90’s with the emergence of widespread network connectivity. Anymore, a PC that’s not connected to the Internet is not only boring, it’s non-functional for many of the tasks that people perform every day. If you don’t believe me, just turn off the network on your computer for a day. And of course, the modern personal computer—the smartphone—makes connectivity the very foundation of the platform.

Like personal computers, personal clouds are only interesting when they are connected. Personal channels link personal clouds. The collection of channels connecting myriad personal clouds form a relationship network. On an open standard relationship network, the attributes, permissions, and capabilities of a relationship are standardized and extensible. Every relationship is a link. A link may be a simple one-way (asymmetric) subscriber relationship that does not require involvement of the second party, or it may be a stronger two-way (symmetric) relationship in which both parties act as publisher and subscriber.

In either case, when data and messages can flow in one or both directions across a link, it is called a channel. The control each party has over the channel—the terms and conditions to which they agree over how it will work—is called a link contract. Control over the channel still resides in the link contract(s) with the connected parties. The following figure shows two personal clouds connected via a channel controlled with a link contract.

Personal clouds linked by personal channels

Channels exhibit the following properties:

  • Personal channels provide separately revocable, separately trackable authority to share between personal clouds.
  • Any given personal cloud can have any number of inbound and outbound channels. Any two personal clouds may share multiple channels for different purposes.
  • Channels use a combination of the Event eXchange Protocol (EXP) and XRI Data Interchange (XDI) protocol that give them metaprotocol capabilities. Channels are ways of doing something instead of a place for doing something.
  • Link contracts are a flexible means of declaring fine-grained access control to data and services. Link contracts specify the nature and behavior of a channel.
  • Channels are the conduits over which messages pass between personal clouds. These messages include event notifications, data queries, and data transfers.
  • A channel need not be restricted to just two parties. It may connect the members of a group (e.g., email distribution lists), or access may be fully public (e.g., blogs or Twitter feeds).

Like email, channels form a point-to-point network between personal clouds all speaking the same protocol. Unlike an email server, whose sole function is usually email processing, a personal cloud is more like a general-purpose computer in the cloud; it has an operating system that runs applications, processes events, and manages data under direct control of its owner.

This is why channels on the relationship web can be dramatically more useful to individuals and businesses than ordinary email or Web connections.

Rich Sharing

Marc Stiegler of HP Labs has written (PDF) and spoken about rich sharing. Alan Karp has written about PubShare, a system Marc built that demonstrates rich sharing. Alan relates two stories that contrast our expectations about sharing in the physical and online worlds. The first takes place in the physical world:

In an emergency, Marc asked me to park his car in my garage. I couldn’t do it, so I asked my neighbor to do it for me and said to get the garage key from my son.

The second involves an online file sharing scenario:

In an emergency, Marc asked me to copy a file from his computer to mine. I couldn’t do it, so I asked my neighbor to do it for me and said to get access to my computer account from my son.

The second story is ludicrous to us because we can’t see a reasonable way for it to work even though it closely resembles the scenario from the physical world.

Rich sharing characterizes what makes human communication in the physical world work. Using this model, we can determine how to create better online communication systems. Communication systems, like email, that embody rich sharing feel natural to users and thus succeed. Systems that don’t feel stilted or unwieldy and thus don’t scale the way their designers intended.

Sharing is easy and technically uninteresting in situations where the shared item is public and there’s no need to authorize access to it. Similarly workgroup-style sharing is relatively straightforward and the tools for protecting resources in workgroups such as role-based authorization control (RBAC) and access control lists (ACLs) are well understood. For purposes of contrast, let’s call unprotected and workgroup-style simple sharing.

Sharing becomes much more nuanced when access to the shared item must be restricted and the players in the sharing scenario operate in independent security domains. Many real-world scenarios require rich sharing. Stiegler and Karp demonstrate why workgroup-style sharing can’t accommodate rich sharing scenarios.

Rich sharing is characterized by six key features:

  • Dynamic—Sharing can be done without reconfiguring the system or having other work done by the sharer’s IT department.
  • Attenuated—Sharing happens with the right permissions on the right items.
  • Chained—A shared item can be reshared in appropriate ways. Authority can be re-delegated. Building attenuated chains of delegated authority is difficult in simple sharing architectures.
  • Cross domain—Sharing can occur across security domains without the user linking the domains in an ad hoc manner or the IT department having to setup special purpose federated identity systems.
  • Recomposable—The shared item or service can be used in conjunction with other resources and services even if those documents and services exist in a separate security domain.
  • Accountable—Even though sharing can be re-delegated along a chain, the original owner must maintain the ability to audit and track the use of the shared item and hold the appropriate parties accountable for misuse.

Stiegler and Karp make a case that email succeeds because email demonstrates these six attributes. In contrast, it’s easy to find examples in other sharing architectures that fail to incorporate one or more of these and thus become difficult to use as the sharing scenarios get more complicated. Today’s popular social networks all fail to meet one or more of the above attributes.

Personal Channels Support Rich Sharing

Personal channels exhibit rich sharing. We mentioned in an earlier section of this paper that channels provide a metaprotocol for interaction. Thus they represent a way of doing things rather than a place. Rich sharing is more easily supported by ways—protocols—rather than by places. In fact, I argue that properties of rich sharing such as being cross domain and recomposable are nearly impossible to achieve using a place such as a Web site.

Let’s examine the attributes of rich sharing and see how channels stack up:

  • Dynamic—A personal cloud can use a personal channel to send a message to any other personal cloud that subscribes to it at any time. Subscriptions can be formed between two personal clouds or between a cloud and another network service at will.
  • Attenuated—Link contracts provide a means of fine grained access control that enables attenuation.
  • Chained—Upon receiving a message on a channel, a personal cloud can delegate that message to other personal clouds. This delegation may be algorithmic, but is always under the ultimate control of the personal clouds owner.
  • Cross domain—Each personal cloud functions as its own domain in the same sense that an email inbox represents an independent domain controlled by its owner. Thus a channel carries messages from one domain to another.
  • Recomposable—Messages sent along a channel, be they events, queries, or data are composed with other information from other sources (e.g. APIs, other channels, etc.) as part of the processing done by a personal cloud.
  • Accountable—Channels are uniquely identified and individually revokable. The unique identity combined with the ability to declare authoritatively the nature and behavior of the channel via link contracts provides flexible accountability that can be tuned to a given purpose.

Conclusion

Rich sharing requires that the sharing be dynamic, accountable, recomposable, and cross-domain, while enabling the chaining (repeated redelegation) of attenuated access (including separable revokablity). We have shown that personal channels exhibit these properties and thus enable rich sharing.

Because channels support rich sharing, they are extremely flexible and can be used for many purposes. Personal channels provide a messaging system for personal clouds that provides access-controlled, filtered, trustworthy notifications, data exchange, and sharing. Future papers will expand on these benefits of personal channels.

Posted on 1:08 PM | Comments () | Recommend | Print
Add to del.icio.us | digg | Yahoo! MyWeb
Related:

May 9, 2012

Unlocking Data Exchange: The Long Tail of Data

I-20 Stack Interchange

Much has been made of data lately. And with good reason. Data and the ability to exchange and process it are at the heart of modern society’s productivity and prosperity. Data and algorithms are the engines that drive the economy in the 21st century.

But data is often onerous to obtain, difficult to trust, and hard to understand. Fixing these problems—making trustworthy, understandable data flow more freely, consistently, and reliably—will provide a wellspring of new ideas and companies to prosecute them.

This post makes a case that there is a structural problem standing in the way freely flowing data and describes a method for removing that structural barrier.

The Long Tail

In October 2004, Chris Anderson introduced the concept of the long tail in an article in Wired magazine. The idea, simply put is that the infinite shelf space and near-zero distribution costs brought about by the Web have revolutionized many businesses by allowing them to compete for business that was formerly too expensive to service.

The concept is called the long tail because if you plot the power law distribution of the relevant data (e.g. revenue from sales of a given book title, song title, airline ticket to a particular destination, and so on) there’s always a cut off point where it gets too expensive to service the business using traditional business models. Here’s one of the charts from the Wired article:

Anatomy of the Long Tail

Notice that in the example shown there is a line on the curve and to the left of that line the words “Songs available at WalMart and Rhapsody”. The area under the curve to the left of the cut line is the head of the curve. The area under the curve to the right of the cut—the yellow sections—is the tail and since it’s long when you have infinite shelf space, it’s the long tail. The area in the long tail is the revenue available to Rhapsody but not to WalMart.

The important point is that Amazon, Rhapsody, and Netflix, to use the examples in the graph, can sell all the same product as their competitors as well as product their competitors can’t. A brick and mortar book store can’t stock every book, but Amazon can. In many cases the area—and thus the available revenue—of the tail is larger than the area in the head.

The Long Tail of Consumer Credit

In credit markets, the kings of the long tail are Visa and Mastercard. You need credit to make a purchase. Before credit cards, you would have made a deal with the local merchant to extend credit, or in the case of a large purchase, taken out a consumer loan at the bank (my parents used to do this). Now, we just put it on the card.

The credit card, largely developed in the 1950s and 1960s represents a huge leap forward in thinking about how credit is extended. Some companies, like Diner’s club and American Express developed a credit system that was based on each merchant and consumer having a direct relationship with the credit card company. Many banks did the same thing. In contrast, Visa and the Mastercard established credit networks. The following diagram depicts the relationships in the credit network.

Visa model

In a credit network, both the customer and merchant have a relationship with their respective bank and their banks have relationships with the Visa network.

Table 1: Comparing Credit
Without Credit Network With Credit Network
Relationship one-to-one any-to-any
Credit Terms per-loan on demand
Penetration select merchants ubiquitous
Processing cost expensive cheap

Table 1 shows a few of the differences between credit before and after credit cards:

  • Relationship—before credit networks, credit was extended on a one-to-one basis. You made a credit arrangement with each lender. With credit cards, the arrangement is any-to-any, you can walk into almost any merchant on earth and use credit with no need for a prior relationship. Moreover, in the networked model, both customer and merchant have relationships with independent banks. Any bank will do, so long as they’re a member of the network.
  • Credit terms—before credit networks, credit was done on a per-loan basis. When you needed credit, you filled out the forms for a particular credit transaction. The next week you might do it all again for another. With credit networks, you get credit on demand, in real-time
  • Penetration—before credit networks, you had to select merchants based on what cards they accepted. This was frustrating to merchants and customers alike. With a credit network, even though there are still many cards, they are interoperable with any merchant, making their penetration nearly ubiquitous.
  • Processing cost—without credit networks each transaction has to be negotiated and approved individually and, often manually. With a credit network transactions costs are greatly reduced through standardized contracts and automatic approval and settlement.

These attributes are what give credit networks their long tail potential. Credit transactions of all sorts are available to a wider range of people for a wider range of goods and services from a wider range of merchants.

The Credit Network

We call Visa a “network” but that label may be confusing to people who think of networks in terms of routers and data connections. In fact Visa is two things (yes, I’m simplifying a great deal here):

  1. A collection of contracts
  2. A protocol

Notice there are no wires. The wires are provided by companies like First Data Corp. who actually do the processing according to the terms of Visa’s contracts and protocol. Nevertheless, a network it is because it links countless people and merchants via their banks through the mechanisms of contracts and protocols.

The magic of Visa is the realization that each bank didn’t need a contract with every merchant and every customer or even a contract with every other bank. That’s why Visa is a “network.” Visa has contracts with each bank, the banks have contracts with customers and merchants and the chain of contracts from a customer, to her bank, to Visa, to another bank, and finally to the merchant is sufficient to convince the merchant that she will be paid when she walks in a buy a new pair of shoes. Every time you use your credit card, you exercise a different path through those chains of trust. Visa is thus a trust framework.

By establishing a network that was

  1. any-to-any,
  2. on demand,
  3. ubiquitous, and
  4. cheap,

Visa was able to create a system that services the long tail of credit. Almost any transaction, almost anywhere can be handled by their network for pennies on the dollar.

Data Exchange Networks

The world of data exchange looks, in many ways, like the world of credit before Visa. Companies like Acxiom, D&B, Experian, and Lexis-Nexis sell data on a one-to-one basis, according to pre-executed contracts, in batch. And it’s not cheap. These are companies who have built profitable businesses servicing the head of the curve. But they don’t service the long tail. They can’t, because they don’t have a network.

Imagine you want to start a business that needs access to risk data (i.e. data about the trustworthiness of a business or person). First, you’ll have to go through the sales process where you’ll be screened to ensure you can sign a contract that has a monthly minimum (say $5000/month), then you’ll have to go through legal to get contracts in place, finally you’ll agree to the format for your batch of data and integrate your systems with those of the data company. Of course, you’ll pay more if you need data more frequently than the norm.

If you only need a little data, or data on demand, or from different sources depending on the transaction, you don’t fit in the head of the curve. How many startups don’t get built because their business model needs, but can’t afford, access to data? How many startups don’t get built because they can’t make data available cheaply? These are lost opportunities that need a new model if they’re to be realized.

A data network solves this problem in exactly the same way that the Visa network solves the credit problem. By putting contracts in place up front and building a trust framework upon those contracts, a data network allows cheap, ubiquitous, on demand, any-to-any access to data.

Drummond Reed has built a company around this very idea, called Respect Network Corp (RNC). The idea is that like Visa or Mastercard, RNC will use standardized contracts to create relationships with data providers and data consumers. Protocols will describe how data transactions are initiated, negotiated, and consummated. Payment will be based on the value of the data but is likely made outside the data network on an existing payment network since they’re optimized for that. As an aside, if you look at RNC’s business model, you’ll see a slightly different version of this based not on raw data transfers as I’ve described here, but more long-term relationships between merchants and their customers.

Kynetx is working closely with RNC in building the network. The model and legal framework are fairly well understood. What is less well defined at this point is the nature of the data exchange protocols. Our recent white paper, From Personal Computers to Personal Clouds, outlines what we think the nodes in the network will be like. The network itself must provide services to these nodes so that they can interact efficiently and safely. Specifically, the network must provide the following services:

  • Reputation—in any-to-any interactions, players will frequently do business with nodes in the network with whom they don’t have a pre-existing relationship. In the credit network, this function is performed by the banks who issue merchant accounts and by fraud algorithms that try to detect bad actors. In a data network, anyone, even the customer, might be a data provider, so a reputation system can remove some of the risk in knowing who is providing reliable data.
  • Discovery—finding the data provider who has the data you want at a price you’re willing to pay is tough job without some help. The network will provide discovery services to aid in this task.
  • Semantic Mapping—the individual nodes in the network provide semantic data interchange, but for that to work, they need semantic maps (e.g. ontologies) that have been agreed to by participants in the network.
  • Brokerage—the network facilitates payment, probably through an existing credit network. The network also facilitates setting up subscriptions to data services by passing channel details from publisher to subscriber when the relationship is established.

Building this network is a tall order compared to building credit networks. Financial transactions, for example, have simple semantics compared to data transactions. A few well-established protocols suffice for authorizing and settling credit transactions. In contrast, data transactions may need multiple protocols depending on the exact exchange, even with semantic data interchange in place. Nevertheless, such a network would open up the long tail of data transactions for dozens, even hundreds of companies in the same way that the Web opened up the long tail to ecommerce companies.

The good news is that in the second decade of the 21st century, we’re ready to take on this task. The Web provides a foundation for transport and recent advances in the understanding of APIs and data interchange have prepared countless developers and companies to work in this new world. The technologies and systems described in From Personal Computers to Personal Clouds including the Event eXchange Protocol (EXP), Kinetic Rule Language (KRL), and XRI Data Interchange (XDI) are the key components in building this network. The legal framework being put in place by Respect Network Corp provides the glue that binds them together.

Public and Private

There may be some reading this who have grave misgivings about what I’ve described because it envisions a private, rather than public, data network. I believe that this network has to be, at least partially, private for the same reasons that no one has ever created a public credit network to rival Visa and Mastercard. The primary reason is trust.

The protocols that underlie the network I’ve described are all public or open source and thus available to anyone. What can’t be open source is the legal framework that engenders that trust. There will necessarily be an organization that is the foundation of those contracts. While there may be several of these data interchange networks over the next few years, I believe this will likely devolve to duopoly as most other quasi-public utilities seem to do.

Unlocking Data Interchange

The network I’ve described in this paper solves a structural problem in data interchange that limits current business models to one-to-one, heavyweight relationships. Building an open data interchange network underneath a trust umbrella, enables new business models to thrive by reducing the friction and expense through lightweight, any-to-any interactions.

Posted on 3:15 PM | Comments () | Recommend | Print
Add to del.icio.us | digg | Yahoo! MyWeb
Related:

May 2, 2012

PDS Interoperability

Dead Data

Last week in London, I attended a workshop Iain Henderson put on at Innovation Warehouse on Personal Data Store interoperability. He used the following illustrative use cases to talk about what interoperability means for a personal data service (PDS):

  • As an individual, I want to be able to pick up my data from one personal data service (locker etc.) and drop it into another with minimal fuss
  • As an individual, I want to be able to have applications run on my personal data, even when it exists in multiple different services
  • As an individual, I want the apps I had running on my personal data in one locker service, to work when I move my data to another one
  • As an application developer, I want the apps I build to run, with minimal overhead, across multiple personal data services
  • As an organisation willing to receive and respond to VRM style data feeds; I don’t want to have to set up different mechanisms for each different VRM provider
  • As an organisation willing to provide/ return data to customers as part of our proposition to them; I want to be able to make this data available in the minimum number of ways that meet the users needs, not a different format for each personal data service provider
  • As an organisation willing to provide/ return data to customers as part of our proposition to them; I don’t want to have a different button/ connection mechanism for each personal data service provider on the ‘customers signed in’ page of my web site

These are worth striving for. Just having a place to put personal data isn’t much use to me unless I can use it, move it, etc. As more and more companies become personal data service providers, they will do well to think through how they’re planning for these. Kynetx is working on a project over the next 6 months to specifically address the developer side of this. Specifically, I think developers need two things:

  1. location independent references—applications will be easier to write if the developer doesn’t have to know where the user’s data is stored and the particulars of the API, authorization scheme, and so on.
  2. semantic data interchange—The developer shouldn’t have to parse the semantics of each data services particular tags, field names, and so on. A simple example is “cell” vs. “mobile” in a contact data store.

The particular technology we’re using to do this is XDI. We’ll be experimenting with how an XDI server can be integrated with the Kinetic Rules Engine and how XRI references and XDI statements can be incorporated into KRL.

Posted on 9:57 AM | Comments () | Recommend | Print
Add to del.icio.us | digg | Yahoo! MyWeb
Related:

April 27, 2012

Starting a High Tech Business: Being Startup Compliant

Visa Credit Card

I’m the founder and CTO of Kynetx. This series of articles relates my discoveries and feelings about starting a high-tech business. This is the thirty-second installment. You may find my efforts instructive. Or you may know a better way—-if so, please let me know!

I run into people all the time whose lives are not startup compliant. They express a desire to start a company and have ideas, but they’ve made choices that limit their ability to live the startup life. They say “I’d like to start a company, but I need a salary.”

Starting a company requires extreme flexibility in personal finances. You will likely work for long stretches with no or greatly reduced salary. Debt is the number one impediment to being flexible. Whether it’s a high mortgage, student loans, child-support payments (not exactly debt, but still a future payment obligation), car loans, or credit cards, many people are not able to start a company because they’ve given away their freedom by going into debt in one way or another.

I estimate that since starting Kynetx five years ago, there has only been a 18 month period where I was at full salary. How do we get by? We have a very low debt load; we have no debt besides a mortgage. When you have a low debt load, slashing expenses is as simple as not buying stuff. There’s all kinds of room in a typical family budget to do this. But when you have a high debt load, much of your income goes to servicing debt. As a consequence, there’s just not as much room to slash expenses.

Young people are naturally more flexible in their finances because they don’t have as many kids, a mortgage, and so on. I tell students that the best time to start a company is right when they graduate. They’re already used to being poor, so it’s not a big change. This is a point that I think is largely overlooked in discussions about how to unleash more innovation: student debt reduces the number of people who can afford to start a company. (Note: student loans are especially pernicious for other reasons.)

If you want to be an entrepreneur, you have to stay out of debt. If you’re in debt, use the snowball method to get out of debt and save an emergency fund. Once that’s done, you’ll be free to enjoy starting a company because you’ll have less worry about what happens if things don’t go well. Debt is a form of enslavement that you just can’t afford.

Posted on 2:01 PM | Comments () | Recommend | Print
Add to del.icio.us | digg | Yahoo! MyWeb
Related:

April 24, 2012

The Multiple Passport Problem: Declaring Digital Sovereignty

Passport 2

This morning Patrick Towell mentioned the multiple passport problem. I’d never heard that phrase before, so I asked him to explain. The multiple passport problem describes the world where we have multiple accounts, identifiers, and copies of data at every Web site. I was familiar, of course, with the problem, but not the name he’d given it. I think describing it as multiple passports is brilliant because that name accounts for some of the frustration we all feel. We have to keep credentials—passports, if you will—for every site. We are citizens of every Web site and thus have a home at none of them.

Logging in with Facebook, Google, or Twitter via OAuth makes the problem somewhat more palatable as we now can use our citizenship at one Web site to enter and participate in another. Still this, at most, saves us having separate identifiers, but we still usually duplicate attributes.

The clear alternative to all this is for us to each be sovereign, issuing our own passports, or at least choosing the place where we are citizens of (our identity provider) and using that passport everywhere. That model is better because that’s all how we view ourselves—at the center of our experience. Any model that better aligns with the vision people bring to the Web is bound to better serve them and, in the long run, the Web sites and applications as well.

To carry this point a little further, any identification is a model. Most are fairly limited and thus limited in what they can achieve. Facebook has a much better model of me—merely by including my relationships—than almost any other Web site. I don’t think it’s an accident that they are able to thereby provide greater perceived value to their members. I think it stands to reason that if we were to give users tools that make it easy to self-model and thus put more and more of the data about themselves online, then the model that results would more accurately match truth and thus even more value would be unlocked.

This is the promise of user-centric identity and personal data: greater value for everyone without people having to sacrifice their privacy, a rare win-win. If this is at all interesting to you, come to IIW next week and discuss it with us.

Posted on 2:20 AM | Comments () | Recommend | Print
Add to del.icio.us | digg | Yahoo! MyWeb
Related:

April 23, 2012

From Personal Computers to Personal Clouds

Cloud Wordle

I’ve created a white paper from the series of blog posts I did over the past few weeks. If you’ve read those, this will all be familiar. The white paper is a convenient way to get the whole thing in a single package or share the ideas with someone else. Here’s the description:

From Personal Computers to Personal Clouds explains why the future of personal clouds will be very different from what you have imagined. As more and more of our interactions move online, we increasingly have need of an online place that operates for us. Personal clouds must become more than appliances to achieve their real potential. While appliances provide value, they can’t anticipate every need. They aren’t flexible enough. This paper outlines a vision of personal clouds as general purpose virtual computers. Making that vision real requires an operating system so that developers have a framework to work within. Operating systems provide a core set of services around identity and data as well as a programming model. Download a copy now to learn how those services will work.

This paper is the first in a series that will explain how all of this fits with what we’re calling The Live Web. You can download the white paper in a number of formats (I think the iBooks version looks the best):

Please feel free to share this white paper widely. I’m interested in hearing what you think of the ideas.

Posted on 11:22 AM | Comments () | Recommend | Print
Add to del.icio.us | digg | Yahoo! MyWeb
Related:

April 21, 2012

Has Social Networking Reached the End of its Cycle?

Tim Berners-Lee

A couple of articles related to what people call the social Web caught my eye this week. The first was a report on Tim Berners-Lee entitled “Demand your data from Google and Facebook.” I presume this was related his keynote at WWW2012 which happened earlier this week, although the reporter doesn’t say. There are several audio excerpts in the article.

Berners-Lee talks about the need for open data, and decries the rise of applications that are not web based. He says:

“My computer has a great understanding of my state of fitness, of the things I’m eating, of the places I’m at. My phone understands from being in my pocket how much exercise I’ve been getting and how many stairs I’ve been walking up and so on.”

Exploiting such data could provide hugely useful services to individuals, he said, but only if their computers had access to personal data held about them by web companies. “One of the issues of social networking silos is that they have the data and I don’t … There are no programmes that I can run on my computer which allow me to use all the data in each of the social networking systems that I use plus all the data in my calendar plus in my running map site, plus the data in my little fitness gadget and so on to really provide an excellent support to me.”

I find it refreshing that more and more people, especially people of Berners-Lee’s stature are standing up for user’s having more control over their personal data and how it’s used. He’s talking what we’re calling “personal clouds” or “life management platforms” (a term from EIC this past week). He goes on to describes how such control could contribute to helping people with personal information management and decision support.

Once the data outputs from different sites had been standardised, he said, our computers would be able to offer increasingly sophisticated services such as telling us what to read in the morning. “It will know not only what’s happening out there but also what I’ve read already and also what my mood is, and who I’m meeting later on.”

An article by Alexis Madrigal in The Atlantic called “The Jig Is Up: Time to Get Past Facebook and Invent a New Future” is more biting, in an “emperor has no clothes kind of way:”

What we’ve seen since have been evolutionary improvements on the patterns established five years ago. The platforms that have seemed hot in the last couple of years—Tumblr, Instagram, Pinterest—add a bit of design or mobile intelligence to the established ways of thinking. The most exciting thing to come along in the consumer space between then and now is the iPad. But despite its glorious screen and extended battery life, it really is a scaled up iPhone that offers developers more space and speed to do roughly the same things they were doing before. The top apps for the iPad look startlingly similar the top apps for the iPhone: casual games, social networking, light productivity software.

For at least five years, we’ve been working with the same operating logic in the consumer technology game. This is what it looks like:

There will be ratings and photos and a network of friends imported, borrowed, or stolen from one of the big social networks. There will be an emphasis on connections between people, things, and places. That is to say, the software you run on your phone will try to get you to help it understand what and who you care about out there in the world. Because all that stuff can be transmuted into valuable information for advertisers.

That paradigm has run its course. It’s not quite over yet, but I think we’re into the mobile social fin de siecle.

His point? There’s very little new under the sun over the last five years and no one really proposing much that seems revolutionary. I’d invite you to read the whole article to understand Madrigal’s entire argument. I’d invite Madrigal to look at what we’re doing with personal clouds and cloud operating systems or life management platforms, if you’d rather. Those terms aren’t very sexy—that’s why we need people like Madrigal to write about them, to help with the language. But they provide, to paraphrase Madrigal, a vision of “the affordances of the future that seem wonderful and impossible.”

My recent white paper on personal clouds and cloud operating systems describes a revolutionary platform that let’s people create and control personal clouds that interact as peers with other network services. This is game-changing because it upsets the client-server power structure that has long characterized online interactions. By restructuring our online interactions we unlock new potential in the Internet: our intentions drive online interactions so that we get more of what we want with less risk, less hassle, less friction, and, as a result, less cost. Such a system, helping people manage their lives, is revolutionary.

Posted on 11:09 AM | Comments () | Recommend | Print
Add to del.icio.us | digg | Yahoo! MyWeb
Related:

April 17, 2012

The Importance of Protocols

Kaufland Grocery Store in Munich Germany

I’m in Munich at European Identity Conference. There’s a big grocery store right next door (yes, that’s it in the picture to the right). During the break, Steve and I walked over to grab a snack. Here’s what happened: I put my ice cream bar and Diet Coke on the belt, the checker rung them up, I handed her some cash, she handed me some change, she asked if I needed a bag, I said “no, thanks”, and then we were done.

You’re probably thinking “the sounds pretty normal.” And it is, with one exception: she was interacting with me in German and it didn’t matter. I had no need to understand her words in order to interact with her and understand what was happening. That’s the importance of protocol.

Protocol is all around us in the conventions we use everyday to interact with people. Protocol creates a framework within which different agents can interact and accomplish some purpose. Protocol allows me to interact in a store where the checker and I speak different languages. I only need to understand her when we need to depart from the protocol. Inside the protocol, everything is syntactic. Outside the protocol, semantics matter.

Posted on 8:39 AM | Comments () | Recommend | Print
Add to del.icio.us | digg | Yahoo! MyWeb
Related: