On September 1st, Derek Webb released his Mockingbird album online for "free" in MP3 format at freederekwebb.com. There is much hullabaloo over whether or not it's really "free" because you must supply your name, email, zip code, and are required to invite 5 friends via the web application before downloading the album. I don't think it's "free", but that's not what this post is about. You can read more about my thoughts on the matter at Kat's blog.

My intent with this post is to make you aware of the technical aspects of the Free Derek Webb application. I do not intend to defame Derek Webb. I personally think he's a great musician with a great message. However, I do intend to show why the application makes me a little nervous.

Aspect of Uneasiness #1: Step 1 is independent of the other steps.

The web application is one of those newfangled AJAX applications. This basically means that the page can communicate somewhat transparently with the server without needing to refresh the entire page.

When you hit the "Next" button in Step 1, your name, email, and zip code information is sent to the server via AJAX. The server then returns "true" and Step 2 is enabled.

Here's my problem with this: When I get to Step 2 and realize that I am required to submit 5 friends' email addresses, I may decide the price for the "free" album is too high and leave the site. Without having actually downloaded the album, I tend to think that I have not participated at all. But, is my name, email, and zip code already in their database? Have I been signed up to the newsletter when I think that I may not have because I didn't complete the full transaction? I can't say for sure, and that doesn't seem right to me.

Aspect of Uneasiness #2: Why send it from my email address?

the cachinnator made a good observation in the comments of Shaun Grove's post:

And be straight: the email does not come from you. It says that it comes from you. But you are not sending that email. Derek's server is. And that's part of the problem.

Email is inherently insecure in terms of authenticating the source sender, and you can spoof anyone's email quite easily. The Free Derek Webb application takes advantage of this, allowing the sent email to appear as if it came from you. In general, I think this is not good practice. It's also quite likely that mail servers adhering to strict Sender Policy Framework (SPF) rules would reject the email as spam because the sending IP did not match with the sending domain's SPF record.

I would have preferred the application send from their own address, say free@freederekwebb.com, and then use your email address in a Reply-To: header.

Aspect of Uneasiness #3: What's that "lid" parameter on the end of the link?

When you put a friend's email address in for Step 2, they receive an email that looks something like this:

Note: I wrapped the long lines for readability. There is no line break in the link.

Your message to your friend.

To download your free copy of Derek Webb's new album,
   Mockingbird, click the link below: 

http://www.freederekwebb.com/pages/
   index.aspx?lid=MTcxMTc1OjM3NzA1OmN1cnQuaXMuc3VtbWVyc0BnbWFpbC5jb20=

Uh-oh. What's going on here? Why isn't the link to the website just "http://www.freederekwebb.com"? What's that "lid" parameter appended to the end of the link? I'm getting nervous.

As a programmer, the contents of the "lid" parameter look familiar to me. It's Base 64 encoding, which is an obfuscation of the data. It's also used to encode binary files, such as an email attachment of a jpeg, into ASCII text. You can decode your Base 64 encoded "lid" with an online decoder such as MAKCoder.

Let's see what's in the "lid" parameter from the message above.

Sent to: curt.is.summers@gmail.com
Encoded lid: MTcxMTc1OjM3NzA1OmN1cnQuaXMuc3VtbWVyc0BnbWFpbC5jb20=
Decoded lid: 171175:37705:curt.is.summers@gmail.com

Yikes. We have two numbers and the email address delimited by colons. Let's look at a few more to see if a pattern develops:

Sent to: curt.is.sum.mers@gmail.com
Encoded lid: MTcxMTc4OjM3NzA1OmN1cnQuaXMuc3VtLm1lcnNAZ21haWwuY29t
Decoded lid: 171178:37705:curt.is.sum.mers@gmail.com

Sent to: cu.rt.is.su.mm.ers@gmail.com
Encoded lid: MTcxMTgyOjM3NzA1OmN1LnJ0LmlzLnN1Lm1tLmVyc0BnbWFpbC5jb20=
Decoded lid: 171182:37705:cu.rt.is.su.mm.ers@gmail.com

Sent to: c.u.r.t.i.s.s.u.m.m.e.r.s@gmail.com
Encoded lid: MTcxMTg2OjM3NzA1OmMudS5yLnQuaS5zLnMudS5tLm0uZS5yLnNAZ21haWwuY29t
Decoded lid: 171186:37705:c.u.r.t.i.s.s.u.m.m.e.r.s@gmail.com

Note: I felt it important to show actual examples without invading others' privacy, so I used the dot ignorance feature of gmail to create several email addresses.

The first number appears to be an ID attached to the referred friend. It's roughly sequential, which means that other people were submitting their friends' email addresses at the same time I was.

The second number, 37705, is constant between the examples, so I'm assuming it's the ID number of the original sender (the referrer). If we assume the number is sequentially assigned, then I was the 37,705 person to signup–which actually jives with the 35,000 number reported by the Tennessean on 9/14/06.

The inclusion of the email address in the "lid" was most likely enabling an automatic fill-in of the email address for Step 1. When I originally clicked on one of my referred links on September 1st, my email address automatically popped up in the Email field on Step 1. The test run used for this post ran on 9/16 and did not show this behavior, so I'm assuming they changed it.

It's likely that the two ID numbers–mine and those of my friends–allow Derek and the web developers to track the percentage of successful referrals back to the site. That's neato for them, I'm sure, but a little scary to me.

Here's the problem: Why do you really need to pass those ID's in the link? If your intent is to just get the word out about the album, then you don't need those ID's, and including them makes me nervous about what you could track if you wanted to. By passing the ID's you could feasibly build a very large graph of relationships.

My conclusions

Derek's privacy policy may be rock solid, but the application does not reflect the spirit of the policy. The use of technology, especially in regard to privacy, must not hint at any impropriety.

To me, this application's original intent appears to be to track not only the initial sign-ups, but all subsequent relationships. That's what a viral marketing application does. Derek probably intended to disable and/or ignore some of the features for his particular needs.

I welcome your comments.