Urbandictionary vindaloo

Sometimes it's good to remember that www stands for World-Wide Web.  One fun example is Samosapedia, a burgeoning collection of slang from India and thereabouts, built on the same basic user contribution and rating scheme as its older cousin Urbandictionary, but twelve time zones away and, from my brief survey, without so much outright gamy material (somewhat off-color material, on the other hand ...).

Slang is an interesting window into a culture or cultures.  The slang here is every bit as lively as anyone else's, and thanks to the web we can all get a glimpse.  A few more-or-less random examples

• Cup ice cream -- literally, what you'd expect, but the local flavor is in the details
• Item number -- a bit of Bollywood
• Do the needful -- um ... just how would you say that in, say, American English?

My favorite, on a par with the mighty might could, is cannot able to (listed under cannot able to be and, commentary notwithstanding, no more "warped" than many an "acceptable" construct).

Forbes on passwords

Wandering through the web (but not necessarily figuring it out as I went along) I ran across a slide show in Forbes on the subject of passwords, with what seems to me mostly reasonable advice.  Some highlights, mostly common-sense stuff that bears repeating:

• Change important passwords frequently and don't reuse them
• Use different passwords for different purposes.
• Important passwords (e.g., for bank accounts) should be unique. 
• Less important accounts can share passwords, but be aware that if one account is compromised you should consider all of them compromised.
• Don't choose a password that's ever appeared elsewhere.  This rules out memorable phrases like "We the people of the United States of America".
• Passwords should contain nothing personally associated with you (basically a version of the previous item).
• Password managers may be useful.  The advantage is you can use random gibberish and the manager will remember it for you.  The disadvantage is that if the master password is ever cracked, you're completely hosed.
• Use HTTPS when logging in.  HTTPS encrypts all connections and uses digital certificates to ensure that you're really talking to whom you think you are (just exactly how secure this system is is a whole other can of worms, but for now let's assume it's basically OK). You can tell if you are because web sites with it start with "https://" instead of "http://" and browsers now indicate whether you have a secure connection
• Don't type your password into anyone else's machine.
• Assume that a public WiFi access point is just that, public (the actual slide says to avoid it entirely).  If you're not using an encrypted connection of some sort (HTTPS, SSH, a VPN or such) assume that anyone can see your network traffic, including passwords you type when you log in.  Also assume that any random person can see anything that's publicly shared on your computer (another fine can-o-worms).
• Don't depend on passwords generated by web sites or random software.  Even if everything's on the up-and-up, it's very easy to get password generation wrong, typically by using a weak random number generator (see this post for more on generating passwords).
• Archive your important passwords in case of catastrophe, for example by writing them down on a piece of paper and storing it in a safe deposit box that can be opened in an emergency.
• In general, if you're going to record a password somewhere, do it on a physical medium separate from your computer (see disadvantage of password managers, above).

There are also a few items that don't seem actively harmful, but probably don't help greatly either

• When replacing letters with numbers and such, use non-obvious numbers, e.g., r7place instead of r3place.  This will add a few bits of entropy, which is good, but not really good enough on its own.  If your base word is in a dictionary of 500,000 words and you replace up to three characters with one of 15 replacements, you have about 30 bits of entropy, which is not that much.
• Add a number to the end of sentence-based passwords "for extra uniqueness".  Adding a number adds about three bits of entropy.  Meh.
• Scramble a password when writing it down.  This will make it harder, but not impossible, for someone who finds your written password to figure out the actual password, but it will also make it harder for you to come up with the actual password at two in the morning when you discover you don't quite remember how you scrambled it and the Very Important Site locks out accounts with more than three login failures.  Of course, you could write down how you scrambled it ...
• Deliberately misspelling words can make passwords more secure.  Yes, but not very much more secure.
• Use a sentence with lots of words, and include punctuation.  In theory this can work, but in practice people come up with much-less-than-random-words, particularly if the sentence actually makes sense.  Also, surprisingly many systems get indigestion if you try to use a long password.

Considerate software

