security

My Bibifi Adventure

I’ve been involved in a learning experiment these past six weeks. Now that it’s winding down, I thought I’d reflect a bit on some themes that emerged.

For the past 9 months or so, I’ve been taking classes online from Coursera to complete a Cybersecurity specialization taught by the University of Maryland. I’ve learned about security and usability, various flavors of software vulnerability, secure integrated circuit design, digital watermarks, and encryption theory.

In early May I began the final class in the sequence–a capstone project where teams of students attempt to build secure software to match a spec, then try to break one another’s submissions with a combination of pen testing, static code analysis, fuzzers, and theory taught in our other security courses. The project is framed as an international coding/testing competition hosted on builditbreakit.org (hence the “bibifi” in the title of this post), and this May’s running of the contest includes several hundred very sharp participants from around the world.

Bibifi Scoreboard

Partial bibifi scoreboard, showing 5 of about 100 teams. I was on team “SEADA”. Net of score in buildit round minus bugs logged against code in breakit round shows current overall standings.

Continue reading →

A grumble about buckets

Sometimes developers limit the choices that are offered to their users as a way to simplify. This can be a good thing; I’m a big fan of simplicity.

However, this strategy comes with an important caveat:

If you’re going to force all choices into a few predefined buckets, you better provide buckets that match the needs of your users.

Broken buckets will not earn you brownie points. Or revenue.

image credit: Eva the Weaver (Flickr)

Today I was adjusting my 401k contribution. Here’s the broken buckets I saw when I logged in to the financial services website:

Continue reading →

Lacunas Everywhere

I’m told that in Czech, the word “prozvonit” means “to call a mobile phone and let it ring once so that the other person will call back, saving the first caller money.”

Image credit: AstridWestvang (Flickr)

How would you translate this word to someone in New Guinea who has never experienced electricity, let alone a telephone or a bill from Verizon? You wouldn’t. This is an example of a “lacuna“–a translation problem caused by semantic gaps in a target language. Lacunas occur in programming languages. You might know a few; maybe you wish C++ had python-style generators–or that Java had Haskell’s notion of pure functions–or that C supported PHP-style string interpolation. But what if I told you that semantic misalignment between any pair of programming languages is just minor details? What if I claimed that all programming languages I’ve used have numerous, pernicious, and expensive semantic gaps? That we don’t see these gaps for the same reasons that a stone-age hunter-gatherer fails to notice his inability to discuss patterns of cell phone usage? Would you think I’m crazy? Continue reading →

Why Your Software Should Cry

The problem of pain has bothered philosophers–particularly those with a religious bent–for a long time. What might be the purpose of suffering, they’ve wondered, and how does it relate to the human experience?

But pain barely impinges on the thinking of software engineers at all. Computers never wince, or complain, or mourn the loss of a favorite program (Marvin the paranoid android excepted). An OS runs at full speed until the instant when its kernel “panics” without warning; once you reboot, it acts as if nothing ever happened. No sniffles, no whimpers, no scabs…

photo credit: nanny snowflake (Flickr)

This is unfortunate.

Reaction to stimuli is one of the 8 characteristics of life. That means that living things are aware, in some sense, of their relationship to the larger environment. They distinguish between good and bad stimuli. They hurt. And they learn from their pain.

Lessons from a protist

This ability to use pain is not limited to complex organisms. The lowly Stentor roeselii (a single-celled protozoan that anchors for filter feeding) exhibits an incredible repertoire of behaviors to optimize its relationship with the environment. Squirt it with water from a pipette, and it contracts for defense. 30 seconds later, it unfurls again. Keep squirting, and it eventually learns to ignore the false alarms.

Gently introduce a poison into the water current, Continue reading →

On SEPs, Squirrels, and Meta Questions

In Douglas Adams‘ novel, Life, the Universe, and Everything, a spaceship lands in the middle of a stadium of screaming fans during a cricket match, and nobody notices. The ship doesn’t use a Klingon-style cloaking device to accomplish this amazing feat; instead, it is hidden by a “Somebody Else’s Problem” field, which operates on the principle that if something is perceived to be somebody else’s problem, the brain of onlookers will treat it as if it were invisible.

Adams was a sci-fi author, but I see applications of his metaphor in the day-to-day work of software engineering.

To one degree or another, we all exhibit inattentional blindness from time to time. And that can be a good thing. Being able to zero in on a particular block of code, to the exclusion of the guy sneezing or yawning in the next cube, is healthy. We don’t want to be like the dogs in Pixar’s Up!, who keep getting distracted by squirrels.

However, truly superb engineers have a capacity to see through the cloak of somebody else’s problem; they think simultaneously on multiple levels of abstraction. They tend to ask “meta questions” (judiciously) that poke at larger issues, broader contexts, or more distant time horizons. Not coincidentally,  Continue reading →