Welcome to the Infrablog

Check out this proposal published by Johannes Ernst of NetMesh. I challenged him a couple weeks ago to apply his skills at developing lightweight, straightforward solutions to the problems presented by XML Digital Signatures, which are too numerous to recount here. XMLDSIG is a powerful technology, but it's very heavy and quite complex, which works against its success in the marketplace, particularly in lightweight development environments.

Just as a gedankenexperiment for Johannes, we wondered what should be done if we wanted something besides XMLDSIG -- something much simpler and lighter -- for identity, publishing and social networking applications we've been looking at. Johannes idea is to forego XML canonicalization -- or transforms of any kind -- and simply sign a single node as a blob, signing the XML in a monolithic way, the way you'd sign a JPEG image.

The single element signing strategy won't work for a variety of existing and legacy XML document formats. But it may be that if one keeps the constraints applied in Johannes' proposal in mind, XML documents might be effectively designed to support this method. If so, it would create a much lower threshold for web apps to clear in order to support basic trust and cryptographic semantics in XML. Essentially, Johannes is asking what would happen if we did away with transforms.

In any case, if you're interested in this kind of thing, it's worth clicking over there to give it a read.

Posted by mike at 04:13 PM | Permalink | Comments (0) | TrackBacks (0)

Dick Hardt and John Merrells of Sxip recently published Fourteen Design Goals for web-based identity systems. As Dick says in his blog entry, these are offered with a nod to Kim Cameron's Seven Laws. I've pulled out the 14 requirements from the doc -- see the doc for more in-depth discussion:

1. Provide a mechanism for presenting users with the information that is being requested.

14. Provide a consistent user experience by ensuring that the user always sees the same
agent, regardless of the context.

Posted by mike at 02:21 PM | Permalink | Comments (0) | TrackBacks (0)

Matt Mower brings up an issue that has come up a lot for me lately as we look for ways to tackle the problems of comment spam. I've looked at the solution offered by CoComment, and their approach pretty much convinced me that the blog comments, as they exist today, are a bad idea.

Don't get me wrong; I'm all for vigorous discussion, wide-ranging and free-wheeling. The idea behind blog comments is obvious and important. The implementation is just terribly flawed, however.

Why?

A couple of good reasons (there are more, but this should suffice):

1. Blog comments do not attach any accountability to the commenter. There is zero penalty levied for abusing the system, either as means of narcissistic catharsis of sleazy commercial opportunism. Nature hates a vacuum, and there's a "consequence vaccum" surrounding blog comments. With no barriers to entry, and no penalties for abuse, it shouldn't surprise anyone when we note that blog comments are increasingly filled with noise and abuse. It's surprising that it worked as well as it did originally.

2. Blog comments are blog posts! Or at least they should be. There's no reason to have a "Comments" section for every post -- that's what the TrackBacks section is for. Want to respond to this post? Great! Post your responses on your blog, and send me the TrackBack. Should I want to respond to your lucid insights into my original posts, I'll just post a reply right back, and send you the TrackBack for that. And so on...

You don't have a blog of your own to respond with? Not a problem. You can spin up your own blog in just a couple minutes, for free, at any of a good number of services. Respond all you want. At length. On any topic. You don't even need to publish original posts. I can imagine an interesting "comment blog" that consists of nothing but witty and insightful comments in response to other current blog posts. Come to think of it, that's all some of my favorite blogs are...

A Self-Correcting System
Requiring commenters to publish their comment on their own blogs gives the system a wall to self-correct. If a commenter wants to be abusive in response to something I've said on my blog, be my guest. Just do it on your own page. Go ahead and notify me, and I can do what I want with it: respond in kind, quote the acceptable parts in a subsequent post, or just ignore it. Want to publish a link to a miracle cure for male pattern baldness in response to this post? Be my guest. Just do it on your own page. Feel free to ping me with a TrackBack to let me know your link is there, and I'll do the right thing in response. I promise.

