List your password-format rules up front. All too often, sites ask for a password with no indication of their format rules, then scream “ERROR!” when you don’t guess correctly. Yell at your users less by telling them what you want first.

Don’t limit the size of a password unless you absolutely have to. Honestly, it’s 2012. Databases can store unlimited-length strings, and the security of a password is improved by length. If your user wants to use the Gettysburg Address as a password, let them go for it.

Ditto for the content. If the user wants ancient Greek poetry for their password, then don’t freak out about the character set or complain that it doesn’t contain any numbers. Honestly, I once had a health-care provider prevent me from using spaces and punctuation in a password. “Alphanumeric characters only”. Way to be secure, guys.

Don’t limit the password format at all unless a compromised account will damage your service as a whole. No minimum length, no “special characters” requirement, no “at least one number”. I know, this is a tough one to swallow. Take an honest look at the worst a malicious user could do; if the only harmful effects are to the user choosing the password, then let them choose whatever they want.

Rate the strength of a password as the user types, and give hints on how to improve it. If you do this, though, get it right. It’s annoying to type in “correct horse battery staple” and have some out-of-date algorithm tell me it’s “Weak“. It’s worse if the system rejects it outright, but even the knowledge that your algorithm sucks makes me doubt the overall security of your system.

Check that your login fields are friendly to automatic login. I’m more likely to choose a unique password for a site when I can hand off the job of remembering it to my browser or keychain. Each time I have to click “forgot password”, though, my choice is going to be easier to remember (and probably less secure).

Background:

• A process (X) is run on a series of items in a queue.
• Items are added to the queue continuously, about 500 per hour.
• A processor (Z) is started once an hour. It performs X on all the items in the queue, then quits once the queue is empty.
• If there are any errors, the processor emails them to me after it quits.

The problem:

1. I noticed 100 random failures in process X each hour.
2. I hypothesized that X is failing due to intermittent system unavailability.
3. I checked the hypothesis by looking for clusters of X failures at times of high load. (There were.)
4. I “fixed” it by pausing the Z processor for 60 seconds whenever there’s a failure (to let system resources recover).
5. 12 hours after the fix, I got no failure emails and declared victory.
6. Not so fast: Not only did I not fix the problem, I caused something worse.

Can you figure out what I did wrong?

Hints and solution, Invisiclue™ style (select to view):

• The fix was a single line of code: “sleep 60″ whenever a process X failed.
• The failures weren’t caused by system load; the errors clustered because high load = more items going through the queue. Waiting fixed nothing, so there were still 100 failures per hour.
• Process X normally takes a fraction of a second.
• Processor Z starts once an hour, but that doesn’t mean it stops once an hour.
• Errors are only reported when Z stops.
• The pause makes process X take a minute longer, about 100 times an hour. There are only 60 minutes in an hour.
  
• Since new items are added to the queue constantly, the queue never gets empty and Z never stops. Thus, no errors.
• There are no other hints.
• Really.

These gentlemen are from the future.

You may have noticed how quiet Global Spin has become, yet again. With the rise of Twitter and Reader and Tumblr and other such thing-share-ers, our little community no longer has much reason to post their thoughts to a group blog.

In response, I’m quitting!

…

checks notes Oh wait, that’s not it… shuffles papers One sec, it was right here…

Right! In response, I’m going to keep posting the same old things on Global Spin as always. (In a word: monkeys.) I won’t even promise to post more often, because we’ve all seen through that little shadow play. Or something.

For those of you looking for a little more regularity and a little less depth, I give you a cat… standing up! (Oh, and I might also share some other things over there, because it’s what all the kids are doing these days.)

That is all.

According to the site itself, the messages were both submitted “via Text Message”, which is odd because I haven’t authorized the Facebook Texts service. I submitted a bug report to Facebook Support, but so far they’ve done nothing aside from ask me to resubmit my request if I’m “still experiencing security issues.”

Just to be clear:

• My account hasn’t been “hacked”. I changed my password as soon as the first phantom status appeared, and that didn’t stop the second message two weeks later. Since the phantom messages came from the Facebook Texts service, they didn’t require my authentication anyway.
• My computer doesn’t have a virus. (If you know me at all, you’re chuckling at the idea.) Even if by some magical circumstance it did, the virus would have to send Facebook a text message somehow, and they’d still have to accept it.

That leaves two possibilities that I can see:

1. It’s a bug. Some bit of Facebook code is misrouting another user’s text messages to my profile by accident.
2. It’s a security exploit. A malicious user is exploiting some crack in Facebook’s text-message-handling code to drop messages in other users’ accounts. This is less likely, but not impossible; it would probably start with innocuous messages to test the exploit.

Either way, I no longer trust my Facebook account. The phantom messages have been benign so far, but all it would take is one generic hurtful statement to become a real nightmare. (Not to mention what this implies about Facebook’s security in general.)

I still plan to keep the account itself open, because I need it for work (to develop Facebook apps) and for space advocacy (as a page admin). I just won’t be posting to it, and it won’t be “friends” with anyone. I’ll miss the easy keeping-in-touch it provides, but that’s not worth the potential hassle.

It always seemed to me that you should only need to assign one or the other. If you have a deadline, then what does the priority affect? If the item is high enough priority, isn’t the due date ASAP?

Today, though, I had a flash of insight. The due date defines how much I have to work on the item in order to get it done in time, almost like the velocity of the task. The priority, however, defines how resistant the job is to being derailed by other tasks, more like the inertia or mass of the task.

Put that way, the two values aren’t redundant at all. In fact, you can put them together to determine the overall momentum of a project, based on the combination of the deadline-driven velocity and the priority-based mass. It might even be possible to come up with a formula for determining the outcome of a collision between two tasks, but I’ll leave that as an exercise for the project manager.

Five years later, I can check it off my to-do list. I never got the hardware working, and I didn’t even get past the rough-sketch stage of the design, but other people met my goals for me. The WikiReader (pictured) matches the original WikiBub idea perfectly: it’s simple, cheap ($99), open to hacking, and designed to do one thing (reading Wikipedia) well.

Of course, the idea of a simple-to-use ebook reader without eyestrain or battery issues is no longer new; the Kindle took care of popularizing that one. I also moved on to another hand-held reading device you may have heard of, which (mostly) took away my need for a dedicated reader. Still, it’s nice to see something so true to the WikiBub spirit. I hope it flourishes.

Now that’s going to be a lot easier, thanks to a little programming trickery by John Tantalo. He created a handy bookmarklet that takes standard International Phonetic Alphabet (IPA) transcriptions (as found on many Wikipedia pages) and runs them through a text-to-speech (TTS) system to speak them aloud.

Checking a few known pronunciations against Wikipedia’s IPA for them, I see that either the TTS server or the listed IPA needs some work. I suspect the latter, because the IPA for the Niger River entry (/ˈnaɪdʒər/) sounds great, while the IPA for Nagios (/ˈnɑːɡi.oʊs/) sounds way off (as I write this at least). Still, most entries work great, and I expect this tool to encourage more authors to include IPA as it gets used.

In 2001, Apple came out with a portable MP3 player. There were plenty of MP3 players on the market, but none of them were particularly impressive. Initial reviews told people to expect an Apple offering that was too big, lacked features, and was way too expensive. What they got instead was the iPod. It was revolutionary, and MP3 players were never the same.

In 2007, Apple came out with a smartphone with an integrated iPod. By this time, people realized they should expect something revolutionary, but revolutions are tricky to predict. Rumor sites and pundits worked themselves into a frenzy telling people to expect an iPod with phone capabilities crammed in, or a phone with an iPod tacked on. What they got instead was the iPhone. It was revolutionary, but not the way anyone expected.

In 2009, Apple might come out with a tablet computer. As before, everyone and their dog is trying to guess what it might be like. We’re being told to expect a big iPhone, or a web tablet, or some kind of ebook reader. What I expect instead, based on all that’s gone before, is the unexpected.

http://globalspin.com/2009/05/22/1531/
http://globalspin.com/2009/05/livable-streets/

A bit nicer, right? Here’s the tricky part: the old URL still works, redirecting automatically so no one need get lost on their way in. I’d love to take credit for such a slick bit of business, but it was really simple thanks to Dean Lee’s Permalinks Migration Plugin.

So when I want to remember something, do I “star” it or “like” it? If I want to let people know about it, should I “like” it or “share” it? Is my “note” shown as a “comment” or somewhere else?

I recognize the thinking here; if users are looking for a feature by a familiar name (“like”), they might not find it by your own convention (“star”). This half-baked mix of features isn’t the answer, though. Each addition should have been weighed against the existing choices, and if the benefit justified the new feature it should have replaced the old.