Mark Trapp. Blog.

Twitter Lists Make Twitter Dangerous to Use

Mark Trapp — Thu, 29 Oct 2009 18:43:08 +0000

Bottom Line: Twitter implemented lists in the riskiest way possible, and using Twitter after it has been rolled out puts yourself at risk.

Updated at the end.

The big buzz in the social media world lately revolves around Twitter's rollout of its "list" feature, which allows you and others to create lists of your followers: easily tagging them so you can share those lists with others. Robert Scoble thinks it's a game changer, and is pushing the value proposition for them hard. But I think lists, because they have no consent mechanism and because they can be made public, are boneheaded, broken, and ultimately make Twitter a dangerous tool to use for anyone who values their reputation.

Three Strikes: You're Out

Twitter made three colossal mistakes with its list implementation:

Lists are public,
Lists a person has been categorized in are available on that person's profile, and
Most crucially, a person cannot consent to the categorization.

This makes lists a wholly individualized action: I have the ability, with no accountability, to categorize anyone as anything and make that categorization public and attached to that person, like a scarlet letter. Because all lists are treated equally, my categorization doesn't get marginalized or ignored. On the contrary, the most I make my categorization stand out, the more it'll be noticed.

Take a look at Robert Scoble's list memberships: he's in about 1,100 lists, most of them are "technology guy" or something similar. If I, say, put him in a "child molester" list, or a "douche bag" list, which one do you think stands out? The sea of "tech" lists, or the really offensive one?

So Long, and Thanks for All the Spam

Beyond the libelous or defamatory possibilities, public lists are now a great avenue for spam that you can't opt-out of or protect yourself in any way. Consider my list memberships: I'm on two generic technology lists. Great: now all a spammer has to do is to target technology people and I'm included. I can't change that, because someone else decided to categorize me.

You might be thinking that's just the risk you take by having a public feed: spammers targeted people based off of keyword searches even before lists. So, go back to the public publishing of lists aspect: now, spammers can categorize me in their "cialis" or "seo-for-less-seojackass-dot-net" lists, and they now get free advertising that's attached to my Twitter profile. A whole new avenue for making Twitter useless! Awesome!

Make an Informed Choice

It's odd that in all the coverage about how awesome Twitter is now because of lists, that people haven't picked up on this, or chose not to care. But if Twitter lists go unchanged, one seriously needs to consider how valuable Twitter is for them or the risks they are taking by using Twitter as a communication medium. It's now just become easier to have Twitter bite you in the ass without you having to tweet a single sentence.

Twitter needs to take a few simple steps to make lists less risky: remove lists from being attached to a person's profile and they could allow people to opt out of lists. More comprehensively, they could turn off public lists or make list memberships opt-in (like groups work on Facebook and FriendFeed).

Update: Robert Scoble responded, pointing out that you can block lists. I believe he's referring to being able to block the list creator, which does remove you from any list that they created and prevents them from adding you to a new list. It shouldn't require a block action to opt out of a list, though: I should be in control of anything attached to my profile. My two basic requirements still stand.

Update 2: Lively discussions are taking place on FriendFeed; on Robert Scoble's feed and on my feed.

The Dirty Little Google Voice Secret

Mark Trapp — Mon, 12 Oct 2009 17:42:24 +0000

Bottom Line: Using two features from Google Voice and AT&T, you can maximize your Google Voice usage on an iPhone (or any other iPhone) in spite of the public bickering between the companies.

If you use Google Voice, have an iPhone, or are interested in smart phones, you’re probably aware of the ongoing spat between Apple, AT&T, and Google over network neutrality and Google Voice on the iPhone (c.f. Apple’s take, AT&T’s take, and Google’s take). If you’re like me, you don’t really care who’s to blame for why you can’t use Google Voice on your iPhone: they’re probably all at fault.

You may not be able to use a shiny application for Google Voice on your iPhone, but you can use relatively new or unknown features of AT&T and Google together and against them and wind up saving a nice chunk of change in the process. This is for all phones, not just the iPhone, but if you’re an iPhone user, I’d say it’s not a bad consolation prize. I’m going to talk about two features: Google Voice’s outbound calling and your wireless carrier’s calling circle feature.

Google Voice, Call Proxy

One of the relatively obscure features of Google Voice is its outbound calling functionality. Prima face it’s not obscure, but lots of people think it’s only useful for international calling: Google Voice has cut-throat rates to many countries. But the feature also works domestically, and it’s a great way to mask your phone number so it looks like you’re calling from Google Voice. If you use Google Voice like I do, I don’t give out any number but my Google Voice number, and it’s a boon not to have any other number floating out there by virtue of someone’s caller ID.

To use this feature, you simply call your Google Voice number from a phone linked to your account. When you get the automated voice, dial your PIN and press 2. Then dial the number you wish to call and press pound. Google Voice will connect you directly that’s that. Works pretty much like a calling card.