The tables turn right around when commenters have to use their own space, even if its free, to give voice to their comments. Bad behavior and abuse is naturally discouraged, it just makes the originator look bad, if they get noticed at all.

What About The Good Guys?
For good commenters, other, virtuous things happen. If all my comments were hosted on my blog, I again "own" and control the content I originate. I can get credit or blame for it directly. Those interested in topics or keywords discussed in my comments can navigate to my blog.

As trust relationships develop between commenters, the conversation can still happen in both places automatically. If I respond to a post from, say Doc Searls, and he decides after cautiously trying to wade through my blog that I'm harmless (if not particularly lucid) as a commenter, he can automate the posting of my comments that arrive via a TrackBack. That is, when I send Doc a TrackBack in response to his post, he could configure his blog to automatically grab my comments from the TrackBack and append those to the original post in his blog. Overtime, Doc's "web of trust" would evolve to include a great number of responsible commenters, and the conversation would evolve as automatically as it does now. New commenters can still be allowed; Doc Searls would just have to go through the TrackBacks for commenters that aren't automatically published, and grant access to the ones he thinks merit publishing.

What would be needed to make this work? Just a couple of things, one easy, one a little more tricky.

First, a simple link to be placed at the end of blog posts that invited comments, but offered either a) the TrackBack URL for commenters who already have a blog to send their responses to or b) a redirect to a blog host of choice that provides a quick and easy setup process to spin up a blog, if even just to comment on the one provocative blog post. If it were b), response information could be preserved through the setup process so that the newly initialized blog appears with a new "response post" -- linked and quoted to the original post -- as the first order of business for the new blogger.

The second piece of the solution would be a policy system for TrackBacks. This could be arbitrarily complex, depending on the tools and the blogger's appetite for configuration, but minimally there would need to be a way to manage TrackBacks in a way similar to the way comments are moderated by blog tools today. The administrative interface for the blog tool would display the contents of the TrackBack -- the content on the commenter's blog -- and the blogger could make "Yes/No" decisions about whether to publish the TrackBack as a link, as pulled, quoted content, or not at all. Bloggers who qualify for the "White List" could have their TrackBacks linked or quoted automatically, without any added work for the blogger.

Blog Explosion
Last but not least, think of the "hype curve" benefits of such a setup. Blog numbers would explode. David Sifry's "State of the Blogosphere" charts could go super-geometric, with blog numbers doubling not in a matter of months, but just a number of days, or even hours, as the commenting masses migrate to "comment blogs".

Ok, so that last one's not really a good reason to pursue this. But the other reasons are good ones, I think.

Comments?

Posted by mike at 02:21 PM | Permalink | Comments (0) | TrackBacks (0)

No sooner do I post about Rails powering the long tail of web apps then do I learn of Google's acquisition of MeasureMap (via DHH's LoudThinking blog).

MeasureMap is a Ruby on Rails app, and according to David Heinemeier Hansson, the first Rails app to get acquired in the Web2.0 era. Didn't even launch before getting acquired. Congrats to the MeasureMap team.

I'll be interested to see what happens to MeasureMap platform-wise as it gets grafted into the fabric of Google. But it serves notice that Rails isn't just about RAD, demos and weekend one-offs. There's a flurry of activity right now building heavy-duty Web2.0 apps like MeasureMap -- if you don't believe me, try and find a quality Rails developer for hire. Go ahead, try it.

Posted by mike at 01:25 PM | Permalink | Comments (0) | TrackBacks (0)

My colleague Kiran Dandekar has been doing something I've been doing lately: working with Ruby on Rails applications in the same way others work with PowerPoint, Visio, or Rational Rose. There's often a need to "sketch out" a web service, build some "wireframes" or "workflow diagrams" as a means to think through architectural and other issues, and also as a way to socialize the idea across the team. There are any number of tools available to facilitate this process, but Ruby on Rails is unique in its approach to sketching out a web application: build the web app itself.

