(1) As a way to prove you own the URL associated with your blog comment. This is the original problem that OpenID was designed to address, and although commenter impersonation isn’t a big problem for most blogs, OpenID is a great solution.

(2) As a way to identify yourself to a web site without having to create yet another username and password. This is web single sign-on, which addresses a real problem for those who want to easily use all the great web apps out there that aren’t part of Google/Yahoo/Microsoft (a big advantage of which is that you can then log in using their IDs, which you probably already have).

(3) As part of a way to calculate reputation, which can then be used to block spam or grant permissions. Other commenters point to ways in which OpenID is headed in this direction, but I think Matt’s point is that it isn’t there yet, and there are existing solutions that work reasonably well.

I think (2), web single sign-on, is by far the most compelling. It’s a big problem, and OpenID could be a big part of the solution. To me it makes a lot of sense to focus on getting some real traction for Web SSO before tackling the much tougher reputation / spam problem, which unlike Web SSO already has some workable solutions.

But looking at the progress of OpenID and Web SSO in general, what is the biggest barrier to widespread adoption? Lots of people talk about issues like security, technology, and usability, and these are all important. But as I’ve said before, the most important thing is to make it as easy as possible for site owners to adopt the system.

That means minimizing integration requirements and supporting the identity interfaces these sites already use. This is exactly what we’re trying to do at PrefPass, for OpenID as well as the other IDs that a lot of users already have: make it easy and risk-free for site owners to eliminate passwords for most of their users right now.

This is a really cool way to get more users to sign up for your app, without having to deal with the fast-changing landscape of digital identity solutions. Instead, just paste some code, and we’ll take care of it for you! The idea is to address some of the pain points for site owners (or “relying parties”) that I talked about in my previous post on the Laws of Identity.

You can read more about the new PrefPass service here; we’re also working on a WordPress plugin that should be out soon. Check it out!

In the requisite three words, what is PrefPass all about?

As I was talking about in the last post, the idea is to keep things simple and anonymous for users, while giving sites exactly what they need:

– A user identifier (unidirectional: unique to the site and user)
– User prefs for personalization: keywords, interests, etc.

So what’s the point? To reduce the number of registrations and passwords you have to keep track of. How many times have you followed a link to a news site, or tried to check out a cool new app, and decided to bail out when you were faced with yet another registration form? PrefPass replaces that form with one click.

For sites, letting people bypass registration means attracting more users, providing better personalization, and earning higher ad revenues. PrefPass is really lightweight, so there’s no server side integration and no security worries, just a simple javascript button you add to the site. For an example of some things you can do with PrefPass, check out the demo site we set up at YourSuperNews.com.

For blogs, PrefPass is so easy to use that you can essentially add instant personalization to your blog. Check out the widgets in my sidebar for an example (more coming soon). If your blog or app has ads, you can earn more from them by targeting them to user interests, as they are here at EconoMeta. Even if you don’t have any ads, PrefPass complements stats like hits and pageviews by showing you what your readers actually are interested in — an example of this is the Audience Cloud in the sidebar here.

The point is that pretty much any site can be made better by being customized to user interests. And the purpose of PrefPass is to make it as easy as possible for the site and user to form the relationship needed to do this.

We’re off and running, with a long list of cool stuff on the way. Give it a try, and let us know what you think!

Here’s what I talked about. The concept of “digital identity” has been around for a long time, and usually includes all kinds of complicated functionalities. For example, an identity can:

– Prove you are the same person you were last time you visited
– Prove that you are a specific person or have certain attributes
– Prove that you have authorization or a reputation verified by a third party
– Grant permission for one site to pass your data on to another

But what does “identity” mean in reality for most consumer web apps? Well, basically, it usually means a registration form, an email validation, and then another username and password to remember.

This is kind of a pain for users, which makes it worth asking: what’s the *real* reason sites require registration? For most apps, it’s to do one or more of the following:

– Ensure the user is a human and not a bot
– Associate the user with site data (e.g. settings)
– Associate the user with preference data (e.g. interests)
– Contact the user (e.g. to email a forgotten password)
– Target ads to the user (to make more money)
– Associate the user with a specific person (e.g. a blogger)

Looking at this list, the interesting thing is that only the last item really requires an “identity” as most of us think of it. You’d think that the rest could be done without the oftentimes complex machinery of most identity solutions.

Well, it can, and from a certain perspective, that’s what PrefPass is all about! Instead of the same old [form -> email -> response -> password] sequence, why not just [click]? And why not make it completely anonymous? After all, only the last item above requires you to “prove” that you’re someone in particular. With anonymity, there’s no ID to remember, no privacy issues, no namespace to worry about — just [click]!

