(I reference this so often that I figured I’d better post this here)
Threes, Rev 1.1
By Elms and L. Fish

Deep in Engineering down where mortals seldom go,
A manager and customer come looking for a show,
They pass amused among us and they sign in on the log,
They’ve come to see our pony, and they’ve come to see our dog.

Three things you should be wary of: a new kid in their prime,
Someone with all the answers, and the code that runs first time.

Summoned from our cubicles to conference rooms we go;
We bring our dog and pony cause we know they want a show.
Watching as we enter with a shifty routine eye,
The customer sits waiting in his pinstripe suit and tie.

Three things never trust in there: a vendor’s final bill,
The promises your boss makes, and the customer’s good will.

The pony kicks his heels up as the doggy does his trick,
And hands are waved with vigor as we lay it on — real thick.
The customer just watches as we do this song and dance,
Then reaches for his briefcase scarcely giving us a glance.

Three things see no end: a loop with exit code gone wrong,
A semaphore untested, and the verses of this song.

From briefcase then there comes a list of things we must revise,
All before within the room are taken by surprise.
And all but four are thinking of their last job with remorse:
The customer, the manager, the doggy and the horse.

Three things hold no secret: files that somehow hit the net,
Your boss’s secretary, and the third thing — I forget…

First thirty-seven changes that somehow we must add in,
Then twenty one new features show up much to our chagrin.
And this thing’s just inadequate, and that one’s just plain wrong,
And by the way, your schedule is about three months too long.

Three things it is better for that only you should know:
How much you’re paid, the schedule pad, and what is just for show.

The customer proceeds to go through each change line by line,
Excruciating detail that no logic can define.
When it ends there’s only four not sitting there aghaw:
The customer, the manager, the pony and the dog.

Three things never anger: first the one who runs your DEC,
The one who does your backups, and the one who signs your check.

Now we here all are software types who spend ours days and nights
Embedded in the system down among the bits and bytes,
And none but us can tell full well the damage done today,
It’s for what they do not know for which they’re gonna have to pay!

Three things are most perilous: connectors that corrode, new
Unproven algorithms, and self-modifying code.

The manager and customer are quick to leave our bunch,
They take the dog and pony and they all go out for lunch,
Now how will we revenge ourselves on those who raise our ire?
Self-destructive code that goes the day the warranties expire!