I'll spare you the sermon on Rails; if you've tried it out, you don't need any convincing from me (and if you have been bitten by the Rails bug you aren't wasting time reading my blog, you're building web apps). If you're not familiar with Ruby on Rails, I'll just say this: Rails makes building basic, solid, functional web apps easier and quicker than anything else I've ever seen. By a long shot.

Kiran called and pointed me at a URL for his "sketch". We'd talked about the application previously, but I'll confess I only partially understood what he was driving at at the time. After a few minutes of clicking around his Rails app, the lights quickly came on, and not only did I understand clearly the value proposition that was being presented, but also the points where things should be developed further, and areas that would be problematic.

At one point, I ran into a server error, leaving the demo stymied. Kiran hung up, and called me back a couple minutes later. "Fixed," he said. We walked through the rest of the demo, and I congratulated him. "Just something I cooked up over the weekend," he said.

Kiran's technically high-powered. He hasn't been a developer for some time, but I'm sure he was quite effective as a coder way back when. But coding is decidedly not part of his day to day responsibilities nowadays, which makes it surprising to see an application like the one he showed me pop up from his laptop over the course of a weekend. In the time it would have taken to forge the appropriate PowerPoint slides that described and hinted at the application Kiran was considering, he built a decent version of the real thing.

Maybe it's just me, but I think this has far reaching ramifications. I'm told that TurboGears for Python and a handful of other web development frameworks are out there now that offer similar power and speed to the web developer. Could be -- great as it is, I'm not one to suggest that Rails has magical qualities that separate it categorically from all other tools. Rather, I'm suggesting the opposite: Web Development has reached the point where the "long tail" of web apps has become a reality. Or will very soon.

Kiran's example highlights the utility of Rails development as prototyping aid. But the same power that makes it effective as a weekend project for Kiran makes it plausible for a wide variety of other "long tail" scenarios to become reality. I'm toying with the idea of writing a set of small Rails apps for managing things around the home. "Block and tackle" apps -- apps that provide basic UIs for shared databases spring up spontaneously from a handful of hackers collaborating at a conference. Consultants really do show up at a client's office with their PowerBooks and leave at the end of a day with a working app that captures a good part of what the client is seeking. And it's not a demo; it's for real.

The marginal cost (and effort) for building new web apps has dropped dramatically in the past two years. While much of the buzz and hype in the infosphere has orbited around AJAX and great advances it has catalyzed in high-end web apps, there's been a revolution at the other other end of the scale as well. For every Google Maps or Yahoo! Mail, there are a hundred or a thousand humble but effective web apps sprouting up, serving increasingly specialized and esoteric needs in the marketplace.

Posted by mike at 12:38 PM | Permalink | Comments (0) | TrackBacks (0)

I've been getting great results from my efforts and experiments with Ruby on Rails in the past few months. More on that another time.

But a couple projects I've been working on could benefit from the UI Library and Design Patterns Library released today by Yahoo!. Rails developers are already in a pretty nice position with resources like script.aculo.us and Open RICO so nicely integrated with the Rails framework. But after just a cursory review this afternoon, it's clear that Yahoo!'s contribution is a big step forward for web developers.

I could go on about some of the cool moving parts in the offering - the Navigation Tab and Breadcrumbs design pattern look particularly useful. But the important takeaway from this isn't the actual features of the libraries, but the "design pattern" Yahoo! is adopting in making them available.

These libraries represent a lot of work. How does Yahoo! come out ahead by giving these tools away? There's the goodwill to be gained from folks like me who can and will put their tools to good use, for free. It's good karma. But also, and more importantly, it elevates the playing field for web apps in general. If Yahoo!'s UI tools and attendant design patterns proliferate -- and there's good reason to think they will -- the whole concept of "web app" will be upgraded. As the overall sophistication and power of web apps increases, who stands to benefit the most? Premium web services will be able to do things: 1) push the envelope for the apps and services they offer to their customers, but also 2) benefit from the availability of high quality web apps and services from partners and even competitors whom Yahoo! integrates with.

