Still No Reputation Networks?

Tuesday, February 24th, 2009

I really want a decent reputation network. Reputation networks are simple concept. Many have tried, but they just haven’t been done well yet. None has brought science fiction’s imagination of the reputation network into reality.

Cory Doctorow’s Down and Out in the Magic Kingdom is the best fictional reputation network idea I’ve seen. Everyone uses its whuffie system, pervading its society like Google has ours. People would hardly have a conversation without checking your whuffie, seeing who strongly trust and distrust you, seeing who you mutually respect, who hate you both. Just like you’d quickly Google to research a bit of trivia.

But there is nothing yet like this system. There are networks where all your friends might have an account, but it’s hard to see what that social graph really implies. Still, there are some interesting tools today.

One of the first reputation networks was Pretty Good Privacy’s Web of Trust. Originally invented in 1992, there are a handful of good and free plugins to work with Outlook, Mail.app, or GMail in Firefox. And while I use PGP for all my email, I only have three people in my Web of Trust. Compare that to my Facebook friends or Twitter followers and it’s easy to see this old school reputation network is probably past its prime.

At the moment, Karmasphere and Naymz are the only companies trying to make whuffie real. Karmasphere is designed for programmers, not regular folks. It is just a database with reputation scores for certain identifiers like URIs and IP addresses. Naymes vaguely resembles a poorly designed LinkedIn with a reputation number tacked on. And it can’t manage to import much of the existing I already have spread about the web. So while these things aren’t well known or easy to use, they are out there.

The trouble with these networks is that their goal is to provide my One True Reputation™ value. Whereas PGP only says whether someone really is who they say they are. EBay ratings don’t mind if you are lying about your legal name, but they do care if you satisfy your customers. But startups like Grocio give real information we can use. Grocio just compares stores by reporting the prices of certain items. It doesn’t waste our time rating cleanliness, customer service or trendiness. It is hard data that we need while we’re getting used to searching to compare real things.

Eventually, places like Consumer Reports and the Better Business Bureau will start requiring claims be written by people who can prove they are who they say they are. That means if you won’t login with an OpenID or a X509 client certificate or a PGP key, then they won’t trust what you say at all. Once that happens, then I can decide if I want to trust your Yelp review based on whether you are someone I really trust.

XRD API

Monday, February 9th, 2009

Marc Canter has been talking about his idea of the Open Mesh, especially its dashboard. In the new web, I’ve got all my services spread all over. The dashboard presents a centralized place to tie all these outside services together. To actually make all of these things work together, there are a bunch of pieces missing. The dashboard needs a way to connect to these services, a way to group the people who can access those services, and a way tell those services what rights those groups have to access them. So this is the first in a series of brainstorming about the gaps in the OpenStack to be filled to make this work.

Today, plenty of people want to tie together their identity from different places on the internet. They maintain a list of their identities at Flickr, Twitter, Magnolia, Plaxo and Brightkite. If they’re geeky, they may even mark these links with hCard attributes, so those places are marked rel=”me”. The geekiest keep a single page showing everything happening at those services, perhaps with Plaxo or FriendFeed or an Activity Streams plugin on their blog. But when you’ve got an account over at Ma.gnolia, there isn’t a good way to push that service back to your OpenID so it can advertise that you store your links there. Right now, you have to collect those identities manually. Doesn’t that just smell ripe for automation?

If you use OpenID, there is a document somewhere saying all the services your ID supports. For the moment, the list of possible services is pretty small. Your ID might be able to send your registration information, like name and email address, or maybe your PGP key. But right now, there isn’t much you can advertise in your discovery document. There isn’t a way to send your photo gallery, your microblog, your bookmarks.

But even if there were, there isn’t a simple way to update those services. The way disco docs work today requires someone to manually edit the disco doc to add a service. Even if that disco doc is automatically generated, it’s probably only generating services for stuff the OpenID Provider knows how to play with. So your service provider needs a way to tell the disco doc it wants to play.

It shouldn’t be too hard to design a service where Ma.gnolia can send a request to be added to the disco doc. All it really needs to do is send what type of service it is, and where the service lives. Since an XRDS disco doc has a format for this info, it is natural to send it:


    <Service>
      <Type>http://ma.gnolia.com/links/1.0</Type>
      <URI>http://ma.gnolia.com/josephholsten</URI>
    </Service>

These services need to be able to be added to, updated and deleted. The Atom Publishing Protocol is a great example of a protocol to handle collections like this. The real trick is to treat the XRDS document as a service link collection and give each of these service links a URI so they can be updated and deleted. With this API, it would be simple to access the services attached to an OpenID.

But doesn’t that mean any site could post some new service onto your identity? Not if we ensure the service is authorized to post before we do anything. And the most powerful general purpose authentication protocol today is OAuth.