(Taken from



I was on my way back to visit my family in the UK, and asked my sister what I could bring.  After a quick canvassing, the answer came back: my niece wanted me to record a piece to which she could study.

So, with great thanks to Hypno for having the percussion ready, and for his usual recording and mastering magic, we recorded the following in pretty much record time.  Enjoy!

Once QA, always QA.

Before I launch into my sociotechnological observations, let me define some terms, and maybe fill you in a little on my background.

QA stands for Quality Assurance1 – in this particular context, Software Quality Assurance.  Infosec is short for Information Security, the people charged with protecting us all from (for example) having our iphone data or Sony accounts posted on the web.  IT of course stands for Information Technology.  And by the way, IT is more than just being the poor bastard who gets sent out to the desk of a wonky computer: it means infrastructure and phones and usually power and AC and sometimes fire suppression. It means the care and feeding of all the computers that keep the business running, not just the computer where the boss reads email.  Currently I work as a technologist of broad scope, encompassing both IT and Infosec and pretty much everything in between. 

I was very fortunate to start my career in Quality Assurance at Broderbund Software, along with a small army of incredibly wonderful people – almost all of whom still stay in touch, decades later2.  One of those wonderful people was a lead technician, and she had a favorite quote: “Once QA, always QA.”  She was usually referring to people who used QA as a launching pad to other tech jobs – R&D, product management, IT, or such.  The context was usually “You will always think like you do in QA, no matter what job you take in life, hahaaa welcome to our brain damage” – but, as I’ve discussed with her recently, it goes somewhat beyond that.

QA people – the ones who really have the brain damage, I mean, not just the checkbox-compulsive metricmonkeys – have this weird kind of perversion in their blood, where they like to dance on the heads of systems and break them.  The idea is to make those systems stronger, of course, but chasing down the holes in the plan is where all the fun is.

(Sound familiar at all?)

Back then in QA, the first thing we’d usually do to a new product was to run it as it was intended once or twice.  This would give us a rough set of expectations as to how the program should run in general.

From there, we’d usually move into doing silly things – trying to click everywhere all at once, typing random characters3, trying to run as many instances of the program as possible, and basically just doing things that would make the poor computer shed silicon tears of bewildered frustration.  I’d say it’s a short hop from that mentality into Infosec, particularly pentesting – well, either that, or to a white jacket in a rubber room. 

Of course, I’m not saying that mentality’s limited to QA.  Anyone in Infosec – or even IT/Desktop Support – or anyone whose account has gotten compromised – has had enough times on the phishing merry-go-round at least to mouse over a URL before clicking on it.

(And you’re doing that too, right?)

What I am saying, though, is that those of us with more inquisitive backgrounds tend to think that way already. It’s a comfort as we pursue our professions, but that philosophy soon bleeds into everything else we do, especially things that don’t have anything to do with personal computing.

For example: I automatically look for video cameras wherever I am.  It’s not really about being paranoid, so much as reflexively wondering where I would place them if I were the head of security, and looking to see if there’s a camera where I would place one.  After all, I used to play small-stakes dominoes in my local bar, which had cameras covering every corner.4

Now, I certainly don’t care whether or not I am on camera, but I do want to know where the cameras are.  What does interest me is where the cameras are looking, and why.  More to my point, by thinking this way I’m not usually looking where my attention is being directed.  Sure, I’ll look once – but that’s about all, just as as QA testers we ran the program once “normally”, just to get an idea of what everyone else is intended to see.

Here’s a more digital example – about a year ago, I watched someone in our company exploit a pretty major vulnerability on an internal webpage that actually sent the employee’s ID through a CGI GET process. It was tempting to keep playing with the information we got as part of this hack, but part of being good at Infosec involves hewing to a certain level of trustworthiness, and making a good-faith effort to report vulnerabilities to the people who can actually fix them, before getting all Jack Sparrow with the digital loot we find5

How did he find the vulnerability? By reading the URL of the internal link he had to click on for one reason or another.  And I mean the complete URL, not just the first few characters that confirms that he’s going to a trusted site.  He noticed his employee ID in the URL, and basically said “Hm, I wonder what happens if I change a particular digit or two in this URL.”  And voila, he was able to verify whatever the company was asking – not just for him, but for anyone whose employee ID was similar to his.  Or he could have just found out the employee ID of anyone he wanted, given an automated script and probably a good few hours or so.6

See what magic awaits us just behind the spotlight?

That’s one of the byproducts of a QA background: we don’t just click on a link like a lemming, we might just read the damn thing first. Check to see that where it goes is where you intend. 

From there we (the QA tester, the Infosec, and me) start to branch out from just URLs, or even computers in general, and start to really look around us, almost unconsciously, and start thinking about what we see.  If we see a set of floodlights in a corner of the ceiling, we’ll probably ask ourselves what might live behind them. Is there a camera posted behind those lights? Or perhaps a small set of speakers?  After all, why waste such a perfectly lovely hiding place?

That thought process is really how I see the main connection between QA and Infosec, and – in this example – between coming from such careers and knowing where to look for the cameras, and wondering why those cameras are there.

Once QA, always QA.  The complexity of the systems and the tests may have changed dramatically over the last two decades, but the underlying philosophy really hasn’t.

And the more you look behind the curtain, the harder it gets to pretend that you haven’t.

[1] As opposed to “QnA”, meaning “Questions and Answers.”  A QA department usually has more of the former than of the latter.

[2] In fact, we just had a reunion party a few days ago, at the time of this writing. We’ve had one every few years or so, and it’s been almost fifteen years since that company got bought out.

[3]This was well before the relevance of a SQL injection – hell, it was before any Internet game that I know of besides Nethack.

[4] They knew that we were gambling for money of course; they just didn’t care. That wasn’t what the cameras were there for and that absolutely wasn’t what they were worried about.

[5] Of course he made a report right away.  And, surprise!  The report went ignored. Not even an automated rejection letter.

[6] I want to make it very clear: he did none of this.  His ethics are strong.  But he could have.
(And while I’m here, yes: he’d started his career in QA as well.)

LinkedIn: Last Name Conceal, Account-Based. Swing And A Miss.

Dear LinkedIn:

I somewhat like the idea that you block viewing last names of third-degree contacts. It makes company-mining slightly more difficult, and is a cute way to upsell your account upgrades.

Trouble is, no one seems to have told the “Viewers of this profile also viewed…” widget, which goes right on ahead and blasts out the full names of those that viewers of a profile have also viewed.

Not that I care, really.  In fact, as regards myself, I honestly couldn’t care less.  If I didn’t want people to see my full name and title, I wouldn’t have a public profile on LinkedIn. 

But, it does seem to defeat the purpose of blocking last names on the main page, when the widget – just a quick scroll down on the exact same page – totally undermines this effort. 

(PS: thanks for leaving that bug in; it really does make data mining easier ; )


[Note: I’d like to put in screen shots, and will if I ever get around to creating a blank LinkedIn account.]

BSides LV Memory x2


We’re having a little … discussion … over on the BSides group list, and Erin most appropriately started us off with the lovely memories.

Mostly so I don’t have to choke the thread with a 300K JPG, and also so it’s somewhere else, I post the picture here. 

For context, here’re two of my favorite BSides memories, in this case about LV #2:

– Track #2, the “game house”, was over capacity and overheated from the jump on day one.  Jack managed to miracle a 3-ton unit literally overnight. (I’ve pulled some huge honkin’ rabbits out of my ass before, but Jack wins the prize for this.  He must have been bleeding for months.)

– Track #2, end of day one.  As speaker wrangler, I noticed the last talk of the day in that overheated and under-oxygenated room was a panel, and (IIRC) my contact for that panel was Leigh Honeywell. I went to her and started to ask, “Since y’all are a panel, do you need A/V, or can we just leave the doors open for that hour?”

I got as far as “do you…” in that sentence, and Leigh finished that sentence for me with the words “… want to run it by the pool?”

I blinked for a few seconds, and said, “Give me 15 minutes.”  Went to Vyrus and Jack, and damn if within 15 minutes Vyrus hadn’t redirected all the necessary A/V to the poolside – in particular, the beach. Jack got the video camera set up on the walkway in about that time, and off we went.

That’s what I’m talkin’ ’bout.

But a picture’s worth 1000 words, as we know, so I’ll just STFU and leave you with this.