Blockbuster, RIP

Back during the Madness, a neighbor happened to mention a new service that would let you rent DVDs online.  This was around the same time as eToys and WebVan, back when one could look at a preposterous business plan and think "Well, maybe I'm missing something."  Nonetheless it seemed a bit unlikely that people would want to wait for DVDs to arrive in the mail when they could just hop over to the local Blockbuster.  I didn't give the idea much of a chance.

About a decade later, Netflix is still going strong and Blockbuster has just filed for bankruptcy, sending its stock from about $0.06 to around $0.04.  That's a typical "oh look, you can too fall through the floor" dot-bomb performance and, sadly, not too much of a surprise.  I literally don't remember the last time I set foot in a Blockbuster or heard someone say "Oh, I'll rent it at Blockbuster".  For that matter, I'm still not sure when I last bought a DVD.  The only reason even to rent a DVD is that it's not available online cheaply enough.  My Netflix subscription, however, is still going, albeit at the minimum rate [and it's still alive and well ... the new "smart TV" in the bedroom has Netflix built in with a button for it on the remote control, and Netflix seems to be doing pretty well following the HBO playbook in moving from supplying movies to producing original content --D.H. Dec 2015].

The winner here, of course, is online video (provided you include video on demand).  The loser is physical video (tape and DVD, but with movie theaters in a separate category).  Netflix would likely be in the same boat as Blockbuster had it stuck to mailing DVDs and conversely Blockbuster might have survived had Netflix not beat it to the punch online.

So there you have it: Convergence and the web winning decisively over the old bricks-and-mortar model.  It really did happen.  Just years later and only in an industry that's essentially been selling bits all along.

More reading on identity

As a companion to the previous post, Joe Andrieu's blog, apart from its own merits, is also a fine jumping off point into a whole community of people thinking long and deeply about such things as what identity means on the web and how to empower* people to take charge of data.  The immediately relevant post is Self-managed Identity, itself part of a series Introducing User Driven Services.


* I generally cringe when I hear words like "empower," but I use it here because I believe it's appropriate and they really mean it.

The cry of the squeamish ossifrage

I think I got rid of the old Scientific American issue years ago, but I still remember reading about the RSA public key cipher in Martin Gardiner's Mathematical Games in 1977 (August, to be precise).  Thirty-three years later, RSA is still in use, providing a secure means of encrypting and signing digital data (unless someone has figured out a way to crack it and is sitting very, very tightly on the secret).

In particular, it can be used to verify that only someone in possession of a particular secret key, generally a several-hundred digit number, could have produced a particular block of bytes.  If you visited a site whose URL started with "https://", for example your bank, your browser most likely used RSA in the process of satisfying itself that it really was talking to the right server.

So why is authentication such a mess?  Why does resetting a password require anything from coming up with the name of a cat to providing a working email address to providing several pieces of information and then getting a phone call?  Why do some sites want the three-digit code on the back of your card and some not, and how is adding three more digits that you end up handing out to all and sundry helping the situation?  Why hasn't OpenID or some other knight in shining armor been able to rescue us?  Why do we still use passwords for anything besides locally decrypting the key to a real authentication system?  How do you even know I wrote this?

I don't really know, but if I didn't have some guesses I probably wouldn't be writing this, now would I?

First, what would a really seamless authentication system look like?

• It would allow for multiple identities.  Maybe I just haven't caught on to the whole every-waking-moment-of-your-life-available-online thing, but I would rather keep my work identity separate from my blogging identity separate from my personal email separate from my bank accounts.  Not to mention my identity as an international man of mystery.
• It would allow the same identity to work multiple places.  This is not the same as giving N different sites the same username and password.  Your username doesn't belong to you, whereas a real identity does.  Anybody can choose your favorite username if they happen to get there first.  It's also not the same as letting your browser keep track of a bunch of username-password pairs and putting a master password on all of them.
• It would minimize the number of tokens needed for an identity, and each token would be there for a clear reason.  If the token is a password, fine, but it should be a password, not a password and two or three "security questions."
• It would use current best practices.  It's risky to use anything too new when it comes to security technology, and unless you're No Such Agency or the like it's madness to try to create your own, but there are plenty of well-established road-tested security techniques available.
• It should be portable, both physically (like the "pocket-thing") and across sites.  Ideally, registering with a new site means registering the token(s) for the appropriate identity.
• It should be as completely under the identified individual's control as possible.

What actually happens?  Something along these lines, I think:

Suppose I have some sort of digital certificate that I can use to identify myself.  Properly used, this could satisfy the requirements above, perhaps together with some sort of physical token, like a smartcard.  Any really secure authentication system, including a smartcard, is going to have some such certificate in it somewhere.

Since it costs money to have a major certificate authority (CA) vouch for a certificate (by signing it), certificates used by individuals in practice tend to be "self-signed", or signed by members of a "web of trust" instead.   That's fine for some purposes, but not for doing business with a bank.  If it's not good enough for the banks, it's probably not good enough for your utility company either.

In theory, you could establish your identity with a bank and then get them to sign a certificate to that effect, which your utility company might choose to trust, but that basically puts your bank into the CA business, not one they're necessarily keen to get into.  In practice, each company would rather control the process, typically asking for an account number off a paper statement to get the ball rolling.  Each entity has its own customer ID system for the account number, and usernames are potluck, so you end up with (at least) one semi-identity for each company you do business with.

In the wild-and-woolly world of pure web sites, where you don't already have a customer id when you sign up, there doesn't seem to be any strong push to move beyond the usual username-password system. Everyone's used to it.   Switching would mean re-doing the login screen, at the least, with new and less-familiar technology, then convincing your users to go along with it.  If it ain't broke don't fix it.

Since an authentication scheme is only as strong as its reset mechanism, there are basically two schemes in wide use:

• An identity is a working email address
• An identity is a couple of "security questions" and answers

If I had to choose, I'd take the former, but it's not much of a choice.

Online customer service, only without the service

I don't generally like to criticize customer service reps.  It's a thankless job.  However, this particular one might have been a little more careful with those boilerplate macro keys.  It would be helpful, also, if SomeCompany's system would allow a password reset* given:

• Account number
• Username, being the service provider's home-grown email address for the customer
• Customer's personal email address
• Customer's full name and home address
• Last four digits of customer's SSN
• Customer's home phone number
• IP address associated with the account (from which the system was already able to find the username)

It's sort of a division of labor anti-pattern. A human an a computer working together end up more obtuse than either alone.  Offering the customer the service the customer can't log into and the chat support that didn't help is a nice parting touch.

What follows is an anonymized and lightly edited transcript of an actual customer chat sent by one of my "army of stringers, researchers, fact-checkers and miscellaneous hangers-on."


Problem: Trying to sign in; need password

Hello Customer, Thank you for contacting SomeCompany Live Chat Support. My name is Service Rep. Please give me one moment to review your information.  I'm ready to assist you today. How are you doing by the way?

Fine, thanks
.

Nice to know that you are doing good.

I was trying to log in to your service


As what I have understood, you would like to have your password for you to sign in right?


Yes.  I thought I'd already set up an account and your website found a user name from looking at my IP address, but I can't reset the password
. Also, I'd rather choose my own user name rather than use the assigned one (wemadethisup@somecompany.com), if possible.

Oh, I see.
  I understand that it is very important for you to know the password of your here.
  I also know that you would like to have your email address personalized and change it.
  There is no need to worry since as your service representative today, I want you to know I am more than willing to help you today with your issue. I can assure you that we can have a positive resolution since we will be working on this together.

Here’s what I can do, Since your password is not allowing you to log in, and since we do not store our customers’ passwords, I can give you a randomly system generated password would that be okay?

That would be fine, thanks


Alright. Please allow me to pull up your account information so that we can resolve it in the most efficient way possible. I will be verifying security information to protect your account privacy. May I please have the account number, account holder's full name, home address, and the last 4 digits of your SSN?

<Customer gives the information>

Thank you.
  May you also verify your phone number and the Email address that you are using?

<Customer gives phone number and personal email address>

Thank you.
  I am referring to the SomeCompany email address that you would like to reset the password.

I don't use SomeCompany for email, so that address is only useful to me as the login ID.  I'm not set up to check that account and I would rather not have to be.  But I think you mean wemadethisup@somecompany.com.

Thank you.  While waiting, I will share with you a feature of SomeCompany that you can truly benefit. Are you aware of the customer self-help on SomeCompany.com? SomeCompany.com has an extensive series of Frequently Asked Questions (FAQs) that cover all of our products. Customers do not have to sign in to access the FAQs. Quick steps to do it...Open a web browser window and go to http://www.somecompany.com/. On the home page, the navigation menus are on the left side of the window and click on Customers then Help and Support.


I have already pulled up your account.

I don't think the FAQ will help.  Please just reset the password.


Okay. 
  Now, for the password, since we do not keep it for security reasons, I can reset it and provide you with a randomly generated one. Do not worry about changing it because you would be able to change it to your preferred password once you are able to log in. Would that be okay with you?

Yes, please.

Sure, now for me to push through the process and reset your password, may you please give me your security pin?

I don't remember setting a security PIN.

A security pin is like a password to your account. This will be sent via a postal mail to you, a few weeks after your service is started. It is a 4 digit number.   May you please try to check your postal mails?

OK.  I might have the mail somewhere.  I have no idea where.
 [time passes] Sorry, I can't seem to find anything.

Since you have not provided the Security pin, in order to push through with this process, I would have to call you right now on your phone number to authenticate. Would that be okay with you?

Unfortunately, no.  My kids are sleeping.
  Perhaps I should try again during the day?

Yes, you may always contact us. 
 We are available 24/7, Customer.

So there's nothing else you can do?

Customer I really know how important it is to have your password. I would like to apologize however, we need to call you to authenticate so that we can reset your password.

OK. I'll try again during daytime hours.

Thank you so much for your time, Customer.

[time passes]


Customer, here’s what we have done on this chat today, I have assisted you with your SomeCompany inquiry on resetting your password however we need to call you to authenticate.
 Customer, it has been my pleasure serving you today and I truly appreciate your understanding and cooperation. Do you have other concerns for me today? I will be glad to assist you further.

No, that will be all, thank you.

We strive to exceed your expectations and hope that you will take a moment to complete the 3 question survey that will follow our interaction, your feedback will help us to continue improving how we serve you. 
 Do you want to use our service? Go to http://www.somecompany.com. Thank you for choosing SomeCompany as your service provider and have a great day! SomeCompany appreciates your business and values you as a customer. Our goal is to provide you with excellent service. If you need further assistance, you can chat with one of our Customer Support Specialists 24 hour a day, 7 days a week at http://www.SomeCompanySupport.com



* Actually, SomeCompany is probably right to want better authentication.  It's quite possible that someone, say, found their neighbor's bill, with the account number, and leeched onto their non-secured WiFi or used other chicanery so as to connect from the right IP address and thence obtain the user name.  It's conceivable that such a person also somehow happened to know the customer's personal email address and last four digits of the SSN.

Calling the phone number of record (which the customer was challenged to give and the service rep is able to verify) would raise the bar significantly.  Likewise, assuming the snail mail with the PIN didn't also have the account number, the would-be thief would have had to steal two separate pieces of mail, typically delivered on different days.

The annoyance here is that the stronger authentication is strong on its own.  That is, "Tell me the PIN we mailed you" is about as secure as "Tell me the PIN we mailed you and several pieces of not-too-hard-to-find information." and "So you want a password reset?  Let me call you at the phone number listed on the account." is at about as secure as "Tell me several pieces of not-too-hard-to-find-information and I'll call you on the phone number listed on the account."  Unfortunately, Service Reps are generally required to go through the whole account verification cha-cha-cha before doing anything meaningful.

One wonders, though, why this bundle of not-too-hard-to-find information is good enough the let the customer access the account information, but not good enough to let the customer use the service itself.

A belated Happy Birthday

Yikes, this is a bit casual even for the new, even-more-casual Field Notes [Heh ... I think the current record is now 27 Aug to 14 Dec 2015, which would include a Field Notes birthday -- D.H. Dec 2015].  For months I'd realized that post 500 and the third anniversary of the first Note would come close together, but I got so caught up in spinning up the new blog after post 500 that I forgot all about the date, even though I posted just one day afterwards.

In the new spirit of apathy, I won't hold forth as I did in years past, but I would at least like to note the occasion, if only a bit after the fact.

Ajai Chowdhry on IT in Africa

Real journalism is not an easy gig.  Your job is to report news, which means things nobody knows about yet.  Old news is no news, so you need to figure out what's going on as quickly as you can.  Extra time spent researching or editing is time that the story's not getting published.  Then you get to go on to something else you don't know about, though at least it will usually be in the same general vein.

So I feel a little bit bad as a casual blogger about picking on the CNN headline writer who characterized Indian IT entrepreneur Ajai Chowdhry's comments on African infrastructure as "Why broadband not roads will transform Africa."  But only a little bit.

From what I read, Chowdhry isn't saying that broadband is more important than roads.  The main assertions I get are that Africa's problems and solutions are the same as India's; India has had an advantage in being a single state instead of 53; because of their similarities and decades of close relations, doing business in Africa is not difficult for an Indian company; Africa represents a huge business opportunity; African manufacturing has a huge native market to supply; African unity will only help Africa's economy and stature in the world; and, yes, broadband and the web could and should play a major role in addressing African poverty.

Chowdhry mentions roads in one passage at the end:

But the one area where Africa can make a big difference is by not just looking at putting up roads -- it should look at putting up internet broadband-type infrastructure.

In other words, both are important, and perhaps broadband is being overlooked.

My point here is not to bash on CNN.  As I said, putting this all together is harder than it looks.  Rather, it's that Chowdhry's broad and well-developed view of the situation, from the standpoint of a key player in IT, provides a good perspective of how the web fits into the overall picture of economic development.

Given that Chowdhry is in the business of IT and clearly and openly hopes to gain from helping develop African IT, it's particularly notable how broad a view he presents.

Well now I've done it

Field Notes now has a baby sibling. Its name is Intermittent Conjecture and it has something I haven't seen in years: a post list that fits on one page. In fact, as I write this it contains only an introductory post. Considering that I skipped that formality with Field Notes, I suppose that's another first.

As I say there and said here, the plan now is to relax for a while and post whenever the mood strikes. If it's about the web, it will end up here. Otherwise it will end up there. Unless you are singularly obsessed with or repelled by talk of the web, you will probably not see a lot of difference between the two, other than the range of topics.

If there were regularly scheduled programming, this is where we would return to it.

Wikipedia 1.0: journey vs. destination

While browsing through the Wikipedia policy pages (it was either that or just tattoo "Geek" on my forehead and be done with it) I ran across something I remembered running across a while ago, more or less shrugging at and moving on, namely an offline edition of Wikipedia. There seem to be two approaches:

• The "German model": Distribute a snapshot of Wikipedia on CD. Why, I'm not sure. Perhaps to reach that select audience of people who have heard of Wikipedia but don't have an internet connection to access it*?
• The "Wikipedia 1.0" model: Select the best, most polished articles and publish them, whether on paper, CD/DVD, read-only web site, or whatever.

The Wikipedia 1.0 project was proposed in 2003. At this writing, several versions have been released and 0.8 will be out Real Soon Now. That's not to say that 1.0 will be two versions from that. The beauty of the x.y version numbering scheme is that you don't have to go from 0.9 to 1.0. You can release 0.91, 0.95 ..., you can release 0.10, 0.11 ..., you can release 0.9a, 0.9b ... [But it looks like we'll go into 2016 still on version 0.8 ... my guess is that 1.0 isn't going to happen -- D.H. Dec 2015]

For my money, it's not particularly important whether 1.0 ever comes out. Plenty of good has come out of attempting the exercise at all, in particular as a spur toward improving the quality of core articles and encouraging the development of Wikipedia's quality and importance ratings. These exhibit a nice division of labor: People rate articles and computers aggregate the best-rated ones.

The main reason not to just leave it at that and integrate the ratings more directly into the UI, is that vandalism still has to be filtered by hand and, despite the lack of imagination exhibited by most vandals, always will be. But most likely even that could be handled without an explicit release mechanism, by means of "flagged revisions," which allow editors to flag particular revisions as being free of vandalism and otherwise up to snuff. Apparently the mechanism has been in place for a while but the community is still figuring out how best to use it.

What's the proverbial "simplest thing that could possibly work" here? Perhaps just allowing anyone -- or anyone with an account -- to tag a revision however they like, and allow readers to filter what revisions they see. E.g., only show me revisions that the quality rating committee has rated "good" or better and my friend Jimbo has rated "funny". The proposal for "sighted revisions" looks pretty close to this, though less flexible.

* That's a bit glib, as there are communities with access to computers but with limited or no bandwidth, but given it was the German edition at 3 Euros per CD, I doubt this was the intended audience. Nonetheless, 40,000 people opted to buy it.

Could I just type a date, please?

For some reason, I've been running into sites with broken date entry fields.

It doesn't seem like a hard problem. In the States, at least, the standard format for dates is "mm/dd/yyyy", so a decent date entry field would behave something like this:

• If I type in, say, "7/27/2010", the date entered will be July 27, 2010
• Um, that's about it. The left and right arrow keys move amongst the numbers, maybe the up and down arrows increase/decrease the field where the cursor is.

The problem is, an annoying number of sites use something that does even more for you: If you type in enough to fill in a field, it moves you to the next field -- which is actually fine -- but it doesn't remember that it did that. "Fill up the field" and "/" both move you to the next field. If you get to the end, it wraps around to the beginning.

So if I type 7/27/2010

• 7 goes in the month field. Good.
• / moves me to the day field. Good.
• 27 fills in the day field and moves me to the year field. Fair enough.
• / wraps me around to the month field. Wha?
• 20 fills in the month field again, except 20 isn't a valid month. Urgh.
• 10 fills in the day field again. Foo.
• I end up with "20/10/" and no year. Bleh.

Of course, all I have to do is remember not to use / if it's the 10th or later and October or later. Right.

Or this widget could just not use / to move fields if it just moved because of a full field.

OpenID and incentives

I mentioned OpenID in the previous post, leading me to wonder "Hey, whatever happened to OpenID?"

Well, it's still there, but perhaps not in the form its creators had in mind.

In OpenID, there are three main roles

• You
• The site you actually want to use (the relying party)
• The site that you'll log in to to convince the relying party that you're you (the provider)

I don't know about you, but my intuition was that it would be easier and more popular to be a relying party than a provider. That's more or less the situation with, say, SSL certificates. If you're a certifying authority (CA), you're vouching for each certificate that you sign and you have to pay great attention to keeping your keys safe and other such matters. If you're just using a certificate (like when you log in to your bank or some other site using https), all you have to do is decide what CAs to trust, and in practice your browser makes that decision and does all the checking behind the scenes.

In OpenID, if you're a provider all you really need to do is accept requests for your users to log in -- which you have to do anyway -- and tell whoever asked you to do that, "yep, that's them." Unless being an OpenID provider is your main gig, you really don't have to take any more care than you otherwise would. If no one trusts you, it's not the end of the world (but see below).

If you're a relying party, you have to decide whether to trust the provider. In particular, you have to trust that the provider will check identities at least as carefully as you would. If the provider is a bank (not that that seems likely) or is trying to make money solely off of providing OpenID, that's a pretty good bet. Otherwise, your milage may vary.

...

After working through that, I realized that there's a much simpler reason that -- unlike the certificate case -- parties tend to prefer providing to relying: If you rely on me, then your users will have to log in to my site, maybe see some of my advertising, be reminded that they use my service, and so on -- in order to use yours*. Sure, their account with you is still an account, but their account with me becomes the "real" account that the others are just sort of attached to. Which role would you rather play?

I like this analysis better. Providers do have an incentive to provide good service to relying parties, but unless users really care, no one has much incentive to be a relying party. Now that browsers are good at remembering passwords, having a single sign-on is less of an issue and people probably don't care so much. With a modern browser, you could give each account its own password if you like (and that's the more secure option) without having to keep all of them in your head.

