Adventures of an Eternal Optimist

Earlier I posted about what I called “the Age of TMI“. The world is busy pouring their heart and soul out into publicly hosted websites such as MySpace, Flickr, WordPress, Blogspot — you name it.

But what happens when you cross a line that the site hosting your particular accumulation of TMI doesn’t care for? What happens if your site accidentally deletes your account, or suffers an outage and can’t restore your information?

Imagine your life’s thoughts, your pictures, your list of friends, obliterated without notice, without recourse, and in some cases without even a backup in case a mistake was made.

What happens when your particular Web 2.0 personality site goes out of business? Or in the case of users on PhotoNet, what happens when your account suddenly disappears, because you don’t see eye-to-eye with the new management?

Consider the case of Rose & Olive, whose Flickr account containing years of photos and thoughts about their photos disappeared without notice. Rose & Olive made controversial pictures – but had for a long time, creating traffic for Flickr along the way, and making many friends and contacts. They were not warned, they were not notified in any way — one day their account was simply deleted. When they asked if they could at least archive what was on their account so that they could move to another site they were told that their account was permanently gone and that Flickr could not retrieve it.

Now – I can’t speak to the question of whether Rose & Olive deserved to be turfed – but the poor quality of the deprovisioning processes are striking.

What responsibility do Web 2.0 companies have to provide recourse to users who have been disabled or deleted? How about portability? And is there a difference between voluntary portability (ie quitting a site but retaining your content) and involuntary portability (ie getting kicked out of a site, but having your content tossed out after you, to do with what you wish)?

On a more personal note, in writing this entry I was directed to this portrait.  I was surprised at the emotions it brought out in me. The story behind the photo is heartbreaking. The discussion around ‘flagging’ a photo (an action that could lead to deprovisioning of the photographer’s account) is also interesting. I think that this is an example of the depth and quality that community sites can have in our society, as long as we allow the controversial to exist and to affect us, one way or the other.

It would seem that Internet Explorer 7 will be pushed out to the world this week. For those of us who do a fair amount of browser-based testing in Enterprises with an IE6 browser standard, you might want to wait to go to IE7. If you do, here are the instructions for blocking automatic delivery.

Also: On the teeny tiny chance that any of you are maintaining sites protected by a self-signed openssl-generated CA certificate, you may want to do a quick test with IE7 before your users get updated.

This is an extremely specific case, but I was unlucky enough to run into trouble with IE7 and use of a self-generated CA certificate. It turned out that the CA cert I generated was missing one or more server extensions that IE6 and Mozilla were willing to overlook the absence of, but which IE7 required in order for the certificate to be considered “trusted”. The CA cert that gave me such problems was generated by OpenSSL using the default config file that came with a not-that-new linux distro (in this case Mandrake 10.1).

I believe the problem was that I didn’t have a CA-specific section in my config file with bits like this in it:

basicConstraints        = critical, CA:true, pathlen:0
nsCertType              = sslCA
keyUsage                = cRLSign, keyCertSign
extendedKeyUsage        = serverAuth, clientAuth

You can see the entire context by going to this great reference article by Security Focus — check out the config file they list under “Method 3: Certificate signed by a local CA”. I can verify that if you replace the default openssl config file with the one in their article, and follow their instructions, everything works beautifully :)

It isn’t exactly a dire emergency should this happen — users are presented with the certificate error screen, but can click “Continue to this website” and get to their content. Still, if you happened to generate your CA cert the same way I did, and want to be absolutely 100% sure that your users won’t get that nasty “There is a problem with this website’s security certificate” error when they get their forced IE7 upgrade and subsequently access your site, you might want to view your CA cert and check for server extensions. In the unlikely event that you have none at all, I forecast that you will have problems.

I hope this affects absolutely none of you… but if it does, I hope at least the links I’ve brought up here can get you going quickly.

Those of you who work in and around federation should take note of Brian Puhl. Brian has been speaking and blogging about his deployment experiences with ADFS as part of Microsoft’s ‘dogfooding’ program, and he has some hard-won opinions on the subject. I commented on a blog entry of his regarding who can create federations in ADFS. Part of his reply was this story:

A great example of technology vs. liability is the ongoing discussion that we’re having with one of our business partners, about providing federated access to their internet portal. This partner though, happens to be one of the providers of financial services to Microsoft employee’s. From the partners perspective, the idea of federation is wonderful…they see it increasing their security, reducing their risk (since they still allow SSN’s as user names), and reducing the amount of overhead they have for constantly resetting users passwords. In fact, one of their architects commented that there were nearly as many users who require a password reset EVERY TIME a user attempted a login, as there were who didn’t.

Enter the Microsoft attorneys…

They looked at the technology, and got a pretty quick understanding of the risks, limitations, and potential uses for ADFS. They just as quickly built the following scenario

So Joe User’s password gets compromised. Not only can someone use it to gain access to some set of corporate resources, but now they can also go in and mess around with his retirement portfolio? And they would do this, because during the logon attempt, “Microsoft” verified that the user was actually Joe? Ummmm….No.

This is basically the story of how Microsoft has ended up asking some of their higher impact business partners, to create a 2-tiered authentication model. In this case, a user can log in using ADFS authentication to view their information…but as soon as they want to make a change to their information, they’ll need to enter their application specific credentials.

According to the partner, approximately 85% of all logons are just to view the data anyways, so it’s still a win…but it also virtually guarantee’s that when a user does want to make a trade, they’ll need to reset the password because now they DEFINITELY are not going to remember what it is.

When I read this, I felt like jumping up and down like the goody-two-shoes in the second row, me me me me oh I know the answer pick me!!!

If they were to use an Information Card for the active confirmation prior to a user making changes, users wouldn’t need to remember a password at all. You would get the impediment of requiring credentials, without the support burden attached to maintenance of a rarely-used password. Alternatively, if you felt the need to have a password, you could require a managed information card. In that case, the user would be authenticating to the home IdP instead of to the outside application, taking the password management burden off of your partner and consolidating password use to a single centralized source that would theoretically be much more commonly used, and therefore less likely to require frequent recovery. Not to mention that the Enterprise could audit use of the managed infocard in this context.

This seems to me to be a perfect scenario to envision a hybrid passive/active federation combination instead of passive federation for 85% of user activity, and partner-managed password authentication for the remaining 15%. Yes? If so, it just goes to show that the scenarios are out there, and for more than just the eBusiness world.

Brian, what do you think?