Podcast Patent: Busted

The EFF is starting up a new patent-busting project aimed at VoloMedia’s podcasting patent. Even if you’re a fan of software patents, it’s obvious bad patents screw up the whole intellectual property system. So I thought I’d check out if VoloMedia’s patent is legit, or if those cypherpunks at the EFF are onto something. Turns out someone beat VoloMedia to the punch by at least half a year.

VoloMedia applied for their patent in November 2003 but wikipedia’s history of podcasting mentions quite a few pieces of podcasting prior art. But it’s not good enough to say podcasting existed before the patent, therefore the patent is invalid. The real task is to figure out which prior art knocks out which of VoloMedia’s claims, and see if there’s anything left standing. So what are the actual claims? In their patent submission they’re laying claim to software that can:

  1. Subscribe to and automatically download from a feed of episodes
  2. Indicate new episodes are in the feed
  3. Sync the episodes to a portable device
  4. Sync to the device based on settings
  5. Sync to the device manually
  6. Share the episodes over a local network
  7. Limit automatic download based on feed priority
  8. Sync less than all of the feed’s episodes to a portable device
  9. Sync when the feed removes episodes

That describes every podcatcher available these days. But we’ve got to find out prior art published before the patent was submitted. So key is finding out what the state of podcasting was before November 19, 2003.

There are a whole bunch of standards docs (and conversations about them) from the people implementing this sort of tool. Searching around for the history of the RSS enclosure tag will find a bunch of people talking about downloading media through aggregators. But you don’t often get a big picture in these conversations, hardly anything focused on how the client actually goes about handling feeds.

But I did stumble accross Mark Pilgrim writing in February 2003 about some features in a brand new feed aggregator that sound a lot like the first claim in VoloMedia’s patent:

Ignoring for the moment all the things it doesn’t do yet (which all sound quite cool), it has one particularly disturbing feature: extracting full HTML content from linked RSS items. The feature is off by default, but once turned on (one checkbox during installation), every time it finds a new RSS item in your feed, it will automatically download the linked HTML page (as specified in the RSS item’s link element), along with all relevant stylesheets, Javascript files, and images.

But wait, there’s more! Deep in the comments, Kevin Burton mentions that one use case for sync is accessing that data on a PDA. Bam! Claim 3. In the same comment, he makes a big deal of the fact that this syncing only occurs based on user preferences, taking out claim 4. He later mentions the standard (and for patent purposes, obvious) way to indicate that a feed has been updated using ETags. Yes, that’s claim 2. And that second comment also mentions sharing NewsMonster downloads on the local network using the same protocol Apple uses in iTunes today, stardardized as ZeroConf. Claim 6, down.

Only syncing less than all the episodes so they fit on the device seems novel, if a bit obvious. The rest of the claims (manual sync, prioritized download, and syncing when a feed removes old content) were common in feed aggregators of the time. But considering NewsMonster’s coming soon features of the time, I’d bet that NewsMonster supported every single feature claimed by VoloMedia’s patent. I’d love to get my hands on an old beta 1 just to check.

For what it’s worth, podcasting is a terrificly successful and useful idea. It took plenty of great ideas to invent it and make it successful. And like it or not, those people who created it deserve the rights to those ideas. If Winer kept his RSS work to himself, it would still be as useful as it is today. But he gave it away and now everyone profits from his ideas.

The thing is, VoloMedia didn’t invent podcasting and they don’t deserve exclusive rights to it. So we’ve got to get rid of this patent, or we’re punishing all the podcasters, fans and real inventors that made podcasting awesome. If you’ve got any more information to help, get ahold of the EFF or let me know.

Damned Flickr

It must be very difficult to be a Daring Fireball. Not only must he suffer the indignity of being the world’s foremost Apple fanboy and a tragic follower of the Yankee franchise, recently he’s had to endure a little purple cowlick infringing on brilliant design.