* Providers can allow "checkid_immediate", where you don't have to log in to the provider, but that's not a popular option. Not only would providers likely prefer that users go through their login as often as possible, relying parties would probably prefer to know that the user actually logged in somewhere before letting them in.

Letters of introduction

As part of my never-ending quest to catch up on things I ought to know already (right up there on the list with reading all the great works that I've never gotten around to reading), I did a little brushing up on single sign-on schemes.

The basic idea of single sign-on is simple and good: I don't want to have to type a username/password all the time, and I don't want to have to keep track of which password I used for which account. The second item is particularly bad, since even though there are ways to let people have passwords without storing the passwords themselves, not everyone seems to know how to do it (the techniques are only a few decades old after all). So that means either keeping track of lots of passwords, or using a few and running the risk that one insecure site gets compromised.

(Logging in by sending a password to a server is kind of bogus anyway. Stronger schemes use passwords only to locally unlock the secrets of some sort of strong crypto which then handles the real authentication. There are also smart cards and similar which use strong crypto to generate a secret with a limited lifetime, tying a login, assuming the crypto works, to a physical object and a point in time.)

So, how does a single sign-on service work? Basically such a service depends on a way for some other system to vouch for you to the system that you're trying to log in to:

• You log in once with a particular server
• That server gives you (or your browser) a token (or cookie, or ticket, or whatever you like). That token effectively says "so-and-so was able to present me with such-and-such credentials -- generally a username and password but possibly something more substantial -- at such and such time"
• You (or your browser) show that token to the system you're trying to log in to.
• That token has enough crypto mojo in it to allow the system you're logging into to verify that it really came from some party it trusts, that it hasn't been tampered with, etc.
• Assuming that the identification in the token matches a known account, you can now be logged in.

There are variations. For example, in OpenID, you give the server you're trying to log in to a URL representing your identity. That server chases the link and finds out who's vouching for you. It then checks with that party. Typically that party will ask you to log in to it and make sure that you trust the server that asked it to do that. The two servers then securely agree, effectively, that yes you did log in.

The young Charles Darwin carried with him on the voyage of the Beagle letters of introduction, as was common practice in those days. By presenting the appropriate letter, he was able to obtain lodging, safe passage and other such benefits. The letters were signed by people the benefactors knew and trusted and let them know that Darwin was also someone to be trusted. The signature a was crucial part of ensuring that the message really came from whom it said it did; people paid more attention to signatures then than we typically do now.

Is there a connection between this fading and quaintly antiquated practice and modern digital technology? Well, they don't call it a digital signature for nothing ...