I first heard the motto "Considerate software remembers" a job or two ago from interaction designer  Carl Seglem, who credited it to Alan Cooper of About Face fame.  The phrase has stuck in my head ever since, so the other day I went searching for it and found this extract on codinghorror.com.

There's a lot to like about the very idea of considerate software.  If I'm using a piece of software, I want it to do something for me.  I'm going to be devoting a great deal of attention to it, asking it to do this or that and expecting responses to those requests.  Ideally, someone or something I'm working with that closely will treat me considerately, just as I should make every effort to treat a person I'm working with considerately.

More subtly, the metaphor of considerate software cuts the designers and implementors of the software completely out of the picture.  This is surely deliberate and completely appropriate.  Once software is deployed, the designers and implementors are out of the picture.  I can't come and ask them how to deal with some puzzling or frustrating bit of behavior (and lucky for them, sometimes).  As far as I'm concerned it's the software that's being helpful or annoying.

There are clearly limits on how considerate software could possibly be.  If I decide to type in a long treatise on considerate software into the "shipping address" field of some form, I wouldn't expect the app to respond "Why yes, that's very interesting.  I personally find Cooper's work exemplary.  Shall we continue this conversation over coffee?"  However, it doesn't seem too much to expect a politely phrased, helpful response pointing out that "I first heard the motto ..." followed by several paragraphs does not look like a valid street address.

I don't need to go into detail here about how far short much software falls in this regard.  I'm sure you've got your own examples.  Neither do I want to go into how and why software comes to be inconsiderate, though that's an interesting topic in itself.  Instead, I'd like to go into what qualities make software considerate or inconsiderate.

The list I referred to above hits a lot of interesting points, but it feels more like a list of this and that than a thorough taxonomy.  In particular, the headings, while snappy, don't always seem to match up well with what they head.

Some of the points fall under "Considerate software remembers":

• "Considerate software takes an interest" is really just saying it shouldn't ask for the same information over and over.  That is, it should remember what you've already told it.
• "Considerate software is perceptive" says that software should remember what we do.  It also says that it should adapt its behavior based on what it knows.  More on that shortly.
• "Considerate software takes responsibility." says that software should remember where it is and be able to restore its state as closely as possible to where it had been before something derailed it.

Other points assert that software should know the kinds of things that we know and it can reasonably be expected to know:

• "Considerate software uses common sense."  Common sense is not some magical filter that separates sensible behavior from senseless.  It's largely a body of knowledge, whether learned or instinctive.  To keep from, say, sending a check for $0, it needs to know that checks should only be sent for positive amounts.
• "Considerate software anticipates needs."  To anticipate needs, a piece of software needs to know what those needs are.
• "Considerate software knows when to bend the rules." Is saying that it should know how (and when) to do more than just the narrow definition of its task.
• "Considerate software is forthcoming." says primarily that software should actually tell us useful information that it knows, but to do that it may need to know information outside a narrow view of what it should be doing.

A third set has more to do with knowing when and when not to offer information

• "Considerate software keeps you informed/is forthcoming." Not only should it know useful things we didn't specifically ask it to know, it should let us know that and modify its behavior accordingly.  But ...
• "Considerate software doesn't burden you with its personal problems/is self-confident/doesn't ask a lot of questions." It should limit itself to interactions useful to us, present information in ways that are easy for us to absorb and ask for information in ways that are easy for us to present.

A couple seem more about letting us exercise our judgment instead of trying to exercise it for us

• "Considerate software is deferential."  Software should not prohibit things that might be useful.  Instead it should make sure we know the consequences of a choice and then let us make it.  It occurs to me that the "undo" feature is particularly helpful here.
• "Considerate software is conscientious." The principle here seems to be that software should know that some things are dangerous and not simply assume that we mean to do them.

Taking a stab at boiling this all down:

• Considerate software knows as much as reasonably possible about its domain.
• Considerate software remembers what's happened, what we've told it and what it's told us.
• Considerate software modifies its behavior where appropriate based on the above.
• Considerate software gives us ways to access to what it knows (including the state of the world as it used to be).
• Considerate software actively tells us important things we might not already know.
• Considerate software communicates efficiently -- taking into account how human minds work.

