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 ...

See, now that didn't take long

One other conclusion from my 500-post mullings: This site needs a re-design. I've narrowed it down to

• Bachelor #1
• Bachelor #2
• Bachelor #3

Expert graphic design help courtesy of the Geocities-izer.

My, how time files

Somewhat over a year ago I posted post number 300 and said I probably wouldn't make much of a production until I hit a more significant milestone.

This is post 500 and, having mulled this whole "blog" thing over, I've come to a few small conclusions:

• After 500 posts and nearly three years I'm pretty well convinced I can write a blog.
• The last couple of months have seen a mad scramble at month-end to make my self-imposed and arbitrary ten-post-a-month quota
• I still enjoy writing Field Notes, but there are also other things I'd like to write and my time is limited.
• Somewhat to my surprise, I still enjoy reading this blog, despite feeling that I must have beaten most of the major themes to death by now.

So ... I'm not sure exactly what to do next, but one decision did jump out: Drop the ten-post-a-month thing. It's good to have a goad to encourage putting something down, but at this point in the game just producing posts doesn't seem like a very meaningful end in itself.

That doesn't necessarily mean I'll be posting less. I might, I might not. The next post might be tomorrow (not unlikely) or in a year (much less likely), but there will definitely be a next post, and one after that ... Will there be a post 1000? I have no idea.

One thing I probably will do is go back and re-read the whole blog from start back to real time and do a bit of gardening along the way. That will almost certainly produce a few "where are they now?" followups -- maybe a year or two is a long time on the web after all.

As always, I thank anyone reading this and in particular anyone following the blog regularly for your time and attention, and hope that you enjoy it at least as much as I.

[Hmm ... re-reading the blog ... now there's an idea.  Five years later I still hadn't done it, but I'm doing it now, slowly, in reverse chronological order, like you see it on the web.  Which is why my heart sank a little when I realized that I've only made it through 148 posts and still have 499 to go (fewer until I get to wherever I ended up when I tried to read the blog through from the other end).

As to the pace of posting, well, that did drop off a bit, didn't it?  Posts from 23 Aug 2007 to 21 Jul 2010: 500, or about one every two days.  Posts from 22 Jul 2010 to 14 Dec 2015: 147, or about one every 13 days.  So basically once every two days vs. once every two weeks.  Ah, well. I still enjoy it.  I just don't do it as much. 

I still have no idea whether there will be a post 1,000 --D.H Dec 2015]

The contours of Twitter

Strange Maps is a fascinating blog of, well, unusual maps, generally accompanied by interesting analysis of what they might tell us about ourselves. The example that led me to the site was a map of Twitter traffic in London.

I'm a bit surprised that more than one commenter is skeptical of the data on the grounds that financial centers like the City show less traffic than areas like Soho. Wikipedia describes Soho as "predominantly a fashionable district of upmarket restaurants and media offices" (which sounds about right) while the City I recall (from a decade or so back) rolled up the sidewalks around dusk as the white-collar crowd headed out to go homeward or pubward to relax.

Hmm ... is one more likely to tweet from the offices of some bank or trading house with the boss nearby, or while relaxing at an "upscale restaurant" afterwards -- or for that matter working at a "media office" during the day? Likewise for the case of Wall Street vs. New York's SoHo and La Defense vs. Levallois in Paris, particularly as Levallois is (Wikipedia again) "one of the most densely populated municipalities in Europe".

I'm more curious what the map would look like normalized for population, that is, tweets per person in a given area as opposed to raw tweets. Are there more tweets in central London than in the surrounding suburbs because there are more people? Also interesting would be a breakdown of both raw and normalized volume by time of day. The raw volume would at least to some degree track the flow of people in and out of the city, while the normalized volume would be affected both by that and by people's daily habits.

[Happily, Strange Maps is still in business, and still keepin' it strange --D.H. Dec 2015]