Microchunking identity means reducing it to its smallest usable parts. For example, there are some cool solutions that focus on proving that you own a blog URL — that’s a microchunk. With PrefPass, we’re focusing on letting you tell a site that you’re the same person as last time, and that you’re associated with some anonymous metadata representing your interests or preferences. That’s it. By keeping it simple, we hope to be able to solve some real problems for both sites and users, while making a big change in how much users can control their own data.

We’re just about to launch a limited beta, so if this sounds interesting to you, please help us out! You can request a beta invite by clicking on the PrefPass button in my sidebar or by going to PrefPass.com. We’re also looking for additional sites who want to try out PrefPass during the beta. If 1-click registration, instant personalization, or user-targeted ads that pay more sound interesting to you, please give me a shout at adam at prefpass dot com.

This is a powerful idea; but why limit it to media? It seems to me that the same logic applies to applications. A big part of what I think is exciting about the latest batch of web apps is that they microchunk what was once a monolithic software application (e.g. Office), make it web-native, and monetize its use via advertising and/or premium service fees.

Going back to digital media, a big part of why it can be effectively microchunked now is that certain enabling technologies are widespread enough to reduce the advantage once held by centralized media: things like editing tools, RSS syndication, and aggregators. The same thing is true for apps; enabling technologies here would include widespread broadband, more active browser techniques like AJAX, and standardized data formats.

I think that there are two main remaining barriers to microchunking apps. The first is the lack of many needed standardized data formats. One big help in this regard could be microformats. The second big remaining stumbling block is that of identity. Big applications, whether on the web or not, have the significant advantage that you just log in once, and then can easily use the different components of the app together.

So how could this identity barrier be knocked down? Well, how about microchunking identity?

As it so happens (or more like, partly motivating this post), microchunking identity is what I just talked about at BarCamp SF. I’ll get to that in the next post.

A great example is GDP, recently dubbed “Grossly Distorted Picture” by the Economist (subscription required, unfortunately). GDP is a very limited and inaccurate measure of economic activity, let alone national well-being. In fact, GDP was initially created to just be a planning tool for wartime production in WWII. But nevertheless, boosting GDP has become a central goal of many countries, which sometimes can lead to strange distortions.

Another example is Alexa’s measure of pageviews to a web site, which has become an easy way to gauge the “success” of a site. But as Alex Castro points out, this measure is in some ways even worse than GDP. Not only can a site attract lots of pageviews without doing anything useful for users, but sites that use AJAX, Flash, or other modern technologies are perceived as less successful because of the fewer page views they generate.

The need to simplify isn’t going anywhere, and so neither are measures and their problems; but it seems worth keeping in mind that any given simplification might be hiding important details, and that it might be worth taking a closer look before drawing any conclusions.

It’s understandable that this happens: you sit down to design the system, and figure “OK, if a user does X then we’ll look up record Y and do Z” when in fact the reality is that most actions will be a small subset of the possible ones and will be initiated by a small subset of users. Keeping this in mind can change your design in a major way; *not* taking this into account can frustrate the users who account for the majority of activity and whose opinions have a big effect on the reputation of your app. At an even higher level, this gets beyond performance and into the realm of features. Specific solutions for dealing with “power users” such as “expert modes” have a mixed reputation, but ignoring the problem won’t make it go away.

It’s interesting that this point runs contrary to the usual “long tail” argument that focuses attention on the *less* active users or objects. I guess the lesson is that we should design for both the head and the tail, and not fall into the trap of designing for a mythical “average user” who doesn’t really exist.

In the meantime, I don’t know how I missed it up until now but John Musser’s ProgrammableWeb site on mashups is just amazing, especially the mashup matrix. If you haven’t seen it already, check it out.

The liquidity in the maturing online advertising industry, which allows new applications to monetize utility to users quickly and directly.

In other words, if you can build an application that has enough utility for a decent number of users to start using it, you can turn that utility into dollars by, say, slapping up AdSense, which pays the bills and keeps the app up and running (perhaps competing with a platform aspiring to monopoly power).

The problem with this in the real world is that AdSense, which at the moment is the easiest way to put advertising on a small site, doesn’t really pay the bills all that well. One big reason for this is that the ads are usually pretty badly targeted when the context is a dynamic app, or a constantly changing document like a blog.

This is where the Web is different from other media: as many people have pointed out, the Web is neither one-to-many (broadcast) nor one-to-one (email); it’s many-to-many. That means that everyone can provide data as well as receive it. In particular, users can “pay” for content with more than just their attention; they can pay by supplying data about their interests that lets ads be better targeted. Although smaller sites currently have a hard time monetizing this data, in theory web applications should become economically viable at a much lower user base due to both more valuable targeted ad space and the previously discussed reductions in development and operations costs.

This idea of paying with data isn’t new, we already do it in several ways:

– Supplying search terms is a payment: your interests at that moment are targeting data (e.g. Google AdWords)
– Reading content is a payment: the content itself represents your interests (Google AdSense)
– Frequenting a site is a payment: your history at that site represents your interests (e.g. Amazon)
– Registering at a site is a payment: facts like zip code, age, and gender act as proxies for your probable interests (e.g. NYT)

This trade of data for content is what Matt Blumberg calls the “New Media Deal”, as I just found out by following a link from Fred Wilson. Matt’s description of this deal is really great, but it doesn’t mention what I think is a big problem: most people don’t get what the deal is! I don’t have any handy stats, but I’d bet that if you took a survey, most people wouldn’t know that the reason they’re always being asked to register and fill out forms is to help the site pay its bills by serving up more relevant ads. They probably think it’s to spam them or do market research or something (er, well, both of which might sometimes be the case actually).

It seems to me that asking users for data might work a lot better if users really understood what it was for. Matt addresses this in part with his next deal incarnation involving more user participation, the “We Media Deal”:

The more transparent the value exchange, the more willing you are to share your data.

But the examples he gives, of us being more likely to care about sharing our data if we know we can delete it and that it will be attributed to us, isn’t really what I have in mind here. Instead of trying to get data from users in indirect ways like surveys, registration, and tracking, why not just make the deal explicit? People understand that someone has to get paid to develop apps or write articles, and if we can pay with something other than money, that’s great!

I think it’s true that a lot of people are used to thinking in the “old media” way: as Matt puts it, we pay by “tolerating” a blizzard of ads, most of which are totally irrelevant to us. If the New Media Deal is made more explicit, I think people will see that everyone wins: a less painful type of payment can support a greater diversity of sites, where participation and mutual respect are values that are reinforced by capitalism and self-interest.

But there are some other aspects to what people mean by “Web 2.0.” Paul Graham calls it “democracy, and not dissing users.” Tim O’Reilly calls it “the architecture of participation.” And pretty much everyone agrees it involves users owning and controlling their own data.

I think that one interesting way to look at this aspect is through the economics of platforms (a great example of an “econometa,” what this blog is supposed to be all about). There are two ways that a platform, or a standard technology infrastructure, can be built:

Private enterprise:
– Many proprietary standards vie for adoption
– One winner attains a lucrative monopoly
– Over time the monopoly expires and the platform becomes a public resource

Public discourse:
– The government or a standards body solicits proposals
– Private companies and individuals lobby for their solution
– A winning platform is selected and designated a public resource

Currently in the U.S. at least there is a tendency to see one of these as “good” and the other “bad” depending upon your political views; I’d argue that there are plenty of situations in which either can be the more appropriate. But one thing is certain: the first way involves a lot more money changing hands. The cost of lobbying is much smaller than the cost of many companies developing and marketing solutions, and the profits associated with being selected to build a public resource is much smaller than the profits associated with holding an ongoing monopoly over that resource.

I’d like to suggest that a part of Web 2.0 is a better understanding of how the private enterprise route towards a platform works, and a decreased tolerance for the power and profits that go to the monopoly winner. This social shift is being accompanied by several economic shifts that reinforce it:

– The ease and low cost of using the Internet to gather together interested parties and work towards a standard without any central authority
– The low cost of building a platform (or an incremental platform component) and applications that use it
– The high number of people with modern browsers and/or broadband who can easily adopt new applications
– The liquidity in the maturing online advertising industry, which allows new applications to monetize utility to users quickly and directly

Taken together, I think that all of this means that the private enterprise path (on the Internet) becomes closer to the public discourse path. In fact, it seems to lead to a “third way” that in many ways exhibits the strengths of each without the weaknesses: a winner can be selected from many different approaches based upon survival in the market, absent huge costs or large concentrations of profits and power, and accompanied by wide discourse.

So yes, I do think it is still possible for new eBays and Amazons to be created, but I think it will be more and more difficult. Instead, models like those adopted (at least initially) by Google and MySpace, which base their value upon utility to the user rather than a lock-in of user data, will become the more certain path to success.

So back to the question in my last post: “should I consider building a new application on a new, proprietary platform?” I think that the bet made by doing so could have reduced risk in this new environment. Charging for the platform itself and maintaining central control over it are becoming less viable; if a company doesn’t work with the interested (e.g. open source) communities, these communities will probably recreate the core value of the platform quickly enough to provide an attractive alternative before the company can gain critical mass. But that doesn’t mean that the basic questions in my last post don’t still have to be answered:

– Is the platform ubiquitous? (e.g. mapping and search APIs? No)
– Will there be onerous fees? (if the platform owner can get away with it, yes)
– Will the platform owner be your competition? (if there isn’t a clear way for them to make money, probably)

So I probably wouldn’t disagree with Greg on the viability of mashups as a serious business model.

One key economic shift listed above that I haven’t elaborated upon is the maturing online advertising industry. I think this is a really important part of the story, but again I’ll have to save it for a subsequent post…