So with a few minor changes to Mr. Knauss’s snarky swipe at our dear Yank, I’ve taken a comb to that little logo.

Damned Flickr

Damned Flickr is a userscript to make everything better. If clicking that link doesn’t just work, you’ll need to install a plugin for Firefox or Safari.

Smoke Testing for Profit

A coworker of mine wants to stub out our access to external services so our tests work faster and better. Trouble is, he seemed to be pointing at our end-to-end testing when he said he wanted to stub things. And that’s exactly where you should stub as little as possible.

But you ask, aren’t all the cool kids are using mocking frameworks? Yes, they are. And so should you. Especially in your unit tests. You should learn the difference between a stub and a mock. And you should remember that really complicated mock expectations mean you’re probably doing something wrong. And that the the harder it is to mock out side effect behavior, the harder it is to make concurrent and thread safe. But you should totally be using test doubles as much as you possibly can in your unit tests, and using the stupidest ones that could possibly work. If you’ve managed to build an app with good test coverage without test doubles, and didn’t suffer in the process, contact me immediately. I’ve got to see that in action.

But theres a maxim that you shouldn’t mock code you don’t own. Instead, it’s generally a good idea to stub out interfaces. And not just to externally developed services, but to externally developed libraries too. Totally makes unit testing more sane.

That’s because unit testing is about creating a suite of assertions that say “it’s not this part that’s broken”. If (and when) that test fails, you can be sure that something in the test is broken. But if that test does alot, then you haven’t got a clue which of the things the test does didn’t get done right. Which makes it about as useful as a bug report from my sister the graphic designer. Pleasant, better than nothing, but sightly twitch-inducing.

But you don’t want the external stuff doubled out in integration tests. Actually, I hate calling it integration testing. ‘Integration’ is what you do when you need to know the volume of a space. End-to-end testing has less sylables and actually means something. But I personally call it smoke testing as in home inspection. Because you really need to push stuff through every pipe to make sure it isn’t squirting out somewhere.

If you’re doing smoke testing, you shouldn’t be doubling out your services. And you really should be smoke testing. Cucumber makes this stuff dead simple. Especially compared to calling DOM events through the COM interface of Internet Explorer from inside an NUnit test. Cucumber tests are even obviously useful, unlike unit testing. They’re useful because they can check that your app actually does stuff. Just like you would do a million times if you didn’t know how to automate tests.

But back before you knew how to automate tests, didn’t you have the program set up to actually talk to everything it would actually talk to? So you’d know if someone updated the database, or reorganized the file system, or the network was down. At the end of the day, that stuff has to get delt with or the app won’t actually work. Which means it won’t make anyone happy. Which means you won’t get paid. Glum face.

So automating smoke tests means you know if you deserve to get paid. That makes it totally the most important testing you could do.

So why is my friend, who is no fool, trying to screw with the most important testing we have so that it wouldn’t actually tell us if we can get paid?

Because he isn’t, of course. He’s got a hankering for a different kind of test, sometimes called an acceptance test or an integration test or a functional test, depending on who you’re talking to today. I like calling them functional tests, but yeah, that’s at least as bad as ‘integration’. But the point of a functional test is to make sure that your code provides the functionality you expect. If the network is down, that’s not your code’s fault. Where unit tests exist to say, “it’s not this part that’s broken,” functional tests exits to say “it’s not my stuff that’s broken.”

Why would you need three different kinds of tests? If you’ve smoke tests to tell you if you can get paid, and unit tests to tell you if you’ve got bug regressions, what’s the point of functional tests? To winnow decision trees. When you get a bug report, the entire reproduction scenario is the functional test. The fencepost error that causes the scenario to fail is the unit test. As a developer with a good testing suite, functional tests can let you inject whatever you like into your app without having to fire up the debugger.

If your fuctional tests are working, then you know it’s not your problem. Well, it’s almost certainly your problem, but that problem is something more like sitting on the phone all day explaining the bug to your service provider’s tech support instead of twiddling with edge cases in the deepest recesses of your code.