Most of the time, you know if you want the service attached to your disco doc when you log in at the service. Assuming it lets you log in with OpenID, your OpenID Provider can just ask you if it should also give the service access to add to your disco doc. If you agree, the OpenID Provider can send an authorized OAuth Access Token along when it authenticates you to the service. The service posts its disco information to your disco doc, and Bob’s your uncle.

But since the OpenID-OAuth Hybrid protocol is not finished yet, the service provider could just ask to get authorized to post to your disco doc itself. It would send you to your disco doc’s authentication endpoint, you allow access, and the service can then update your disco doc like before.

The great thing about OAuth is that it allows us to control exactly who can update the disco doc. A smart dashboard would allow you to delete a service, all the endpoints it created, and revoke that service’s access to your disco doc.

To wrap up, I’d like to mention some alternatives to an XRDS protocol modeled after AtomPub. First, this data shouldn’t be in XRDS, but microformats or RDF. I sympathize and am convinced there should be representations of this data as both microformats and RDF, but think XRDS is optimized for just this case. Alternatively, this information could be pushed back via an XML-RPC or SOAP protocol. But since the end result is to change an XRDS document, HTTP verbs are well suited to the actions that would actually be used, where an RPC implementation would simply reinvent standard HTTP procedures and unnecessarily confuse the semantics. Finally, this could be implemented as an OpenID AX pushback service. But as as I know of no services using AX, there is little precedent to build upon. Regardless, I only want the simplest protocol that does the job, so if you can present something better I will gladly support it. Whatever gets the job done.

OAuth for the IRS

Wednesday, February 4th, 2009

I am tired of giving out my social security number. If you have looked into digital identity technology recently, you have probably heard of the password anti-pattern. As Jeremy Keith puts it,

asking users to input their email address and password from a third-party site like GMail or Yahoo Mail is completely unacceptable. Here’s why:

It teaches people how to be phished.

The same thing applies to my social security number. Every time I give it out, I am making it a habit. I am accepting identity theft.

This anti-pattern has gotten a lot of notice recently as OpenID has gained use. OpenIDs are just a URI, and if some bank told the IRS that my OpenID had earned one million dollars interest this year, there would be no way for the IRS to verify the claim. That is, unless I gave that bank my OpenID password, which would prove that they really were speaking for me.

But what if that bank were broken into? If some thief gained access to the bank database, they could go around acting like me until I changed my password. They might even be able to set my password to whatever they wanted wanted with that information. So giving out my password, even to my bank, is a bad idea.

To fix this problem with OpenID, a group of people developed the OAuth protocol. OAuth doesn’t need you to give your password to your bank. OAuth works by having your bank ask your OpenID provider for permission. Then, you can log into your OpenID provider, grant permission, and the bank gets to prove that you really are who you say you are. Entirely without giving your bank the sensitive information that would be lost in a break in.

Now, it is possible that the bank could be broken into. They would still have some OAuth credentials that the thief could use to claim to be you. But OAuth has already thought of that. With OAuth, you can revoke those credentials at any time. If your bank gets nationalized by the Fourth Reich of Zombie Hitler, have no fear. One click and there is nothing the undead national socialists can do.

But today I still need to give my bank my real and entire social security number. That is all some crook needs to ruin my credit. I have no way of revoking that information. In this modern age, this needs to change.

The IRS needs to stop making us give irrevocable identity information to everyone who asks. If I sign up for a job, let me log into the IRS web site and create a unique tax identifier for that employer. If and, given today’s security climate, when their human resources database is broken into, no big deal. I just need to log into the IRS site and let them know the identifier needs to be revoked. No more would illegal immigrants pretend to use my social security number. No more would criminals apply for loans and credit cards in my name. All because the government started using secure identity.

While I am a big fan of OAuth, it is not the first protocol that could handle this trick. Kerberos and WS-Trust and perhaps many others could be made to do the job. Of course, I like OAuth because I have been involved with it, and because it was designed for just this problem. But it is being reworked for a formal standard today in the IETF. Much is my love for OAuth, but if government is in the place to make these changes now, they will need to use something else. And I would rather have my identity be safe than wait for my pet protocol to be finished.

We Wear the Mask

Sunday, January 25th, 2009
We wear the mask that grins and lies,
It hides our cheeks and shades our eyes, —
This debt we pay to human guile;
With torn and bleeding hearts we smile,
And mouth with myriad subtleties.

Why should the world be over-wise,
In counting all our tears and sighs?
Nay, let them only see us, while
    We wear the mask.

We smile, but, O great Christ, our cries
To thee from tortured souls arise.
We sing, but oh the clay is vile
Beneath our feet, and long the mile;
But let the world dream otherwise,
    We wear the mask!