These principles seem fairly universal, but it's worth noting that one of the first extensions to the original web protocols, and one that enabled major improvements in the experience of using the web, was the cookie -- a way of letting a web site remember things that have happened before and, ideally, act accordingly.

Building a better password

[I've updated this post slightly to reflect the back-of-the-envelope calculation in this post suggesting that 100 bits of entropy is probably more reasonable than my original statement that 48 bits was "not bad".  Under the assumptions in that post, a 48-bit password would take on the order of microseconds to crack --D.H. Feb 2020]

I've recently complained about the irritating nature of the password strength checkers that have been popping up everywhere, so I feel obliged at least to try to analyze the problem and offer solutions.  This is leaving aside the question of whether password authentication is a useful approach at all.

Fundamentally the real measure of password strength is how many passwords you'd expect to have to guess in order to get the right one.  A more formal version of this is the notion of bits of entropy.  If you had a list of all possible passwords in your scheme, I could identify any particular one so long as I could get answers to a series of yes/no questions, for example:  "Is it in the first half of the list or the last?",   "Is it in the first half of that half or the last?" and so forth.  The number of such questions I need is the number of bits of entropy.  Twenty questions means twenty bits, etc..

If I know that your password is either "0" or "1", you have exactly one bit of entropy.  If I know it's an uppercase letter, lowercase letter, digit, "$" or "%", there are 64 possibilities, so you have 6 bits of entropy.  If I know it's two such characters, you have 12 bits, and if it's seventeen such characters you have 102 bits, which is not too bad.  Someone trying to guess your password would have to guess about two thousand billion billion billion passwords, on average, before stumbling on yours.  That may seem like a lot, but keep in mind that the current network of Bitcoin miners can try on the order of a hundred thousand billion billion hashes -- roughly the same problem as guessing a password -- every second.

[Don't assume that guessing a password requires typing it in to the same text box you have to use.  If someone steals the right data from your service provider, they can throw as much computing power as they've got at guessing the passwords.  Quite possibly they'll be happy enough just to try a few thousand weak passwords for each account, since that will crack depressingly many, but attacks like running through the OED with simple substitutions of letters for numbers are absolutely feasible as well, even on fairly ordinary hardware.]

This is assuming that you picked eight characters at random.  If I knew instead that your password was either "F1%ldN0t3$" or "sasssafras" (maybe I'd watched you read your password off a piece of paper with only those two words on it but couldn't quite see which you were typing), then you have only a single bit of entropy, even though both passwords are not just eight but ten characters long and one has plenty of non-letters.

More realistically, if I knew you'd picked an uncommon English word and maybe changed some of the letters to numbers, you'd have somewhere around two dozen bits of entropy.  That's not nothing, but keeping in mind that each added bit doubles the number of passwords a cracker has to try, it's nearly a billion billion billion times weaker than the 102-bit scheme above.

The fundamental flaw of password strength checkers is that they can only look at the password you gave them.  They have no idea what other possible passwords you might have chosen.  The assumption is that if you're forced to jump through enough hoops you'll be forced to expand your parameters, but in fact it's possible to generate passwords in a secure manner using only letters, and or to generate them insecurely in a way that will still satisfy any strength checker out there.  Which is why I half-grimace, half-laugh when I see the "password strength indicator" jump from "poor" to "great" as soon as I type a number.

Now, it's perfectly possible to generate completely random 17-character passwords.  The problem is that something like "qcrQf1x2" or "u%js%hPQ" is a pain to try to memorize, so most people will fall back to picking a "hard" word and maybe altering it a bit.  However, as xkcd points out, it's possible to do a lot better by using random short words.

For example, here's a kind of clunky way of producing a random, memorable password:

BIG HONKING DISCLAIMER: This is just for demo purposes.  The second site I mention uses http, not https, so in theory anyone could be looking in on your session.  Even with https, the sites might be logging all your traffic and recording the results you come up with.  I personally seriously doubt they would, and it's hard to imagine they would be able to connect the dots and figure out what you were using the generated password for, but if you really want to be on solid ground, get the source, look it over, run it locally and use something like /dev/urandom or D&D dice to generate the random input (23d20 will give you close to 100 bits ... not that I would have any idea at all what "23d20" means).  There are also smartphone apps that do more or less the same thing, I believe.

[I last checked that the recipe below worked on 28 Feb 2020]

With that out of the way:

• Go to this site and copy the random string you see there (e.g., 60990FFC250C).  If for some reason you don't like what you see, just reload.
• Go to this site.
• Type some short number and a space into the Challenge box and paste the random string from the first step in after it (e.g. 123 60990FFC250C)
• Type anything at all into the Secret box (e.g., "secret").  This doesn't have to be hard to guess.  The real entropy is coming from the random string (alternatively, put any number you like, a space, and anything else into the "challenge" box and paste the random bytes into the "secret" box).
• Press the Compute with SHA-1 button.  Again, the cryptographic details of how strong SHA-1 is don't matter here.  You're just converting a random number to short words.  A simple table lookup would do just as well.

In the Response box you will see six short words followed by some hexadecimal gibberish (in this case, WOVE COOT SLEW WIT SIGH I (FE2D 5F7B 22CD BC39)).  Each of those words represents just over 10 bits of entropy.  We'll need ten words in all, so repeat the procedure but this time just take the first four words (I got FIRE CUFF GALA MINK from A4B455FEFFE7BFAD).

You can play around with this formula to get words that are easier to memorize, or type, or are just more to your liking.  If you reorder your words or try typing in several different things instead of 123 or secret and then picking what you like, you're decreasing your entropy, depending on what criteria you're using to filter out passphrases you don't like and whether your attacker knows what kinds of phrases you like.  If you just try a few different secrets until you see something that seems memorable, that should be fine.  If you do something like sort the words (and your attacker knows only to try sorted lists of words), you've lost almost 22 bits of entropy, which wouldn't be good.

Once you've selected your words add a random punctuation character, number, capital letters or whatever makes your site's password strength checker happy.  Voila!  Your password is now Wovecootslewwitsighifirecuffgalamink5? or whatever.  This isn't great to have to type, but it's pretty secure as passwords go, and probably better than trying to remember something like C;cTbfThoO4ePFTt or 67EE386A205C4563DB8908A6C4.

If your site's password checker imposes an 8-character limit (and, incredibly enough, some do), cry.

Oh right ... I write a blog, don't I?

A couple of housekeeping items, before I attempt to get back to real blogging:

• No, I haven't fallen off the face of the Earth, been trapped under a large object or wandered off to Nepal to contemplate the mysteries of the universe.  Just busy, and decided to devote what little blogging bandwidth I've had lately to contemplating the nature of awareness on the other blog.  Hmm ... maybe Nepal wasn't so far off.
• A couple of logins ago, AdSense advised me that I appeared to have a "popular blog" and I should consider advertising on it.  I'm always glad to know that people are reading Field Notes, but I suspect that AdSense and I have somewhat different notions of "popular".  As much as I would like to bump my employer's revenue stream up by another 0.0000000000000001% or so, I have no plans to do that at the moment or any time soon.  I'm not against running ads per se, but I don't see the point of cluttering up the layout for what I doubt would be any significant gain.  If you ever do start seeing ads here, it will be because there has been a dramatic surge in demand for occasionally-posted web.musings, in which case why not?
• Prompted by a couple of recent comments, including a couple of completely appropriate ones,  I've settled on a definition of spam comments:  If it's completely independent of the post it's supposedly commenting on, it's spam and will be summarily removed. Mentioning your favorite business as part of a thoughtful response to a post on customer service is just fine.  Mentioning your website, commercial or otherwise, with nothing more than a generic "Hey, great blog!" comment is spam.
• Mind, I reserve the right to delete any comment for any reason or no reason (hey, it's my blog).  But as a practical matter I'd only expect to do so in cases of spam or incivility, should it occur.  As part of recusing myself from matters Google (and yet still trying to write about the web), I would also remove any speculation about what Google might be up to, be it public information or not, accurate or otherwise.  I don't expect that to be a problem, but thought I'd mention it.

And ... we're back!

Worst ... user experience ... ever (how to turn on your wireless radio)

[Doing a little more searching after I wrote this, I eventually learned that it's not just a few oddball brands that have this problem, and that some models really do have physical switches.  If you're banging your head trying to get your wireless turned on, this list might help.  It told me where to look again for the small, black-on-black slider switch on the laptop I was dealing with.


As always, I make no warranty that this will help you.  I particularly don't vouch for the spammers halfway down offering to crack passwords for you.  --DH]

OK, this isn't really much to do with the web, except that you can't really talk about the web unless you can actually connect to it, and it's really just a bunch of griping, but ...

Who in the Windows world decided it was a good idea to make laptops keep their wireless radios turned off until you find the right magical incantation to turn them on?  Did Steve Jobs sneak into Steve Ballmer's house at night and put an iPod loaded with subliminal messages under his pillow?  "Turn the wireless radios off ... trust me ... people will love it!"   Did someone decide that having wireless connectivity was too simple and useful?  No?  What, then?

I'm trying to imagine a portable device in this day and age that you don't want to be able to connect to the the nearest hotspot.   Smartphones do it.  Tablets do it.  Netbooks do it.  Even set-top TV boxes and video games do it.  One of the first things you do with most new gadgets is locate the nearest hotspot, connect up to it and say "Ah ... that's better."  At least if you're me, anyway.

Is this supposed to save the battery?  I can see that, but why have a separate control?  There's already a "disable" option for the wireless if you want to go offline (or wired, or into "airplane mode").  That should turn the radio off, no?  Conversely, if I enable the wireless I want the radio on.  Duh.  Do I really have to spell that out?  Evidently.

OK, fine.  You need to turn the radio on before I can use the wireless.  How do you do it?


Typically you futz around the network area of the control panel until you stumble on a help message that says to flip a switch on the front or side of the laptop.  I have never seen such a switch.  Why would there be such a switch?  How many other such switches are there on a modern laptop?  Typically, there's a power button and ... um ... yeah, that's about it.  [As mentioned up top, I have now seen such a switch.  I am no more impressed than before.]

I've seen other attempts at handy buttons for some novel function, but always in the keyboard area, and never for very many product cycles.  A switch is another moving part and an added design and manufacturing expense in a cutthroat business.  It only makes sense if it's for something that people really want to be able to do in one quick step.  Who, exactly, is asking for the ability to instantly make their mobile, web-enabled computer nearly useless?

So there's no physical switch readily apparent.  That leaves the software equivalent.  The previous time I had to jump through this hoop I was able to find some forum somewhere that said what to run to do the trick.  This time -- as you an probably guess -- not so much.

Oh, there's a function key that will pop up a grayed-out-looking but otherwise pretty little box with an icon denoting the wireless radio, x-ed out with a nice red x (Dedicated function key?  Who are all these people asking for a shortcut to do something I've never, ever wanted to do nor known anyone who admitted to wanting to do?).  Clicking on the box does nothing.  Pressing the function key again in hopes that it's a toggle that I somehow just turned off does nothing.

There's in icon in the tray at the bottom, bearing a similar x-ed out icon, that you can right-click on.  It will tell you that you need to turn your radio on.

There's a setup application supplied by the hardware manufacturer (this is one area where closed architectures like the Mac win).  It offers to set up the wireless hardware for you.

But first you have to turn the radio on.  Of course.

Search the forums.  Someone suggests uninstalling the drivers and rebooting.  Well naturally.  If I want to turn on the lights in my house the first thing I do is uninstall the wiring (never mind rebooting).  Try that.  Nope.  Flip a couple of checkboxes buried deep in the bowels of the "Device manager" menus.  Nope, sorry.  Maybe the drivers -- that the manufacturer shipped with -- are out of date?  You could try updating them.

If you had an internet connection.

Maybe drop-kicking the thing off the roof of a tall building will do it?  Seems worth a try ...

Shave and a haircut: two bitcoins

Someone the other day was mentioning Bitcoin, which calls itself the first decentralized digital currency.  Regular readers of this blog, a select group to be sure, will probably not be surprised that this sent my not-so-disruptive-technology sensors into high gear.  So what's a decentralized digital currency?

Virtual worlds often have virtual currencies, which citizens can earn by doing various things in the virtual world and which they can exchange within the world.  In at least some cases these virtual currencies have leaked into the real world, or been tied to real money to begin with, not always with happy results.  One can view Bitcoin as abstracting that process and removing it from the confines of a closed, proprietary virtual world.

Bitcoin uses a modest ensemble of established crypto techniques to create a public audit trail certifying that a particular person has generated a Bitcoin, or that one person has exchanged some possibly fractional amount of Bitcoin with another (and by "person" I really mean "whatever has control of a given private key").  Generating bitcoins and certifying transactions requires a non-trivial amount of computation, much as generating money in a virtual world requires a non-trivial amount of whatever one does to earn money in that world.

There are various safeguards to ensure that each unit of Bitcoin has exactly one owner and everyone has a consistent view of who owns what.  That view can change over time.  In other words, Bitcoin meets some basic requirements for a currency: It is transferable, limited in supply and difficult to duplicate or forge.  So far, so good.


It occurs to me that there is actually already a very widely-used decentralized digital currency, namely money.

While it is still possible to exchange cash for goods and services, an awful lot of commerce gets done without it.  Instead, various banks and other entities simply increment and decrement balances in various accounts.  If I pay you, my balance goes down, yours goes up and one way or another our banks and various intermediaries get to take a cut.  This is certainly digital, and it's certainly currency.  It's also decentralized, in that there are many banks, particularly once we move into the international arena, and not even the various central banks have complete control of what happens.

However, it's not as radically decentralized as Bitcoin aims to be.  Bitcoin aims to take out all intermediaries.  If I pay you in Bitcoin, everyone in the system will be informed, reasonably soon, that I now own that much less Bitcoin and you own that much more.  All participants are an essentially equal footing.  There are no banks, clearinghouses or other such entities at all.

More precisely, everyone learns that whoever controls my private key has that much less and whoever controls yours has that much more.  Whether anyone knows who controls what keys is a separate matter.    Bitcoin uses pseudonymity -- known names tied to possibly unknown entities -- to recapture some of the anonymity of cash transactions.

The Bitcoin documentation is very careful to make the classic economical distinction between value in use and value in exchange.  The computational work done in producing Bitcoin and validating transactions is not inherently useful.  It basically consists of guessing numbers until one the right one comes up (technically, one that contains a given bit string and hashes to a particular value).  The value, if any, comes of people being willing to use Bitcoins in exchange, that is, as currency.  This is no different from printed pieces of paper or numbers in databases or, for that matter, materials like gold whose prices -- that is, their exchange rate with paper currencies -- are largely decoupled from their practical uses.



So this looks well thought through and doesn't seem wildly implausible.  Why was my spidey-sense tingling?

In trying to make sense of this I went back and reviewed the concept of currency.  Except there doesn't seem to be a nice, crisp, near-universally accepted concept of what makes currency work.  Scarcity is required, in the sense that the supply of currency must be bounded, albeit typically large.  Gold and other precious metals are hard to produce.  Coins are limited by fiat -- the king's mint will only put his face on so many coins, and woe betide the counterfeiter -- making it less important what the coin is made of.  Notes carry this one step further.  Clearly it doesn't matter much how much the paper and ink is worth, only that it's difficult to duplicate the note itself.

Numbers in databases are completely abstract, and they seem to work fine.  So why not Bitcoin?

At the end of the day, currency has to be exchangeable for something useful, for example, food.  This can only happen if the person accepting currency in exchange can be confident that they in turn will be able to exchange it for something useful to them.  Bitcoin works hard to ensure that it will behave essentially like physical cash and carefully-regulated changes in bank balances, but that still doesn't make it a currency.

And that's the crux of it.  Will people trust that Bitcoin will remain exchangeable?  What is the mechanism for maintaining confidence?  Typically, this confidence is based on confidence in a government, but other systems work as well.  Failed states may continue to circulate currency well after the government has collapsed.  Some countries are perfectly happy to use another country's currency.  Local communities have been known to create their own currencies which rely on the communal bond among members.  All of these and more can work, so why not Bitcoin?

Well, maybe it can.

The best measure I can think of for the viability of a new currency is how it converts to and from existing ones, and there are Bitcoin currency exchanges which do just that.  From what I can tell, the jury is still out, if only because Bitcoin hasn't been around that long yet.  Bitcoin is currently trading around $14, but it's been as high as twice that in the past couple of months and much, much lower not long before that [and on 28 November 2011, around $2.75, less than 10% of the all-time high ... given that the earth shook slightly when the Swiss Franc dropped from around $1.27 to around $1.16 and that Sterling's fall from 2.80DM to around 2.55 helped bring down a government, this sort of volatility does not look good ... my source for the price, mtgox.com, is now offering options and margin trading on the bitcoin, just in case anyone wants an even bigger adrenaline rush -- D.H.].  On the one hand, a non-zero value is encouraging, but on the other, that sort of volatility doesn't inspire confidence.

Personally, I don't see much reason to use Bitcoin in any significant way.  Money has worked fine so far, and if the US dollar should collapse, I'm not exactly convinced that Bitcoin would become a safe haven.

Messin' with the buttons again

It took a couple of tries, because the template I use is a fairly old one, but I've made a couple of tweaks to the buttons at the bottom of posts

• The old hand-crafted Digg widget is gone.  So far as I'm aware, no one has ever Dugg this blog.
• The old email button is gone
• In its place is an all-singing all-dancing set of share buttons, comprising (as I write this)
• email
• share to Blogger
• share to Twitter
• share to Facebook
• share to Google Buzz
• +1 -- a quick way to say "I like this", should you ever be so inclined

and of course, if you just want to read the post and be done with it, you still can do that, too.

Wikipedia tics

I'll say it again: Wikipedia is great.  I use it all the time.  It does its job astoundingly well, particularly given that when it was first getting started any sensible person could have told you it couldn't possibly work.  Anyone can edit it?  Anyone can write anything about anything?  And people are going to depend on it for information on a daily basis?  Riiiight.

But it does work, thanks to countless hours of effort from dedicated Wikipedians hammering out workable policies, nurturing the culture behind those polices and putting those policies into practice by editing a stupefying number of articles.   It is this endless stream of repairs and improvements that keeps Wikipedia from devolving into chaos.  It's a wonderful thing, but wonderful is not the same as absolutely perfect (for starters, one is achievable and the other isn't).  Anyone who's read Wikipedia more than casually will inevitably have a few pet peeves.  Here are some of mine (and yes, I do try to fix them when I come across them, time permitting):

• Link drift: Article A includes a link to article B.  Article B gets merged into article C and the link is changed to point to article C -- not the section, but the whole article.
• More link drift: Article A includes a link to article B.  Someone creates an article on a different meaning of B.  The article for B becomes a disambiguation page, and the article on A continues to point to it.
• Digression:  Article A has some connection to topic B, which people Need to Know More About.  Instead of just providing a short summary and linking to the article on B, an enthusiastic editor gives the complete story of B, in nearly but not exactly the same form as in the original article (or, the digressive section moves to its own article, but the section later regrows).
• I'm really into this: An article is stuffed with unsourced Things You Didn't Know about the topic, often to the point of downright creepiness.
• Some say ... yes, but some other people say ... yes, but ... :  People feel strongly about topic A.  Generations of editors qualify each other's statements until the article reads like a pingpong match. Usually an effort is made to collect the clashing statements into one section, but that doesn't always keep them from escaping into the article at large.
• Actually, everybody gets this wrong:  An editor makes a great point of declaring some piece of common knowledge incorrect without bothering to check if this is really the case.
• This is a very important distinction:  Instead of saying something on the order of "not to be confused with [link]" or such, an editor feels that it's worth including a sentence or two on either side of some valid but not earthshaking distinction emphasizing how crucial it is (see previous item if the distinction in question is invalid)
• Take it to the discussion page, please: A discussion that ought to be lightly summarized is hashed out in excruciating detail before our eyes.
• Oh look, I can write a textbook/conference paper, too!:  Editors seem to make a special effort to pepper their writing with the mannerisms of their professors or other authorities.  Math articles seem particularly prone to this ("clearly ... it turns out that ...").
• My home town/band is the awesomest:  Material on a place or group reads like your cousin showing you around on a visit.  I actually don't mind this, so long as it's not too overboard, even though it generally runs somewhat afoul of Wikipedia's notability policy, because how else does one find out about the Anytown Moose-waxing festival or the real meaning of "incandescent oak" in that one song (don't go searching for those -- I made them up).
• This article reads like it was written by dozens of different people over the course of several years:  Well, yeah.  The real magic of Wikipedia is that relatively few articles read like that, particularly if they really have had a chance for dozens of different people to work on them over the course of several years.
• [One other tic occurred to me not long after I hit "Publish": Gratuitous wikification.  To "wikify", in wiki parlance, is to make an ordinary term into a link to the article for that term.  It's one of the things that makes wikis wikis, but sometimes people seem to go randomly overboard, occasionally with fairly odd results.]

Wikipedia's strength is in its transparency.  For the most part, you can see every draft of every article if you want to, every mistake, every correction, every paragraph in need of tightening, every statement in need of a reference, every quibble, every pointless edit war -- in short, everything that a normal publication, encyclopedic or otherwise, goes to great lengths to hide.  The downside is that flaws like the ones listed above are also there for all to see.

The upside is that we get Wikipedia.

This password madness has got to stop

It's well known that people like to choose bad passwords, and for years other people have suggested rules for making passwords more secure.  I'm not really sure why it should be happening now in particular, but it seems that every site that has a password must now jump on the bandwagon and have a password policy enforcer.

And of course, they're all a little different.

Fortunately there are plenty of possibilities.  Here's a do-it-yourself guide in case you think your site needs one.  First, pick any two of

• The password must contain at least one number
• The password must contain at least one lowercase letter
• The password must contain at least one uppercase letter
• The password must contain at least one special character

Next flip a coin to pick one of the remaining two to disallow.

Now pick a minimum length.  Back in the day, when computers were much slower than they are now and it wasn't fairly easy to get a gazillion computers to cooperate (with or without the owners' consent), the recommended minimum length was eight characters.  Today it should probably be more like 12 or 14.  So make sure the minimum length is at least six.

Now set a maximum length of 8.  Why a maximum, given that all other things equal, longer passwords are stronger, and the whole point of the exercise is to encourage strong passwords?  Don't know.  Probably whoever put the database together remembered the old eight-character rule and decided that should be the maximum.  But 8 is a magic number for passwords and everyone else does it.

Finally, add an arbitrary hidden restriction.  For example, if the password has to have a number, make sure it can't be the first character (yes, I ran into that one).  If it has to be a special character, quietly disallow '$' and '!'.  Something like that, just to reduce the strength and make people work a little harder.

Voila.  You now have a password policy.  If I did that math right, there are three dozen basic policies, times however many arbitrary rules there are, so there are easily hundreds of possibilities.  Chances are fair that your poor user will never have encountered your exact policy before and never will again.

Chances are also fair that once they jump through all your hoops (bonus points if this is all happening on a smartphone or tablet), your poor user will have never come up with that particular password on the spot before.  That's good, since sharing passwords can be dangerous.  The only drawback is that poor user is liable to forget this ad-hoc password within five minutes of logging in.

So urge them to write it down "some place safe."

Then have them pick three or four secret questions and answers for when they have to reset the password next time they log on.  But that's a different rant.


If you feel you need further security advice, you can always consult a real expert.

Now available in sleek mobile templates

Blogger offered me a new feature to turn on, and it looked cool, so I turned it on.

If you're accessing this on a mobile device, you should now see the blog in a much less cluttered format, better suited to the small screen.  I haven't tried it from a mobile device yet myself, but the preview looked good.  Hope you like it.