In this ecosystem, the general quality of the apps that are floating around matters. If you offer a *platform*, it's important that the developers who connect with and build mashups on top of your services have what they need to make your platform shine.

Even then, there's still something more. When you allow for both the good karma and the elevate-the-ecosystem arguments, the sense remains that Yahoo! developed this wicked cool library, and the developers just understood that it deserved much wider use than it would ever receive, even inside a huge web company like Yahoo! As developers know, sometimes a thing is just too good to be kept in a cage -- damn the economics, it deserves to be free.

Posted by mike at 11:44 AM | Permalink | Comments (0) | TrackBacks (0)

Over on the OpenID mailing list, I made some comments outlining concerns about OpenID/YADIS/LID and the prospect of managing directional identity. Drummond Reed emailed shortly after I posted my thoughts, pointing out that he had covered this topic in depth on his blog back in December.

So he has. And, suprise, we came up with essentially the same solution. My suggestions were largely informed by the Sxip approach to the problem of directed identity, so I suppose its fair to say that I've essentially just been agreeing with Dick Hardt and his team, as well as Drummond and his: a robust single sign-on technology -- even a lightweight one -- should support on-the-fly, directed identities. If you've been following the evolving discussion around OpenID, YADIS, LID, XRI, and their points of convergence, Drummond's post is good one to read on this subject.

Posted by mike at 12:27 PM | Permalink | Comments (0) | TrackBacks (0)

Via Kim Cameron's blog, an article -- ostensibly legit -- about a Cincinnati company that is implanting RFID tags in some of its employees. The thinking is apparently that "tagging" employees adds additional security, enabling better monitoring of where people are, or aren't in secure environments.

RFID chips in humans are a good example of omnidirectional identity, something I discussed in a recent post. In this case, it seems quite ill-advised for humans to equip themselves with an omnidirectional identifier that anyone with a proximal reader can detect, without the consent, or even knowledge of the bearer. This is a feature, not a bug, in many commercial contexts -- say when you're a tracking a flat screen TV through the supply chain. But as the recent passport+RFID controversy illustrates, the intrinsic omnidirectionality of RFID tags presents more problems than solutions when tied to human identity.

Not all RFID tags are world-readable. The SpeedPass tags that are widely used in certain parts of the US for automated roadway tracking contain low strength cryptographic tools to make them at least somewhat challenging to clone and read, for example. Other chips are available, at much higher prices that do provide a strong challenge/response sequence that manage the risks involved here.

The RFID technology embedded in the employees is provided by a company named VeriChip. While VeriSign is in the RFID space - we run the ONS root for RFID, for example -- VeriChip and VeriSign aren't related.

Posted by mike at 12:06 PM | Permalink | Comments (1) | TrackBacks (0)

David Sifry of Technorati posted his latest State of the Blogosphere, asserting that growth rates in the blogosphere remain vigorous. Umbria has an interesting (if somewhat short) report on splogs, which you can download here - email and name registration required to download this PDF.  Matt Galloway surmises that combined, these two reports might indicate contraction in the blogosphere. Intuitively, I think that's not at all the case, but I do think that Matt is pointing at a phenomenon that is under-examined: the growth rates for splogs are significantly higher than for "real" blogs, based on the data I get to see.

Posted by mike at 06:31 PM | Permalink | Comments (0) | TrackBacks (0)

Keith Teare gave me a look at the service he's getting ready to launch – edgeio. In addition to being a good example of the new breed of web apps visually and interactively, edgio is an example of what I think is an important trend in the blogosphere. Edgeio is a search and indexing tool that aggregates content from the blogosphere in such a way that your blog can be used in new and interesting ways. In the demo, the emphasis is on classified ads, but Keith hastens to point out that the edgeio platform is designed for a wide variety of content types and applications.