Paul Laurence Dunbar

Getting into Open Government

Thursday, January 22nd, 2009

Obama has written two memoranda making it clear he intends to encourage an open environment so the public can access the data it pays to create. He wants to create an Open Government Directive to make that happen. The Office of Management and Budget is charged with recommending what that should entail. And I have a few recommendations.

If the folks developing the semantic web want to make it happen, this is the perfect opportunity. Whether you support microformats or RDF, the only way to really access this data is to get it marked up. That means people need to get in there and dig around the data that is being released. Draft profiles, sketch vocabularies, but if there is not a way to mark up this data, it will not be done. If it does not happen now, it will not be cleaned up before another administration.

There are some things that can happen immediately. Obama has released two executive orders already. It is great that he is doing work, but here is an example of data that needs to get marked up:

Section 1.  Definitions.  For purposes of this order:

(a)  "Archivist" refers to the Archivist of the United States or his designee.

(b)  "NARA" refers to the National Archives and Records Administration.

(c)  "Presidential Records Act" refers to the Presidential Records Act, 44 U.S.C. 2201-2207.

(d)  "NARA regulations" refers to the NARA regulations implementing the Presidential Records Act, 36 C.F.R. Part 1270.

(e)  "Presidential records" refers to those documentary materials maintained by NARA pursuant to the Presidential Records Act, including Vice Presidential records.

See all those references to executive positions and legal statues? Every last one of those should be a link. Each of these defined terms should be entities in this document. When those terms are later used, they should be links to the formal definition.

I am not saying it is President Obama’s obligation to mark up legal documents. But whoever is editing these drafts needs to have the tools to make it easy. But what is the way to do this now? I do not know.

To

Saturday, March 1st, 2008

Regarding passion.

There is not any “grand, magnificent, all-encompassing design” and there never was or will be.

What looks grand and designed in hindsight is the just like seeing design in the free market. There is no watchmaker. Just billions of choices, good or bad.

So fuck the driving forces, and make a passionate choice now.

To Insure Proper Service

Wednesday, October 31st, 2007

Gmail IMAP + Mail.app is nice. Note that you may select the gmail Drafts, then go to Mailbox → Use This Mailbox For → Drafts, and so for each gmail message. You may also archive a piece of mail in the inbox by dragging it to All Mail. You may move another piece to to same place with Command + Option + T.

Oh how time slips away

Monday, October 1st, 2007

I’ve been a user of Harvest for a number of months now. I’ve gotten a few people on it, and enjoy it thoroughly. I’ve tried Tick, but a time tracker without a timer is (grasping for metaphor) worthless (clear language is better than colorful ambiguity, right?).

However, I’ve just given SlimTimer a try and am unsure of harvest’s future. Basecamp integration is awesome, yes. But do I have to have project constraints on my users? Estimates? No.

Of course, I could convince my employer to adopt harvest. Their time tracker is a horrible mess, but build with the same goal in mind. Estimates, employees constrained to a finite set of projects, spiffy API.

I will ponder this problem for perhaps the next month, since I just payed the harvest bill. We’ll see.

Fat client leacher

Sunday, September 23rd, 2007

Would it surprise you that I use fat clients for most internet stuff? That’s right, most of the apps I use are for cocoa or win-forms. The blogs I read, the mail I send, the music I listen to is rarely housed in safari, internet explorer, or firefox.

That’s because I don’t have internet at home. I’m a computer programmer, director or leading member of a handful of local computer groups, occasional podcaster, blogger, and really bad web designer. I have been working on replacing the traditional operating system with a web operating system since 2004. Ironic, no?

But while I’ll pay to get a current of electricity and water, or some walls with a roof, I’m not going to pay to talk and listen to you. If my parents didn’t value talking to me so much, I wouldn’t have a phone. I don’t have cable, satellite, and barely listen to radio. These things are synchronous, so for them to get my attention it has to be on their terms. Same goes for instant messaging.

Synchronous info can be great. There’s nothing like being able to talk to a loved one when you can’t be with them. There’s nothing like live video when you want to watch a game, see breaking news, enjoy your favorite show as soon as it airs. But I don’t need to hear about bills, see your latest fishing photos, read the latest company memo right now. And the best way to take synchronous info and hold it for asynchronous access is a fat client, bar none.

Most people are amazed at how tivo changed the way they watch tv. But you can do the same with almost everything. Do try.

Propertied Intellectual?

Sunday, September 23rd, 2007

Steamboat Willie opens a gap in the New York Times. Or rather, Disney’s copyright lobby prevents access to New York Times archives.

Doesn’t it make sense to allow use if no copyright holder can be found? Trademark holders have to defend their property, why should copyright holders be any different?