OSCon 2005 wrapup

   Print.Print
Email.Email weblog link
Blog this.Blog this

Andy Oram
Aug. 05, 2005 11:46 PM
Permalink

Atom feed for this author. RSS 1.0 feed for this author. RSS 2.0 feed for this author.

URL: http://conferences.oreillynet.com/os2005/...

Nat Torkington and his team did a superb job choosing topics for the O'Reilly Open Source Convention. Just take this as given: if something important is happening in the open source space, it's at this conference. There may be only one or two talks on a cutting-edge topic, when the public hasn't caught on to it in a big way yet, but if you're observant you'll find the topic here, and key people in its space available to talk to. I'll show one example on the subject of identity.

Identity: whose is it?

Substantial attention was given at OSCon to identity, a problem the computer field has to solve if we are to make the most of what individuals have to offer online. Dick Hardt of sxip gave a lightning keynote, Dave Smith spoke about Passel, and Johannes Ernst presented LID.

Identity, in this context, means offering verifiable and persistent information about yourself to people online so they can make judgments ranging from the most basic ("Should I read an email from this person?") to the most significant ("Is this person offering advice really a lawyer?").

Clearly, in an online world where people increasingly generate their own content and form communities relative unmediated by servers, identity will become central, along with reputation and other aspects of trust.

In his keynote, Dick Hardt relied on the trendy "2.0" meme, reserving "Identity 1.0" for the traditional provision of online identity, based on a single all-powerful authority such as a CA or a credit-card company, and heralding "Identity 2.0" for forms of identity that decouple the user from the authority.

I dealt extensively on this topic back in April 2004 in my two-part article From P2P to Web Services: Addressing and Coordination and From P2P to Web Services: Trust. I think the downbeat assessment of the field I presented in that article is still accurate. None of the very eager and idealistic players in this space have solved the real-world difficulties of maintaining, verifying, and presenting information about people and institutions.

On the one hand are heavy-weight standards that take years to develop and are dominated by huge companies: Liberty Alliance, WS-Security, SAML, and so on. The size and complexity of these standards lay down a stiff ante to any organization that wants to get involved in identity services. Yet they barely scratch the surface of what is needed. This is due to the perennial scourge of standards: they strive to be broad frameworks, so they leave the details to other committees to standardize later. And the problem with later is that it's always later.

The talks on identity that I heard at OSCon had similar limitations--although I'll show later how the proponents handle my objection.

It's fine to say, as Dick Hardt or Dave Smith do, that a person ought to be able to obtain a valid ID from a trusted third party and then present it as one presents a driver's license in order to buy alcohol. (Both relied on this familiar analogy from everyday life. Me, I get my alcohol from the spigots that flow freely at conferences such as OSCon.) The question is: who will grant that valid ID? It's a social question, not a technical one.

That's why, in the title of this section, I asked whose identity it is. The designers at this conference have a different concern: they want to make sure your identity is just yours, because you control how much of it to reveal.

What we all want to avoid is the existing situation with SSL authentication in browsers. Only a limited set of certificate authorities, such as Thawte and VeriSign, have a chance of being recognized. (I checked a version of Firefox and found 21 authorities in its Certificates list.) A user can install another certificate authority, but who ever does?

Worse still, how many users reject a certificate from a web site when it's not secure--that is, who backs away when a dialog pops up saying the site failed to be validated by the certificate authority? Most of us forge right ahead.

So we all want a more inclusive system of third-party verification with lower barriers to entry. For instance, Hardt possesses a driver's license from British Columbia, which is useful even though he has no relationship with British Columbia other than having proved his ability to drive there. We can all have multiple forms of such flexible identity. (He said that federation, as in the Liberty Alliance, could be considered "Identity 1.5.")

The SAML-style frameworks try their best to set up robust frameworks so organizations can exchange information about the characteristics needed to trust people (for instance, who gets to look at financial records) and whether individuals possess those characteristics. But first the organizations have to agree on the characteristics and their possible values. This is where the real effort lies; not in exchanging the information once they agree on it. I cover this problem in the previously mentioned articles.

Another problem, that of privacy, has to be faced. Most people understand the commercial benefits of identity management, especially online wallets and single sign-on. But this is the unfriendly side of online identity, the side that makes people afraid we'll go through life with all kinds of sensitive facts tattooed to our online selves. What Hardt and the others at this conference promote is a friendly side of online identity, where we provide tidbits when they're useful to us and build communities and new services on identity.