So please, write smoke tests. Write other tests if it suits your fancy, and please write tests for any bugs you find to avoid regression. But don’t cripple your existing smoke tests in the name of TDD. Not unless you don’t care to get paid.

Prev and Next II: Electric Boogaloo

It seems Jonathan Palardy doesn’t like my old prev/next bookmarklets. He thinks I should actually include code that works, even if it means having people pull some javascript library from my site. So do I.

Trouble is, I don’t use those anymore. It’s a real hassle to negotiate Prototype to play nice with everyone else’s javascript, so I’ve moved onto a simpler approach. Like Mr. Palardy, I wanted something using something standard and with builtin support from modern browsers. But I thought I’d give CSS selectors a shot using the Selectors API, available in Firefox 3.1+, IE8, Safari 3.1+, and Opera 10.

What we want is very simple: elements with a rel value of prev or next. You find those easily with the CSS selectors [rel~=prev] or [rel~=next]. We need to get the link those elements are pointing to, so we just pull that from the href attribute. Finally, we tell the browser to update the document location with that URI. Like so:

location = document.querySelector('[rel~=prev]').getAttribute('href');

Of course, I took a second to wrap this stuff up as proper bookmarklets. Just drag these to your link bar: prev and next.

Attaching a payment service to your web identity

Chris speculated some about the way payment processors like PayPal can play nice in the digital identity arena. I don’t think anyone’s surprised that the big issues in identity today are heath data and payments. I do think that Chris has dropped the ball a bit by taking such a big picture view of the problem. He’s a designer and his real forte is envisioning how tech should look, and then pushing the right people to make it happen.

He needn’t bother too much for this, though, since the VRM Project has already done a great job at imagining how payment should look. With their r-button project, they imagine a common interface for payers and providers to exchange cash and services. They even have a nice icon to show that someone supports the r-button. Like the ever present feed icon, I think it would work nicely in the address bar.

The VRM Project even has a side project of the r-button called PayChoice, that is designing a way for users to pay exactly what they want, how they want. Admittedly, most businesses aren’t keen on selling their stuff for just a penny. But if you haven’t heard, there are Real World Famous People, like Nine Inch Nails and Radiohead, who are already doing business like this. If all it took was a WordPress plugin to install, you can be sure plenty of bands would do it too. But there’s a wider range of CreativeCommons smoking, GPL snorting, free-content loving creators who could use something a bit easier to use than a PayPal donate button.

Unfortunately, VRM Project people generally aren’t cypherpunks, crypto-system designers, or programmers at all. So while we’re got a pretty interface that would be great to use, the wires aren’t connected to anything. There’s no protocol, no implementation, nothing. So the next step is to figure out what what wires we need and what parts we can jack from the rusted Jeep in the backyard.

First of all, there’s got to be security. Just sticking your credit card number in an XML file and posting it on your site is not going to work. I’m not positive, but I’d bet some combination of OAuth and OpenID Attribute Exchange ought to be enough to keep private info safe. OAuth tends to use a segmented system so your payment info would only work with a single provider. And when that cute startup gets acquired by Zombie Hitler’s MultiNationalAcme Inc., you could revoke access to your cash with a click of a button.

Behind that basic security, you’ve got to have some server handling credits and debits. Secure payment systems get created all the time by crypto fans, but there’s a few modern examples that might fit the bill.

The first sort is a pretty close to how things work today. Typified by PayPay, you and your service have accounts in the same bank. You or the service request a transfer, both of you authorize it, and you both get proof that the transfer happened. OpenSocial Virtual Currency is a protocol designed to do just that. It’s strangely tied to the social network where all this would happen, but it seems like that social network could be a marketplace or something else very unlike today’s social networks. I’d be surprised if it weren’t easy to pull this protocol out of it’s social network shell and make it happen anywhere.

