Adventures of an Eternal Optimist

If a genie jumped out of my coffee right now and offered to grant me a wish, here’s what I’d want (world peace is overrated):

I want a way to put a sunset date onto technical web data,  so that I can find relevant technical information instead of the one “Introduction to Tomcat” that 5 gzillion people downloaded 6 years ago, and that eventually reveals itself to be 3 versions out of date, but still shows up at the top of the hit list.

I would love to have a way to know that when presented with two webpages, each describing two COMPLETELY different ways to do something without mentioning a date or a version or a platform, I can pick the one that isn’t going to waste 6 hours of my time.

Scope.  Context.  That is what I wish for.    A consistent way to determine scope and context.

This is my own reminder to myself, to write documentation that includes scope and context, right up front.  Whatever I can go back and add scope to, I will.  I will imagine that it is 10 years from now, and .NET Framework 27.2 has just been released,  and I want to put that on my machine along with Higgins Framework 10.7b.    Either my documents should be still-relevant, or instantly dismissable.  If I can accomplish that, and keep it up, I’ll be happy.

The worst documentation is the vendor-branded stuff, of course.  No author.  No date.  No version.   Erg.

To my horror yesterday – I found that all of my NetVibes folders had been blown away, and around 80 different feeds had been placed into a single tab called “Lost & found” after I created a new tab called “Funny!”.

It turns out that if you export an OPML File, even when the folders are missing, and then re-import, you can get your folders back (don’t click the “create new tab on import” checkbox, because then you’ll have 2 sets of everything). At least, my folders came back, YMMV.

I recommend saving an OPML file of your feeds anyway – I didn’t even think to do so until I was in a bad position, and only then did I realize how valuable that list was.

Higgins 1.0 is out today!   Congrats to all the folks who have worked for a long time to make this happen – and thanks to the companies and individuals who have commited time and $$ because they believe that Higgins make a difference.

Check out Higgins 1.0!

Even as the infrastructure around Information Cards and other user-centric and/or federated identity initiatives grows and matures, other groups & technologies are trying to solve the same problems. Browsers have had password managers forever, for example.

Browsers, however, do not travel to the service whose passwords you have entrusted to them and actually authenticate in order to farm your accounts for information.

This service does, however:

We already have RSS feeds – why not account feeds? These guys figure that if we just give them all of our usernames and passwords for all of our silos, they can give us a one-page dashboard of all of our bank balances, point balances, incoming email, you name it. Well actually, they name it. Because they can take whatever they want out of your account. Best part is: they reserve the right to use that data to market things back to you. But hey – you don’t have to enter your password when you go to any of the aggregated sites…

I have no problem with the general idea. I know people who would love to see all of their numbers from all of their investments, etc, all in one page, including a handy little “login now ” link for the website of each institution. What I do have a MASSIVE problem with, is the underlying technology used to achieve this end.

The whole site is based on credential management. You give this company complete access to your bank accounts, and they give you a pretty aggregated screen back. They authenticate as you and pull out whatever information they want, with no controls, no visibility into what they are doing while authenticated, and the obvious ability to make programmatic use of your credentials as often as they wish. You give it all to them, completely at the mercy of their ethics, business practices, and technological failsafes. Such a scheme benefits neither side of the transaction.

To me, this is a perfect illustration of the long-term future of federated identity. You want an aggregated account feed? Authorize a specific service to request a specific amount of information from your account. Want a handy login link? No problem, part of the information you can give the aggregator is your relying party endpoint, and next thing you know, you are asked to directly authenticate to the site in question, in a consistent fashion, using credentials that you trust, and that only you possess. Perhaps you don’t even need to do that – perhaps the aggregation site participates in a ‘circle of trust’ that in fact means you can seamlessly travel to your bank site. Chances are, this won’t happen though — and for very good reasons; because chances are banks may not trust the aggregation site. If they do trust the aggregation site, you can bet there is legal work backing that trust relationship up. What legal work backs up a user who gives their credentials away to a third party? There is no difference in user experience – but a world of difference in risk mitigation, in transactional repudiation, in auditability, heavens, pick any security or privacy buzzword, and it probably applies.

What do these guys have? They have a beautiful, easy-to-use interface. They solve a problem that many people are eager to have solved. They have some fancy logos in their footer that show they at least get the fact that what they are doing had better damn well be secure. But – in my opinion, they are basing all of this on a foundation that is quickly tilting sideways.