For instance, you could share your college degree, authenticated by your college, to a forum where you're trying to throw your knowledge around. Similarly, you could decide whether to reply to someone's question based on his rating as a helpful and competent member of the forum. Many sites contain valuable rating information, such as eBay; perhaps they could allow users to share it outside their boundaries.

The goals inevitably involve trade-offs, because while it's a big advance to give a person a choice as to whether to share information, sites can also require that information as a condition for logging in. This conflict will never go away, although provision for pseudonyms can soften the choice in some situations.

The underlying technologies are familiar and well tested (cryptography, certificate authorities, asymmetric keys). CACert (mentioned in an earlier blog of mine), is becoming a no-cost, low-barrier certificate authority for the masses.

The designers of the heavy-weight standards such as Liberty Alliance as the WS specs are designing from the top down. They have daunting business needs and are trying to put together a system that will ensure these needs are met in an air-tight manner. By shoving off the immense social changes that would be required for people to bring out digital identities, they risk that the systems will never be used even if they can be built.

When you build a specification you hope to be used, you can't get away with saying, "Somebody else has to solve the social requirements," because it's up to you to design your system to so those requirements can be met.

The designers of the low-bandwidth, easy-entry systems such as sxip, Passel, and LID are proceeding, instead, bottom-up. As with the historic development of the Internet and the Web (or cute little tools such as GreaseMonkey, described next), they want to provide identity capabilities and just see where these go. Still, they won't succeed unless some of those same social requirements--giving everybody a certificate, deciding on what parameters are important and how to represent those parameters digitally--have to be solved.

Some unusual aspects of GreaseMonkey

Aaron Boodman described his GreaseMonkey Firefox extension to a fairly sizeable crowd. Along with a few impressive demos and a quick lesson in GreaseMonkey scripting, he laid out some lesser-known aspects of this new and suddenly popular system. (It is being generalized and ported to other browsers besides Firefox.)

First, he pointed out that GreaseMonkey scripts are ephemeral hacks by nature and not likely to ever becoming something more. This is because they are based on characteristics of downloaded pages that are not under the control of the script, and therefore are fragile. (He didn't use the term screen scraping, but that's essentially what GreaseMonkey scripts do.)

For the same reason, Boodman has decided to put his library of scripts into Wiki form, to encourage users to update and improve the scripts without the formality of source control or project teams.

Other features under development include:

  • User notifications for new scripts. These don't involve users asking the script site for a script that applies to each page they download; that might be a privacy risk. Instead, news of new scripts will distributed regularly, perhaps once a week.

  • A centralized management area for scripts called Greaseproxy.

  • A possible rewrite in C++, mostly for security.

On the security front, Boodman admitted that GreaseMonkey had originally ("like Windows") been written with no concern for security. He promised that all this had changed in the latest version, numbered 0.5. He now recognizes that a Web site's content can abuse scripts, notably by substituting functions written by the malicious Web site developer for functions of the same names defined in the GreaseMonkey script. To stop this, he's instituted the use of a JavaScript feature called XPCNativeWrapper, which ensures that the function being run is the native one rather than one defined on the page, and a new structure placing GreaseMonkey above the document root, so that the document cannot override the functions in the GreaseMonkey script.

Boodman pointed out that GreaseMonkey can be useful for prototyping. It's much easier to try out a feature in JavaScript than to rewrite one's Web pages, although ultimately the feature should be implemented in a more traditional and robust manner. He also claimed that Web sites benefit from being hacked up by users through GreaseMonkey: the sites get new features for free and end up with happier users.

Miguel de Icaza on desktop advances

The OSCon organizers saved the ever-popular Mono designer Miguel for the closing keynote, and I wager it helped to keep people around at the conference. He demonstrated the somewhat hallucinagenic 3D effects Novell has achieved in the X Window System by integrating the Cairo vector graphics library and Xgl, an X server based on OpenGL so it can use hardware. Watching Miguels' windows wriggle, fly toward us and back, and wrap around, I was reminded of a demo of Sun's Looking Glass I saw a year ago. I found Looking Glass even more pleasing aesthetically, but I haven't heard anything about it recently.

A Java developer told me at the conference that one of the biggest weapons Novell can wield in trying to persuade customers to migrate from Windows to Linux is to tell them Mono will let them keep all their ASP.NET scripts working. And that was one of Miguel's themes at the keynote.

He also said (with his characteristic flippant bluntness) that Novell is finding out "what is wrong with the Linux desktop" by gradually migrating its entire staff to it (they are 50% done). They perform extensive user testing, with three cameras on each user to capture their behavior.

