It may surprise you to discover I still work with Facebook on a daily basis. I did leave Facebook as a user over three years ago, but wrangling the Graph API is still a core part of my job. (For the web developers among you: It’s like your relationship with Internet Explorer.)

Last week I was updating Measured Voice to match changes in the Facebook permissions dialog, and I noticed that the documentation said one of my permissions was now out of date:

“Facebook used to have a permission called publish_stream, publish_actions replaces it.”

– from the Facebook API’s Extended Permissions documentation

In a fit of eagerness, I broke the first rule of API usage* and switched out publish_stream for publish_actions. However, it soon became obvious that the two weren’t equal. The auth tokens produced before and after my update were markedly different:

with publish_stream

with publish_actions

Requesting publish_stream gave me publish_actions anyway, which makes sense if the two are being treated as equals, but it also gave me a whole passel of other permissions I hadn’t asked for. As it turns out, at least one of those permissions is still necessary to do what I need: post status updates and photos to a Facebook Page.

But which one? I checked the documentation again, and… well, none of them are documented at all. Not listed anywhere, not mentioned as deprecated, not anything. Huh. Some of them do sound like permissions I’d need (photo_upload and status_update, for example), but without documentation it’s just a guess.

It sounds like the documentation is ahead of the actual API development, and reflects some design goal instead. Or maybe this is (yet another) API bug. Either way, I’m going back to requesting publish_stream until they get their facts straight. It still works. (For now.)

* “If it ain’t broke, don’t upgrade to the new revision.”

Passwords bug me. Specifically, password management on most websites is maddening. Here are a few things to keep in mind when designing yours:

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

Yesterday I did something dumb, and I only realized it today because I don’t trust an easy success. Let’s see if you can spot the flaw in my reasoning:

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? Continue reading →

Starting today, I’m going to remove all my personal information from Facebook and “unfriend” everyone. I’m responding to a pair of status messages that appeared on my profile over the last few weeks, though I didn’t put them there. (John calls them “phantom status messages.”)

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.