For all the “hipness” of craigslist, the edgeio demo quickly drives home the point that while craigslist is an improvement over the traditional newspaper classified advertising section, it's built on its own outdated ideas that are about to be replaced, or at least innovated upon.

Why does craigslist host the advertising content for its classifieds? An obvious reason is that many of the craigslist advertisers don't have a blog, homepage or other site on which to host their ad. Fair enough, but in creating the classified ad, craiglist is giving them that hosting place. If a “space” for that ad is going to be created, why should it be inside craigslist's walled garden? If that same user comes back from a vacation to Kauai and wants to publish a review about her stay at the Westin there, Fodor's is more than happy to accept her review as freely donated content that it hosts in their own “walled garden”. Many Internet users, if they take inventory of all the useful content they've created and published over the past years, will realize that they do indeed have a significant “presence” on the Net. It's just been donated piecemeal into a myriad of walled gardens. On one level, blogging is a natural reaction to this phenomenon: I want to own my own comments and thoughts, rather than simply offer them as fertilizer for someone else's walled garden.

There's no problem with Internet sites that provide tools and space for users to host their contributed content. It may be easier for many to let Craig's List, Amazon, eBay, Trip Advisor, Epinions and others host the content users would like to contribute to the infosphere. But increasingly, with the advent of blogs and citizen's media, users do have a place to host their content. They've already realized the value about owning and controlling their own commentary on the world via blogs, but edgeio highlights the potential for users to become “holistic” in their publishing and content management. Why not host your restaurant reviews, your classified ads, your resume, your game walk-throughs on your terms. You control it, you own it. It's yours to begin with, so why not?

Indices, metadata and navigational information belong in the center. Content, however, optimally exists at the edge. This design pattern is pervasive on the Internet – Google is a prime example. Google aggregates metadata about billions of web pages that are out there: index at the center, content at the edge. Google doesn't maintain a “walled garden” of content that its index provides access to. It simply provides indirection – links to the content, wherever it lives.

That's not the case with craigslist, though, or any number of other destination sites. Craigslist aggregates metadata for classified ads, but only for the content it controls. Why? Fodor's provides an easy search facility for finding user reviews on destinations, but only for reviews that it hosts and controls. Why?

There are practical reasons, to be sure. In the case of craigslist, it's just easier to get things off the ground if you provide a “one stop shopping” experience – type in your classifed ad here, and you're ready to go. There's self-interest at work as well; content hosting builds a tighter relationship with users that can be monetized. Those are good reasons if you are a walled garden builder. If you are a user, though, these reasons are increasingly less important, as tools for hosting and managing one's own content become more refined and accessible, and aggregating services like edgeio emerge.

Edgeio follows the Google pattern – metadata at the center, content at the edge. Craigslist follows the eBay pattern – everything within the garden walls. It's certainly a challenge for edgeio and other like-minded services (the underlying thesis behind structured blogging and microformats is essentially the same) to get over the initial adoption threshold, but once up and going, this model performs much better than the walled garden approach. Maybe not for the walled garden, but for the user who powering Web 2.0 and beyond. Us, in other words.

Posted by mike at 02:44 PM | Permalink | Comments (0) | TrackBacks (0)

VeriSign Naming and Directory Services (VNDS), the division of the company that operates the com/net registry -- and does a great many other things as well -- has been renamed to "VeriSign Information Services". It's more than just a new name, of course; it's a reflection of the broadened scope the division has in providing its part of the "Intelligent Infrastructure" services that VeriSign provides as a whole.

Posted by mike at 02:11 PM | Permalink | Comments (0) | TrackBacks (0)

As a follow up to a previous post on Kim Cameron and Craig Burton discussing digital identity, my comments on Cameron's Seventh Law of Identity: Consistent Experience Across Contexts:

The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.

I can't remember who first pointed this out but it's worth noting that while it's fun to refer to things like this as the “Seventh Law”, these are actually requirements or goals, not laws. In any case, the implications of this are sweeping: in order for digital identity to work, a common user interface experience is required. As it happens, Microsoft is busy building “InfoCard”, which is the presumptive standard-bearer for this common user interface. Microsoft points out that their InfoCard UI is distinct from Windows Vista, in which it will be shipped, so as not to require the rest of the world to adopt a part of the Vista user experience as a necessary ingredient of digital identity.

Given that, it's hard to see this as anything short of a short-sighted piece of the framework. Question: What is the rationale behind the Fifth Law: Pluralism of Operators and Technologies? In the white paper, we find this:

It would be nice if there were one way to express identity. But the numerous contexts in which identity is required won't allow it.

That argues directly against the Seventh Law as I understand it. The variety of contexts (as well as corporate and social interests among other things) won't allow for a unified user experience to develop. Maybe I misunderstand what is meant by that term, but there must some common visual component implied here. If so, what do do with mobile phones that can't support the visual richness of the InfoCard-on-Vista experience? Users with small, text based screens can't participate? Reading the Seven Laws of Identity, I always get to the end and expect it so say something quite opposite for the Seventh Law. Something congruent with the Fifth Law:

It would be nice if there were one user interface scheme which would work for all users, on all platforms, in all contexts. Because of the diversity found in each of these areas, this is unrealistic – the system won't allow it. Pluralism of operators and technologies dictates that the user experience will vary – often dramatically – from context to context. However, here are several high level design principles which will provide the best control and management for the user....

To me, that is both consistent with the spirit of the rest of the document, and respectful of the practical realities of the Internet. As it is, I think the Seventh Law works against the rest of the framework.

Posted by staci at 04:55 PM | Permalink | Comments (0) | TrackBacks (0)

It's a fairly long piece and they cover a good amount of ground. Have a listen if your into digital identity. In the roundtable, several points or assertions were made that bear further discussion.

The first issue is unidirectional and omni-directional identity. Kim and Microsoft published a whitepaper a while back laying out the “Seven Laws of Identity”. Law #4 is the Law of Directed Identity, and asserts that an identity system should be able to provide a different identifier to each relying party, so as to foil attempts at correlation. That means that to website A, I'm known as “X”, and to website “B”, I'm known as “Y”. If they should happen to compare notes, they won't have a basis for determining that X=Y.

In contrast, omni-directional identity uses the same identifier to everyone. The example Kim gave in the podcast was the URL for a blog. That URL is omni-directional – all parties see the same identifier, and know the blog by the same name.

So far so good. Kim went on to suggest, however that URL-based identifiers were inherently omni-directional, and that this was a design flaw with URL-based identity systems, as they violated the Fourth Law of Identity.

URLs are well suited to unidirectional identity. There's no problem at all in deploying a identity server that issues a different URL for the user to be known by for each different relying party. For example, if I enroll at an identity server “exampleid.com”, it can provide me with an omni-directional ID URL:

http://michaelgraves.exampleid.com

I can delegate another website like my blog to that address if I want so that:

http://michaelgravesblog.blogspot.com

Delegates its identity services to http://michaelgraves.exampleid.com

That's straightforward. URLs have been used as omni-directional identifiers as long as there have been URLs. But exampleid.com can generate any number of URL IDs for me as I need them. For example:

My identity server knows each of these is me, but no one else does. Each of these can have its own policy and rules about what information and claims it will exchange with the relying party.

At the heart of this is what I believe the mistaken idea that URL-based identities are singular, or somehow tied to a blog or particular web page. That isn't the case. With URL-based identity, I can have as many omni-directional identifiers as I want and as many directed identifiers as I want.

Posted by staci at 12:04 PM | Permalink | Comments (4) | TrackBacks (0)