Key areas where they're working now include making hardware work, and implementing missing applications (although I've seen other implementations of some apps he showed). Some of the new applications include iFolder, which keeps different systems in sync, a media player with ipod synchronization and CD burning, and the Beagle search tool (which I covered in an earlier blog.

Short takes

Wez Furlong introduced PHP Data Objects (PDO). The goal of PDO is pretty much the same as its Perl counterpart, Perl DBI, of Java's JDBC: to provide a portable interface that can let people use a database application with a different database engine without having to rewrite the library calls. (The SQL, in all these cases, may still have to be rewritten because no two database engines have quite the same SQL interfaces.) Furlong did not demonstrate any other strong advantages to using PDO instead of PEAR DB or even a database-specific library. PDO implemented various features such as error reporting and streaming results (forward-only cursors) in its own way, but didn't break new ground that I could see.

Randy Ray had an unmatched opportunity for forty-five minutes to tell a completely full room why they should use SOAP for some projects instead of relying on REST. He did not succeed. Because he didn't get through all his slides, I can't tell whether he tucked some knock-out argument in the last ones. But I would expect a talk like that to explain why standard object-oriented virtues--such as strong type checking and routine error reporting--were sometimes useful in Web Services. I didn't detect any such argument. Instead, he focused on things I find irrelevant, such as the freedom with which REST applications can define protocols. He did generously remind the audience of XML-RPC and suggested it as a half-way measure between the loose, light REST approach and the heavy-weight SOAP approach.

As you can tell, while I stated at the beginning of this blog that the choices of topics at OSCon were outstanding, some of the presentations did not live up to their potential. Usually I was glad I went and learned something--there is no doubt that the presenters knew and cared about the material--but I sometimes felt either that the presenters focused on aspects of the subject that weren't the most interesting to me personally, or that they didn't go into enough depth.

On the other hand, an unexpectedly delightful keynote on how to adopt open source in business was delivered by Kartik Subbarao of Hewlett Packard. I won't try to reproduce his perky analogies, in which poor open source utilization comes out as a swamp and effective open source utilization comes out as Venice. I'll just mention that his insights align well with those in our recently released book, Open Source for the Enterprise. Subbarao ended with an invitation to work on the HP Linux Common Operating Environment (LinuxCOE).

David Heinemeier Hansson offered another interesting keynote about the philosophy that made Ruby on Rails a success. He concentrated on three reasons:

  • It places convention over configuration, meaning that the designers guessed what people want and try to provide the right defaults so there's minimal configuration. (People can override the defaults if they want.)

  • Change is instant: you don't have to recompile or copy something to a server; just refresh. (The language characteristics of Ruby make this possible: introspection, open classes, and code execution within class definitions.)

  • The system is complete and integrated, from JavaScript on back to the database engine. Nothing is left for the user to do in some other component of the system.

In short, "constraints are liberating."

Asa Dotzler, Community Coordinator of Mozilla Foundation, delivered a keynote on a few basic things the Linux community can do to bring desktop use to the masses sooner, such as slowing down library changes to ease application development, and cutting down on the slew of configuration options in applications. (Editorial complaint: nobody should talk about the confusion of configuration options in open source applications until they're tried to do something basic such as turning off color printing on Windows.) He pointed out that Linux enthusiasts like to concentrate on porting more and more hardware, but that a lot could be accomplished apart from hardware through "low-hanging" fruit such as the ones he described. An audience member mentioned that this philosophy of simplification lies behind the popular Ubuntu distribution.

Biologist Drew Endy discussed Open Source Biology in his keynote. On eBay you can buy equipment that let you change an organism's genome. There are many exciting (and perhaps scary) applications of this, but due to the imprudent legalization of patenting genes, many useful biological functions cannot be manipulated without permission from some discoverer.

Endy also warned about the quality of the programmed organism (this is the scary part), and risks of other intellectual property claims. In several notorious cases, GE crops have turned up where they shouldn't, because nature doesn't recognize property boundaries or license agreements. But Endy also asked whether reverse engineering would be possible or legal so that users could take control over their crops. He finished by saying that the public must be brought into these discussions, as with open source software, and announced the founding of an organization with this goal.

This is still nearly the only conference where I expect the keynotes to be interesting--and where they routinely exceed expectations. I expect OSCon to continue to increase in size, and for the field of open source to continue providing good fodder for it well into the future.

Earlier blog on this conference:

OSCon: Developers and testers as heroes

Andy Oram is an editor for O'Reilly Media, specializing in Linux and free software books, and a member of Computer Professionals for Social Responsibility. His web site is www.praxagora.com/andyo.