The whole “give us your account credentials” trend, whether it be for social networking or any other kind of data aggregation is a serious problem. Allowing such practices to gain a foothold in user’s minds as a valid practice simply because they are starting with “inconsequential” data is a surefire way to make future battles a lot tougher to fight in this area.

The good news is, this site is yet another validation of what the user-centric identity folks have long said. Silos are bad. People hate them. They want their online lives to improve, and they want improvement now, not in 5 years. The bad news is, if we don’t galvanize our industry into wholesale participation in providing an alternative in the near future, this site serves as an exact answer to where the world will go.

After working to install version 0.7.0 of the MediaWiki OpenID extension, it turns out that the whole thing boils down to 7 pretty darn simple steps. Although the OpenID extension README says the extension was “tested with 2.0.0 rc2″ (of the php-openid library), the plugin doesn’t actually work with php-openid-2.0.0.  For some reason, I feel chicken about clarifying this point on the actual extension wiki site – perhaps if somebody externally validates my findings and comments here, I’d feel better about it…

1. Download/check out the extension and place it in the extensions directory as extensions/OpenID.
2. Create the user_openid table from the .sql file included in the OpenID directory:
   mysql <dbname> -u <username> -h <hostname> -p < openid_table.sql
3. Create an includes directory within the extensions subdirectory (this is where I put it – if you want it somewhere else, just make sure that it is a place that won’t be overwritten or deleted during upgrades, and alter the path in step 6 accordingly).
   mkdir extensions/includes
4. Download version 1.2.3 of the PHP-OpenID library and place it in extensions/includes.
5. Run the detect.php script inside of extensions/includes/php-openid-1.2.3/examples and do your best to deal with what it says. If you are missing things like MySQL and PEAR, you’ll just have to figure that out yourself, sorry. If, however, the results of the detect.php script tell you that you have no big integer math support as shown below, you should uncomment the define command in the code you paste into LocalSettings.php in step 6:

Your PHP installation does not include big integer math support. This
support is required if you wish to run a secure OpenID server without using
SSL..

6. Add the following lines to LocalSettings.php (remember to uncomment the NO_MATH_SUPPORT line if you received the error shown in step 5):

#
# -- OpenID Extension
#
$path = "$IP/extensions/includes/php-openid-1.2.3";
set_include_path(get_include_path() . PATH_SEPARATOR . $path);
# -- uncomment the following line if you have no big integer math support!
#define("Auth_OpenID_NO_MATH_SUPPORT", true);
require_once("$IP/extensions/OpenID/OpenID.php");

7. Attempt to log into your site with an OpenID – hopefully it works!
8. Update:  if you have issues, a reader emailed in to say that he had to add a trailing slash (“/”) to the path statement in step 6 before anything would work.  It would look like this:  $path = “$IP/extensions/includes/php-openid-1.2.3/”;  It couldn’t hurt to give that a try… (thanks Christian)

Believe it or not, somebody has introduced a bill in the Mississippi legislature that would require restaurant owners to deny service to any patron with a body mass index (BMI) greater than 30.

This raises an interesting question: is weight-related information considered private? On first blush, such an idea makes no sense – anyone can look at you and judge your weight, the same way that anyone can judge your eye color — but to me, the difference between judging weight from 3 feet away and pulling out the calipers to do a body-mass-index (BMI) measurement is a difference that crosses a critical line.

Would you consider your annual income to be a private matter? Me too. You may be able to take a guess based on the car I drive or the house I live in — you may even conclude that I’m well off. I certainly cannot prevent you from deciding I make a good living. I can, however, refuse to provide details, thank you very much. Those details, as guessable as they might be, constitute my private business. Public disclosure of such details would be uncomfortable, embarrassing, and invasive.

By the same token, my body-mass-index is also my private business. It constitutes something only I need to know. It is a piece of data strongly connected to my dignity. The idea that this information has to hang out for the consideration & judgement of the hostess at TGI Fridays is frankly repulsive to me. There seems to be an idea that this is no different than denying alcohol to a drunk person; the difference being that government restrictions on public intoxication are not expected to cure alcoholism. Do these lawmakers really think that restrictions on public eating will cure obesity?