I hate Chad, too.

If you’ve watched TV in the past 5 years, you’ve probably seen a commercial (or seven) for Alltel where Chad talks about a calling circle, where you can talk to a select group of friends for “free” (read: part of the expensive plan you’re already paying):

Chad’s a dillhole, and Alltel was bought out by Verizon. But nowadays, every major carrier has their own version of a calling circle: Verizon has Friends & Family, T-Mobile has myFaves, and AT&T just came out with A-List. If you talk to a small set of people a lot, these calling circles are a great cost savings.

You got Google Voice in my calling circle!

You can probably see where I’m going with this: add your Google Voice number to your calling circle and call it before calling your destination. Since the call is routed through your Google Voice number, your carrier doesn’t know the end point, so it charges you whatever it charges you to call your Google Voice number, which is nothing.

I used this trick this month to go from 1,500 minutes used in September to 137. The only reason I have 137 minutes used was because I was too lazy to dial my Google Voice number, or someone called my cell phone directly. This means I can drop my really expensive unlimited calling plan and pick up the cheapest, 450 minute plan for a cost savings of $70 a month. Think of all the ponies you can bet on with that found money.

Caveats and Disclaimers

If you use Google Voice the way I’m using it, you’ll likely miss not being able to use your built-in address book (you’ll have to dial numbers the old fashioned way, one number at a time). This is where a Google Voice app that integrated your cell phone’s address book would truly come in handy. But I think it’s a small price to pay to save $70/month on unlimited calling.

The other caveat to keep in the back of your mind is the clause that your carrier may have (AT&T, for example, has it) that they can block a number from your calling circle at any time for any reason. I charge that this is against the spirit of network neutrality and is likely to be against FCC regulations. If they block my Google Voice number, I will take AT&T to the mat about it, and so should you if they pull that on your Google Voice number. AT&T and the other carriers have caved when they are called upon unfair practices, and they have repeatedly shown that to raise a big stink is the only way for them to stop infringing upon consumer rights.

But that’s a different story altogether. For now, enjoy being able to use Google Voice to do something pretty useful: save a chunk of change.

OAuth for Dummies

Mark Trapp — Thu, 17 Sep 2009 17:30:09 +0000

Bottom Line: OAuth is a tricky beast, but once the general workflow is worked out, it's more tedious than difficult.

One of the projects I've been working on instead of updating this blog has been a set of modules for Drupal that allow FriendFeed users do all sorts of interesting things. While I'm not ready to release the details of those projects, one of the biggest mind-benders I've experienced in my work has been OAuth, a technology FriendFeed uses as its preferred authentication mechanism in the latest version of its API.

It took me a while to figure out how exactly OAuth works: either the information on the web is very bare, or I'm just very dense. But I did eventually get a working OAuth client up and running, and if you've been struggling to wrap your head around the OAuth concept, hopefully the workflows I provide here can help you.

One can easily get overwhelmed with all the stuff you have to do when using OAuth, so I'm going to present the workflow several times, starting with a very high level overview. Each successive explanation will add more detail such that, if I did my job right, repetition will help reinforce everything.

This guide should be helpful for any OAuth scenario, but for explanation's sake, I'm going to use the following terminology conventions:

MyApp, or the client: this is the web site that wants to have access to a user's private resources.
John, or the user: this is the user who is using MyApp and wants to allow it to access his private resources.
FriendFeed, or the server: this is the web site where John is a member and stores his private resources.

The 100,000-foot View: Basics

OAuth, at its very heart, is just a fancy way to authenticate with a server. When it's all said and done, you are given essentially a user name and password, and you use that pair to access a user's private resources. The spin that OAuth adds to basic authentication is based on two parts:

OAuth never divulges the user's actual user name and password to the client.
The user can go back to the original application and revoke the client's access to their content.

If you've ever had to create a guest account on your computer or temporarily give a spare set keys to someone so they could water your plants, you know the basic idea. You are allowing someone else to access something private, but you're in control of when and how they access it.

The 50,000-foot View: What the User Sees

So far so good. Now, we need to talk about how that access is granted. If you were getting your plants watered, you'd just meet up with someone and physically hand over the keys: a relatively secure transaction. OAuth attempts to replicate and expand upon that level of security by providing a means to explicitly say "I want this client to have access to my stuff" and a means for the client to prove who it purports itself to be. It'd be like if you ran a background check on your friend before you gave them your keys, and kept looking at their ID as you handed them off.

So how does an OAuth client do these things? With a lot of handshaking. A lot. To the point where, if someone shook your hand that much, you'd be thinking about a restraining order. But let's hold off on what the client does and just outline what the user experiences:

The user, John, visits the client, MyApp, where he sees MyApp can do cool things with his private information stored on a server, FriendFeed.
MyApp advertises these cool things, and beckons John to "sign in with FriendFeed": essentially, to allow MyApp access to John's FriendFeed account.
John clicks on the sign-in button, which initiates a negotiation process between MyApp, John, and FriendFeed.
MyApp performs, shall we say, "deep magic" to prove to FriendFeed it is who it purports to be.
FriendFeed agrees, and MyApp then sends John off to FriendFeed.
On FriendFeed, John is asked whether or not he wants to allow MyApp access to his private data.
If John says "yes," FriendFeed sends him back to MyApp.
MyApp does some more deep magic, and finally receives a specially made ultimate set of keys, which it can now use to access John's private data.

Once MyApp has this last set of keys, all hope is not lost for John: at any time, he can go back to FriendFeed and revoke MyApp's set of keys. For further information, I suggest watching the classic Seinfeld episode, "The Keys:"

The 10,000 Foot View: the Client's Deep Magic

If you have seen "The Keys," you might remember a scene where Elaine and Jerry are confusing themselves about who gets what key. I've found OAuth to be just as confusing: there's a lot of handshaking, a lot of key passing, a lot of agreement, and in the end, everyone's left confused as to what just happened. This is where the client's deep magic comes in. Before MyApp can access John's private resources on FriendFeed, it needs to do 4 things:

It needs to register with FriendFeed and receive its first set of keys: a consumer key and a consumer secret. This is done by the developer going to a special webpage (in FriendFeed's case, this page is within their API documentation).
Once John clicks on "sign-in to FriendFeed," MyApp then needs to take the first set of keys it received (the consumer key and consumer secret) and use them to sign a special request to FriendFeed for a new set of keys, called a request token.
Once MyApp has the request token, it needs to send John back to FriendFeed with the request token. There, John is asked to allow or deny MyApp's request to access to his data.
Once John allows MyApp access to his data, FriendFeed sends John back to MyApp and tells it that the request token is "authorized." MyApp then needs to take the request token and use it to sign a new request to FriendFeed for a third and final set of keys, called the access token.

Once MyApp has the access token, it can then use it to sign requests to private resources on John's behalf: it now has access to John's private data to do whatever it needs to do.

The 1,000-foot View: Implementation

If you've gotten this far and understand what's happening, you're in great shape: most of the conceptual work is done. Now, let's discuss how to actually implement all the different parts. At this point, you're going to want a library to do the heavy lifting for you. OAuth has its own set of official libraries, and they're likely a good starting point for many languages.

When you registered your application with the server, you should've been given a bunch of information. At a minimum, you'll need the following to continue (if you don't have this information, check with the server's API documentation to fill in the missing pieces):

A consumer key
A consumer secret
A request token URL
An authorize URL
An access token URL

The basic methodology in working with OAuth is that you make requests just like you would unauthenticated, but with several parameters attached that'll act as a way to prove the request is legitimate. These parameters include:

The consumer key and consumer secret.
A token and a token secret. These are the keys I've been talking about. You'll use a specific set of keys depending on where you are in the handshaking process.
A nonce (short for number used once). This is a random string or number that's used for exactly one request.
A timestamp
An OAuth version number: it's currently either 1.0 or 1.0a: consult the server's API documentation to figure out which one to use (it's likely 1.0a)
A signature method, explained below
A signature, also explained below

If you're using a library, it's likely most of this information is abstracted and you don't need to worry about anything other than supplying the correct token, token secret, request URL, and signature method. Check the library's documentation and especially the examples of the client to see how to build the signed request URL.

But let's talk about the the last two parameters, the signature and signature method, To prevent a variety of attacks, it's a good idea, and in many cases required, to sign all requests with an encrypted signature. There are currently three signature methods that I know to do this: HMAC-SHA1 (seems to be the standard), RSA-SHA1, and PLAINTEXT (insecure, should not be used unless all the other parts of the handshake are encrypted). The signature method is merely one of those strings: HMAC-SHA1, RSA-SHA1, or PLAINTEXT.

To get the signature, however, is much tougher. This is where the library comes in especially handy. Most libraries will take the request URL, the token and token secret, the method by which you're requesting the URL (GET or POST), and the signature method and provide the correct signature. Easy as pie.

Getting the request token

The general starting point for the user is to have a nice little button that, when clicked, performs the OAuth handshaking and signs the user into the server. So, what you'll need to do is link the sign-in button to a page on your server that'll retrieve the first element of the handshake process: the request token.

To get the request token, you'll make a signed GET request to the request token URL and parse the results you get back. For the request token, you'll sign the request using the consumer key and the consumer secret. Since you don't have any tokens, you'll omit the token and token secret parameters.

If you did it right, the request token URL will provide a new token pair: an oauth_token and an oauth_token_secret. This is the request token: you'll use this for everything else in the handshake process.

Getting the user's consent

Once you have the request token and token secret, you're going to need to get the user's explicit consent to allow access to his data. Store the token secret somehow (maybe a secure cookie or somesuch), and redirect the user to the authorize URL with certain parameters:

The request token (just add oauth_token=<token>, where <token> is the actual token)
The callback URL: this may be ignored or optional due to security concerns. If it's not allowed, usually you'll specify it when you register the application with the server. The callback URL is where the server should send the user once he consents.

If you did it right, the user will be redirected to the server, which will display a page asking the user to allow you access to his data. Once the user clicks the button to allow access, the server will redirect back to you at the callback URL with the request token as a parameter.

Getting the access token

At this point, the server has acknowledged the request token you have is authenticated, and can be used to get the final set of keys, the access token. Make a signed request just like you did with the request token, but to the access token URL. Since we now have a token and token secret (you remembered to store the token secret you got back when you got the request token, right?) to use, add those parameters back.

If you did everything right, you should receive a new oauth_token, a new oauth_token_secret, and some additional information from the server that'll likely identify who the user is on the server. Trash the request tokens (they're useless now), and store the information you just received: this is your access information, and will be valid until the user revokes your access.

Accessing Private Resources

Once you have received the access token, it's pretty straightforward. Make requests to private resources, but sign the requests just like you did with the request token and access token. Instead of omitting the token and token secret or using the request token, use the access token.

The Ground-Floor View: Details, Details!

I wanted to go through and discuss the conceptual and basic implementation parts to provide a good foundation to do OAuth work. I've glossed over some of the finer points, but you should be in a good place to understand the OAuth spec as well as considerations people will discuss. A good place to start getting into the details of OAuth is the spec itself, which explains in far greater detail all the moving parts and options.

Here are 3 things to consider:

You're probably going to want to have your own user structure on your application, so you can tie an access token to an account and keep the user from having to keep re-authenticating your app.
The access token and access token secret are functionally equivalent to a user name and password, and should be treated as such. Keep the information secure.
You'll need to do something if you try to access a private resource with a revoked or invalid access token. Maybe check for that and run through the handshake process again?

Hopefully, you're thinking about all the ways you can use OAuth to do good work, like extend Twitter, FriendFeed, or Facebook. If there are any points that are confusing, or if you're an OAuth wizard and see I made some glaring mistakes, let me know in the comments.

Update: In the comments, Benjamin Golub points to a really neat tool, Google's OAuth Playground, for creating and testing out signed requests. Definitely check it out to understand how request signing works and what types of responses you should be expecting when you request a token.

Dr. Private Message

Mark Trapp — Wed, 15 Apr 2009 16:54:42 +0000

Bottom Line: We ought not to fear because the problem of private messages is too hard: we ought to fear because we've already solved them yet won't use that knowledge.

Or: How I learned to stop worrying and love the web

Today, Alexander Van Elsas had a sort of 95 Thesis/20 Questions amalgam about a host of issues involving the state of the internet today. One set of questions provoked a couple points of discussion from Rob Diana and John Bredehoft:

Networks and destinations

If everything becomes open and connected, what will happen to the big destinations?

Why is the web rapidly evolving into uncountable databases with connections, instead of one database where everything connects?

If all services and destinations become open, then what is the point in being a destination site in the first place?

Why are we creating webs within webs, instead of one network that connects it all?

Rob Diana suggests that your email inbox might be the gateway for all of these siloed communication systems, or that the messages from these systems might be pushed to one specific user destination (be it email or something else, like a cell phone).

John Bredehoft, in a comment to Rob's post, argued that we need to have multiple destinations, as each destination is a context in and of itself: one communicates with FriendFeed friends on FriendFeed, or Facebook friends on Facebook, or email friends through email, to ensure maximal participation.

John and Rob touch on two parts of the greater communications problem, but there's something unsatisfying in both of their answers, especially as it relates to Alexander's final question: why are we creating webs within webs, instead of one network that connects it all? I think the answer to this question is likely a house of cards: we should be creating a network by which we can tie these all together. A revolution? Not really: this is the foundation of many of the oldest communication systems on the block: DNS, telephony, and email.

United Federation of Messages

Federation, a term that seemed to come into vogue with the rise of XMPP, describes a concept that's been around for decades, long before web 2.0, and long before there was an internet. It basically entails the following:

There is one standard, vetted by the community, by which all participants should conform. Some parts of the standard should be baseline: all participants must implement it. Other parts of the standard might be implemented by many or few of the participants.
All destinations have a largely unique piece of information to identify themselves to the greater network of participants. For email, it's your email address. For DNS, it's a name server. For telephony, it's a phone number.
The standard must identify the logical path a participant must take in order to reach a uniquely identified destination. In most instances, this is a concept called routing and it identifies computers (routers) that will relay messages to other computers to ensure messages reach the proper destination.

Federation works brilliantly. Because of these three criteria, I can set up a computer made of scrap parts in my bedroom that can send email to anyone in the world and serve DNS. It doesn't matter who participates: everyone has more or less equal access to everyone else. This is a concept called network neutrality. You may have heard about political issues involving this: it's currently a right protected by most governments because of the value of federation.

Facebook is not the standard

Somehow, the concepts of network neutrality and federation have been lost with the rise of web 2.0: even though everyone talks about "open APIs", "transparency", and other buzzwords, nothing really talks to each other. Each system implements its own standard, and leaves it up to everyone else to figure out if and how they want to communicate with that system.

To use email as an example: imagine having 100 competing systems of email where none of them talk to each other. You have to have 100 different email addresses in order for it to work. Some enterprising individuals have come up with ways to link email addresses together (so you can have one email address), but it only works on about 5 of the email systems, and requires you registering yet another email addresses (so now you have 101).

We're into silly territory, but this is the state of the web, and more importantly, messaging, today. But this problem has already been solved, over and over again: there's no reason to come up with a completely new method for handling the multitude problem.

Where has the cabal gone?

Attempts at interoperability, via "standards" like OpenID, OpenSocial, OpenMicroBlogging, are primitive and re-imagine tried and true concepts. A lot of times, the advocacy of such technology feels like a guy marveling at his ability to make a fire (which he claims he invented, and calls it OpenMiracleLight) a thousand years after fire was perfected and turned into all sorts of useful things, like heating and electricity.

Back in the 70s and 80s, there were tons of smart people who came up with the standards for the backbones of technology we use today: what happened to them? Why isn't their work being used to progress the web?

They say those who don't learn from history are doomed to repeat it: why do we need to keep resolving the same problems?

Real-time Killed the Web 2.0 Star

Mark Trapp — Mon, 06 Apr 2009 23:40:04 +0000

Bottom Line: The real-time web renders the old web 2.0 convention of following tons of people obsolete: filters replace follows, and trying to maintain the old order will break your user experience of what's to come.

Today, FriendFeed unveiled a redesign of its product, focusing on real-time communication as a principle design goal. Expectedly, there are more than a few detractors of the decision to place real-time at the forefront (see Steven Hodson's post on Inquisitr, Michael Arrington's post on TechCrunch, or do a search on FriendFeed). I think they're stuck in a paradigm that's lasted for years that real-time has now rendered obsolete: the "follow."

Dunbar Was Right, Scoble Was Wrong

One staple of social psychology is the concept of Dunbar's Number: that there's a cognitive limit to the amount of people with which we can hold stable social relationships. The upper bound for this is thought to be somewhere around 150, but it's not hard to find thousands, if not millions, of people in social networks and services following or friending well beyond that limit.

A few weeks ago, Hutch Carpenter wrote a great article on how social relationships may be changing to incorporate far more people than Dunbar's number: that we use the follow relationship as a means to discover new content and track interests rather than as a means to follow people in the normal sense of the word. Instead of Dunbar's number, we should be focusing on Scoble's Number: the number of people you can follow that captures what you're interested in. This is a great hypothesis, and has great explanatory power in the normal web 2.0 world. Robert Scoble has talked about how he uses his "friends" to keep track on trends and find new stuff.

The problem is that this breaks down in the real-time world: content comes in too quickly, and it is very difficult to find anything that's of any use. Following hundreds or thousands of people in real-time prevents the cognitive absorption of information. Instead of finding the diamonds in the rough that you'd normally miss if you didn't follow lots of people, you instead can't find anything. Utilizing a network of hundreds of people to filter the good stuff just compounds the problem.

It's a Follow Problem, Not a Filter Problem

This is where filters come in: real-time filtering solves the information discovery problem far better than the kludge of following people with diverse interests. I don't need to follow a person to find out about the interesting bits they're sharing: I can monitor, in real time, based on semantic data. FriendFeed, in its new version, provides this, and it's merely the beginning. Filters will become far more powerful and provide far more targetted information that a social graph could ever produce.

Real-time Mimics Real-World

So where does this leave the social graph? I mentioned it on FriendFeed, but I think we're now much closer to how the real world works than anything else, and it's a sign of things to come. In real life, we don't go around making friends with everyone in hopes of getting some sort of information: we have close networks based on shared life experiences, and we use those close networks to experience a lot of stuff outside of our own worldview. A friend may invite you to a party, or tell you about their life, or catch up with you about things you've neglected that are personal to you. We use filters, in various forms, to get information about the rest: newspaper sections, TV channels, college courses, and so on.

Wrapping Up

FriendFeed, in its new form, is not perfect, but it's closer to capturing our natural methods of acquiring information than anything else out there. It's a sign of things to come: if you're a person like Robert Scoble, you're going to have to forget about following a thousand, 10,000, or 50,000 people; instead, start thinking about how to filter the infinite amount of information out there to things that interest you. Set up your information and entertainment channels and stop using people as if they were news feeds.

MG Siegler on VentureBeat had a great article today about this change, quoting Top Gun:

Instead, I’ll just quote a line from Top Gun that speaks to why I love the new FriendFeed: I feel the need — the need for speed.

Look, information happens in real time. One of the reasons the web has exploded in popularity is because it gives you access to more information, faster than ever before. This new version of FriendFeed does the exact same thing, to the extreme — it’s wonderful. Are people really complaining that we should slow the information down? It may be a bit extreme to say, but that really is a form of censorship. Don’t slow the information down, tweak the way you consume it.

In keeping with the go-go 80s metaphors, it's a real-time world, and I'm just a real-time girl.

URL Shorteners Are Playing with Fire

Mark Trapp — Sat, 04 Apr 2009 16:24:08 +0000

Bottom Line: URL shorteners, due to their very nature, may be on borrowed time. One step by Google and the entire industry collapses like the house of cards it is.

Yesterday, Joshua Schachter had an excellent piece on the perils of the URL shortener: it's clear, concise, and scathing. Jason Kottke and Dave Winer had a few suggestions on how to mitigate the problem, or get us on the right track to eventually deprecating the use of URL shorteners.

I agree with Schachter's assessment, and I think Kottke and Winer are on the right track, but I think the URL shortener problem is far greater than what Schachter enumerates: no longer satisfied with controlling the initial click, URL shorteners have decided to add toolbars to promote ther content or to sell adspace: the most notable and recent addition to this group is Digg's toolbar, DiggBar. Dubious utility aside, they are trampling in the garden of an angry god.

The 800lb Gorilla: Google

For better or for worse, all things link-related must pass Google's standards. Google's search engine depends on high quality, relevant results determined, in no small part, in how the web links together. It's something Google protects with its blacklisting policy: you do something Google doesn't like, and your links disappear from Google's index. It's as if they didn't exist at all.

Although it sounds like the 21st Century equivalent of Big Brother, they do at least give a clear indication of what is not acceptable, so you can avoid doing it if you want to play nice with Google. You follow those, you're probably in favor with Google.

The Doorway Page

But in reflecting upon the topic of toolbar URL shorteners, there's one set of policies that caught my attention, on cloaking, sneaky Javascript redirects, and doorway pages:

Doorway pages are typically large sets of poor-quality pages where each page is optimized for a specific keyword or phrase. In many cases, doorway pages are written to rank for a particular phrase and then funnel users to a single destination.

Whether deployed across many domains or established within one domain, doorway pages tend to frustrate users, and are in violation of our webmaster guidelines.

Google's aim is to give our users the most valuable and relevant search results. Therefore, we frown on practices that are designed to manipulate search engines and deceive users by directing them to sites other than the ones they selected, and that provide content solely for the benefit of search engines. Google may take action on doorway sites and other sites making use of these deceptive practice, including removing these sites from the Google index.

It seems to me the toolbar URL shorteners are treading dangerously close to Google's definition of a "doorway page:" all it takes is Google to classify them as such and Digg, of all sites, disappears from Google's index. Think of that concept: Digg, by far, gets most of its traffic from organic search results. Why would they even risk it?

Wrapping Up

While I agree with Schachter, Kottke, and Winer about the problems of URL shortening, I think those of us against the practice of URL shorteners (and at least for me personally, especially the use of toolbar URL shorteners) could soon have a powerful friend in Google. One step by Google towards classifying URL shorterners would mark the death of the practice: I'm not sure it's worth the risk for any of us to use them.

All Likes Are Not Created Equal

Mark Trapp — Wed, 11 Feb 2009 01:24:23 +0000

Bottom Line: Facebook still doesn't hold a torch to the basic user experience of FriendFeed not because it isn't trying, but because of the rules it's decided to play by.

Recently, Facebook released a feature in its newsfeed that allows people to "like" newsfeed items. As it's described by Facebook's program manager Leah Pearlman, the feature allows you to tell your friends you approve of what they posted:

This is similar to how you might rate a restaurant on a reviews site. If you go to the restaurant and have a great time, you may want to rate it 5 stars. But if you had a particularly delicious dish there and want to rave about it, you can write a review detailing what you liked about the restaurant. We think of the new "Like" feature to be the stars, and the comments to be the review.

This feature prima face copies FriendFeed's "like" functionality, right down to the interaction and the verbage. Not surprisingly, FriendFeed's supporters were outraged and appalled at Facebook's Machievellian drive to copy FriendFeed. But I think it's important to take a step back and talk about the value of a "like".

"This is interesting" vs. "I approve of this"

What most people seem to miss in the analysis of Facebook's latest feature is how different it is, in both intent and implementation, from FriendFeed's feature. It uses the same word, and lets the poster know you liked the story, but FriendFeed does something more: it shares that story to everyone that's subscribed to you.

Why is this important? FriendFeed's like acts as a means to rapidly disseminate things you find interestng with people. Think about Robert Scoble's 2,000-hour project: he's not just telling all those people that he approves of what they posted, he's telling his 20,000+ followers that they should check it out because Robert finds it interesting. That's true power and knowledge sharing.

Facebook's implementation of the "like" is for one thing only: to tell your friend (and others) that you approve of what your friend posted. While it makes you and your friend feel good, what value does it have to the social aspect of the newsfeed? If you like the story so much, wouldn't you want to share it with people?

Think about a real life interaction: say your best friend tells you they just got engaged. That's important! I'd be telling everyone about it. But Facebook doesn't capture that. It lets you tell your friend "cool." and walk away. I guess there's a small token value to that, but it's not capturing an important part of the power of social media.

FriendFeed's Like is Safe

What's great for FriendFeed about this difference is that this isn't merely an oversight of Facebook, to be corrected later. Facebook's privacy culture, which holds people's privacy as sacrosanct, prevents the FriendFeed like from ever occurring. While it's great for the average Facebooker concerned about privacy, it relegates Facebook's offering to a mere novelty gimmick, destined to the same fate as the superpoke.

Main photo credit: Nono Farahshila (Flickr)

My Perfect FriendFeed: Meme-less

Mark Trapp — Tue, 20 Jan 2009 23:10:51 +0000

Bottom Line: FriendFeed should not be work to use constructively. Better filtering tools, and more predictive tools, would elevate FriendFeed beyond the goof-off place it is today.

A couple weeks ago, one of the founders of FriendFeed, Paul Buchheit, asked the world their ideas on the perfect FriendFeed. I've been thinking about this since then, and there are a few standbys: I'd like better filtering options, I'd like to be able to have Tumblr treated like a blog, I'd like a native FriendFeed iPhone client that has 100% of the functionality of the website, and others. But these are either vague, or non-critical to my usage of FriendFeed. I could live without a good iPhone client. And what do I mean "better filtering options?"

Memes

By better filtering options, I really am trying to remove one "type" of thing from my feed: memes. I know there are a lot of people who love them, but I don't. I don't find memes to be a particularly valuable or useful phenomenon on the internet: I want to find new information, not 300 variations of a topic. So, what I would love to see FriendFeed somehow tackle is memeing: identify when a meme is going down, and block it, either for me or universally. "Blocking" may be too strong of a word: it could be handled like a hide, or even like other inflammatory discussions, where they simply don't get bumped up to the top of people's feeds.

It'd be really awesome if this was automatic: the moment there's a spike in "25 things" posts, institute the block. However, a poor man's version could be a keyword block. If I could hide or block things with keywords, it'd probably accomplish the same thing, albeit with more work.

Less work, more fun

The tried and true standby of those who respond to people like me who complain about content is "if you don't like it, hide it." Hiding is work. Having to read something, identify if it's valuable, then take an action to hide it is robbing me of time I could be spent doing something else. One hide is negligible, 10 hides is annoying, 100, 1000, or 10,000 hides is insanity. How much time have we lost individually hiding things on FriendFeed or manually managing lists and subscriptions? It shouldn't be so time consuming to derive value from FriendFeed: I think this time sink is what gives FriendFeed an air of "this place isn't for serious business," which is a shame. I don't want a game, I want a tool to augment my online use.

Updated: Yes, it's a Free country

In responding to some of the initial reactions to this post, I realize I didn't fully elucidate a big distinction of mine: I don't want to limit people's abilities to use FriendFeed however they want. You want to spend your time answering questions and filling out surveys and posting lolcats? More power to you. What I am saying is that it should be a lot easier for people not interested in those things to filter that out: FriendFeed could be much more useful to them if it was.

BuddyFeed, a Native FriendFeed Client

Mark Trapp — Fri, 16 Jan 2009 12:56:52 +0000

Bottom Line: BuddyFeed is a promising native iPhone client for FriendFeed, but there are a few things it fails to handle which probably makes it a non-starter for most people, even for its relatively small price tag of 99 cents.

One of the things that's been missing from FriendFeed has been a native iPhone client. Sure, there's the iPhone version of the website, and there's FFToGo, but they both miss a lot of administrative features of FriendFeed and don't provide the lustery UI of a native app. Recently, a third-party FriendFeed iPhone app came out called BuddyFeed. It's promising, but there are a few things it fails to handle which probably makes it a non-starter for most people, even for its relatively small price tag of 99 cents. It also has a few UI failures that really need to be addressed.

Overview

For screenshots, check out the Flickr photo album.

Like all good third-party FriendFeed clients, BuddyFeed asks for your username and remote key, indicating it's working off the standard, third-party API FriendFeed provides and not off of some magical scraping technique. This is great for users who are wary of giving their authentication information to third parties, but it also highlights just how far BuddyFeed is able to go: if FriendFeed doesn't provide it, BuddyFeed can't do it. A FriendFeed client written by FriendFeed itself probably won't have those same restrictions.

The UI is pretty standard iPhone app fare: which is a Good Thing. Most functions are available from a single click or within 2 clicks. You can subscribe and unsusbscribe from people (something you can't do on the FriendFeed iPhone website or FF2Go), get to your rooms, see your own feed, see your likes and comments, and post messsages (including messages while using the built-in iPhone camera). However, there are two glaring omissions:

No hiding, no lists

Two of FriendFeed's main features for filtering your stream, hiding and lists, are completely missing from BuddyFeed. I've seen these missing from other third-party FriendFeed apps, so I wonder how much that has to do with the third-party API BuddyFeed uses. Regardless of the cause, the lack of hide support breaks FriendFeed in a big way, and the lack of lists is a sorely missed feature from FriendFeed proper.

Quirky User Interface

BuddyFeed also suffers from some really odd UI quirks. In order to see comments and likes, or to make your own comment or like, you can't just feed item a story, you have to touch the feed item in the lower right hand corner, in an unmarked area. If you don't, the feed item goes to whatever it was linked to (for example, an external webpage).

The other big failure is the choice of icon for the comment function: it's a "go back" arrow. It took me a while, and a blind guess, to divine that the arrow meant "comment." It really needs to be changed.

Conclusion

BuddyFeed looks pretty promising, and the lack of lists and the odd UI choices are forgivable, but the lack of hide support is not. If you use FriendFeed at all on a regular basis, the lack of hide is probably going to stop this show.

Update: Robin Lu, the developer of BuddyFeed, just sent me this response:

Hi Mark,

Great thanks for trying the app and giving all the suggestions.

The "hide" setting will be honored in the next version.

"List" support will be added for the next version.

The icon is the native one for "Reply". You may find the same icon in the "Mail" for replying the mail. Maybe I should change it to the one as "Post".

Best Regards, Robin Lu

Sounds good to me. Here's to the next version!

Twitter vs. the Business-to-Business Model

Mark Trapp — Thu, 08 Jan 2009 23:07:26 +0000

Bottom Line: The value of social media for the business-to-business model, especially as we start to look at who participates in social media and who the decision makers are, is unclear. What do you think?

Over the past couple of days, I've been thinking about Business-to-Business (B2B) marketing as it relates to social media, and truth be told, I'm lost. Rather than go into a rant about how the internet's wronged me today, or try to get into a lesson about an abstract concept, I'm going to go through my take on the state of B2B social media marketing and pass it off to you, the reader.

Businesses are not individuals

One of the key concepts in social media is the emphasis on the individual: rather than talking to, or marketing to, large swathes of the population, you can interact with indivudual customers. This is great: for Business-to-Consumer strategies. But what about B2B? This is where the value of social media breaks down for me. I can see maintaining a blog: it allows you to keep your message out there and provides great SEO value. But if you're not targetting individuals at all, what's the point of Twitter? Or Facebook? Or FriendFeed? Or any other individual-based social network?

The decision makers are too old for Facebook

One counter to the above is that businesses don't really talk to each other: it's individual decision makers, and those people could be using social media to keep in touch. But in reality, I wonder how much that is the case. The average executive age is 53, and there's a substantial generational gap for social media. What's the average age of a Facebook user? It's probably under 35.

Even disregarding the generational gap in social media, there's something odd and unproductive about having decision makers hash complex B2B deals on social media. In the back of my mind, I've tried to picture Steve Ballmer and Jerry Yang working out a buyout deal over Twitter, and it's just awkward. I mean, come on:

B2B deals are large, complex, and time-consuming processes. 140 characters don't cut it, and the lack of a respect of privacy, at least in principle, is a problem. So where do these great social media tools fit in? How do you justify telling a B2B company that they can't afford to miss out on social media?

Short-term failure, long term success?

The one value I can see clearly with investing time and effort is to prepare for the next generation of executives, managers, and other decision makers. As scary as it sounds, there are people entering the workforce now who have spent their entire adult lives with Facebook, nevermind the increasing amount of the population who have never known a pre-Internet world. It would be remiss not to be talking to them using the same tools they use. But that's in 10 years or so: most social media addicts are in their 20s, or even younger; most executives are over 40.

So the value isn't really in an action item for businesses, but for them to be hiring people with minimal skill sets in the future: somewhat like knowing how to use email or Microsoft Office. But what about the short-term and medium-term (less than 10 years)?

I'm interested in your thoughts on this: let me know in the comments.