This sort of bank-centric has a lot going for it. The protocol is super lightweight, and most of hard security stuff happens behind bank walls. In fact, it’s pretty much the exact same thing as PayPal does now, with a little more automation. Just getting a common protocol to handle the things PayPal and Google Checkout do would make it much easier to support competitors and push innovation into the market. Unfortunately with this kind of protocol, a bank will have a hard time competing with big players. Since both you and the service have to have accounts at the bank, big banks will get more users. And without a protocol that tackles non-repudiation, you have to seriously trust the bank handling the transaction.

More powerful protocols can take care of that. They make sure that every transaction is safe and could let complete strangers exchange things without trusting each other. Protocols like ripple let you use whatever bank you trust and ensure the money gets to the service’s bank safely. In between, the protocol anonymizes the transaction so the service can’t see where you got your money and you can’t see where they spend it. It’s quite a bit like onion routing or using a darknet. Obviously, I’m much more keen on using a protocol that gives me more control over my information and my money.

None of these projects is exactly an Enterprise Turn Key Solution, but that’s okay. Back when OpenID started, there were a large handful of projects that did the same thing. But enter yadis and they could reuse components, fight on an even playing field, and slowly add the features of the others until OpenID eventually had everything in all the others. I didn’t think OpenID would win back then, but won because it got better faster than anything else. We need to get the same thing happening with payment processing. Getting them all to support OpenIDs and publish XRD services would be the first step to snowball into a real solution.

Next and previous page bookmarklets using prototype

I’m working on a few tools to do semantic web stuff in Safari. Since I’m just at the prototype phase, I’m handling this stuff with javascript. I just want to make some useful bookmarklets and be done with it. The trouble is I normally can’t depend on Prototype or jQuery to make my life easier.

Fortunately, Mr. David Hochman whipped together a little Protoype bookmarklet that pulls down Protoype wherever you need it. It’s pretty spiffy, but a bit special purpose. It depending on a script link to use an id of "prototype.js", which won’t always be true. Instead, you should check the value of Prototype.Version, which has the added benefit of letting your stuff be version dependent. Also, doesn’t everyone DRY out their code to the point that Huffman coding fails to improve anything?

(function() {
  var d = document;
  try { Prototype.Version }
  catch(e) {
    var s = d.createElement('script');
    s.type = 'text/javascript';
    s.src = 'http://scripts.example/prototype.js';
    d.getElementsByTagName('head')[0].appendChild(s);
  }
})();void(0)

To install this bookmarklet, just drag it to your bookmark bar or right-click and save. If you haven’t noticed, you’ll still need to point your script at a copy of Prototype. Version checking is left as an exercise for the reader.

But let’s not forget I hacked this up so I could use Prototype to a real end. Sadly it’s not RDF or microformats or HTML5. In fact, it’s just for a feature from HTML3.2, rel="next". I’m far too attached to Safari’s minimalism to suffer Firefox just for the plugins, and Opera just feels funny. Don’t get me wrong, it’s quite a nice sort of funny. I do enjoy using substances that make me feel pleasantly funny; I just gave up my habit of doing that all the time. Now it’s more of an occasional celebration. Say, in honor of passing acid. No really, the other Acid.

But I digress. I just want a simple tool to go back and forward. I know it’s in vogue to have little text hanging about the page that does that. But it’s also in vogue to say that the web will never supplant books. And that journalism is dying. Probably fnords as well. But I’m not that kind of gas-guzzeling, coke-drinking, twitter-checking sheep. No, I’m the other kind. Really, I’m glad they finally took the next- and previous-page buttons out of books. But they’re turning around that sort of innovation and putting them back into newspapersites. Come on!

So I proudly present to you—in this original, exclusive, and one-time event—my next and previous buttons. Once you’re done, lock up and turn the lights out.

Still No Reputation Networks?

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

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

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

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

Page 3 of 6