Full-spectrum security

Yesterday, I stopped into Carey My Keys on St. George Street to have some spares cut.  The front door was open to both the patrons and the weather, and the poor dude who was supposed to be staffing the counter was instead juggling two phone calls.  While waiting, I took a gander around the place.

Keys are no use without locks, of course, so the range of those on sale was impressive.  Ditto the safes.  And a few fancy-schmancy electronic devices. Also on display, though not actually for sale, were two dogs, both sprawled out in the warmth of the afternoon.  At least when no human attention was forthcoming.  (Because, naturally, any Office Dog worthy of the title must be a friend to the world.  It's in the union by-laws.)

I couldn't help but appreciate the full range of security options, of which dogs, of course, are by far the oldest.   I suppose even Office Cat #1, who growls and hides at the sound of a knock or the doorbell, technically qualifies as security--particularly whenever I'm wearing headphones.

In the purely physical world, each form of security acts as a filter against specific hacks.  Locks can be picked.  Someone with inside knowledge could find a way to disable a security alarm.   Dogs could theoretically be neutralised one way or another--possibly before sounding any form of alarm.  But all together, someone would have to be both determined and thorough about breaking into your house to do it successfully.  Particularly if you were home at the time.

Online, it should be much the same story, meaning an overlapping of different mechanisms to prevent someone from breaking in.  Sure, you can set up your web application to use Secure Sockets Layer (SSL) 100% of the time, not to mention require password lengths to be measured by the kilometer.  But that doesn't stop someone with a bot-net trying to crack it with sheer brute-force computing power.  Adding a captcha (those mangled combinations of letters/numbers you have to type) to the login form complicates matters for the bot-net, but in the end, it's just another iteration of the arms-race.  But locking out the account (even for a minute) really puts a crimp in a bot's style. 

Alas, that doesn't stop someone from setting up an identical-looking website and sending out emails that attempt to trick your users into signing in (a.k.a "phishing").  (And, by the bye, nothing in the above scenario covers direct attacks on your I/T infrastructure.  That's a whole 'nuther job, and I'll get to that in a minute.)

As in real life, nothing's ever 100% secure.  That being said, the fact that there is no proverbial silver bullet is no excuse for not loading the entire clip.

As a programmer, a ridiculous percentage of the code I write exists to lock out the baddies.  A sample (but by no means complete) list of tactics:

• Verifying all input sent by the browser to the server, and back and forth between the server and the database.
• Scrubbing potentially malicious characters out of text entered by the user (e.g. attempted SQL injection or JavaScript injection attacks).
• Encrypting important data (e.g. passwords and email addresses)  so that even if the database were compromised, those would be useless to the thief.
• Preventing specific error messages from the server (and, most especially the database) from being displayed back to the web browser.
• Encapsulating code data access functionality in database functions, which adds another level of validation/protection.
• When appropriate, using industry-standard frameworks.

It's mechanical, repetitive work and boring and time-consuming as all get-out.  But it wouldn't mean bupkis if the person wearing the Sys. Admin. hat (which sometimes is me) drops the ball on things such as:

• Not keeping the system patched with security updates.
• Not shutting off unnecessary processes--particularly those which can reach (or be reached from) outside the network.
• Not limiting the channels (a.k.a. ports) on which traffic can flow to and from the server.
• Not using strong passwords.
• Not locking down resources (e.g. files and databases) to restrict which users can access them...and limit those to the bare minimum.
• Not using/enforcing SSL certificates (or using self-signed ones).
• Not having intrusion detection in place, or having no mechanism to defend against denial-of-service attacks.

Again, that's just a taste.  Does it add to the cost of a project?  Most certainly.  But it's nothing compared to what a hack will cost in terms of lost customer goodwill.  And that's even without lawsuits being filed.  And if that breach runs afoul of privacy laws/regulations...Ouch.

In practical terms, anyone thinking of paying programmers to develop a custom application should make security part of the initial discussion*.  It's not an after-market feature that you bolt on right before it goes out the door.

More importantly, it's not a feature that one single person should be responsible for.  Even when that one single person wears many hats (as I do).  

- - - - - 

* Pro tip:  Talk to your favourite geek ahead of time to develop a few intelligent questions about security alongside other pertinent issues like scalability.  Informed questions are an inoculant against being taken lightly.

Story:  Before I knew anything about cars, I used to call a friend who fixed them for a living.  Then I could walk into the shop and parrot something like, "My gut feeling is that there's a flat spot in the starter, but you might want to take a look at the solenoid, too," and have a reasonably good chance of not being fleeced.  Trust me, this is a totally legit. way to approach negotiating with anyone who's a domain expert where you're not.  Eventually, though, I found a mechanic I could trust.  Which was just as well, because I learned a lot of things about cars--or at least 1983 Toyota Tercels--as its innards were replaced during the remainder of its 16-year lifespan.

Excuses, excuses...

This is the reason my Gentle Reader is not seeing a "real" blog post tonight:

The chipset is the 8266 and, when soldered into a small printed circuit board with an embedded antenna (the gold square wave thingy that mostly goes across the top), it's basically a wifi-enabled breakout board.

The big deal is that it has GPIO pins.  Now, most of them are already spoken-for (input current, ground, reset, serial input/output -- that sort of thing).  But at least a couple of them are not.  That allows them to communicate with other devices or widgets, most notably (for me, anyway) my latest obsession, the Arduino.

The bigger deal is that, relative to other options for granting wifi superpowers to a primative microcontroller (again, the Arduino), this is fairly inexpensive.  $11-$12 Canadian is at the high end.  (I'm sure eBay/Amazon can do better, but I prefer to support vendors who support the community.  And provide datasheets.)  Normally, this functionality would be at least as expensive as the full-size Arduinos, and require a specific model besides.

The biggest deal is that it seems to have gained a lot of interest--and, more importantly, community in a relatively short time.  In practical terms, that means that people have donated their time to translate/interpolate the documentation from Chinese.  And make it easier to program the chip.  That says boatloads.

So my job for the next couple of evenings is to figure out how to make that itty-bitty chip connect to our wi-fi router and play nicely with other microcontrollers.  Because if the ESP8266 family turns out to be all-that-and-a-bag-of-chips...holy moly, does that ever open up the possibilities...

Scratching at scale, Part II

So there's an itch.  And it turns out that the most effective way to scratch it is with a computer of some sort, typically a desktop, laptop, tablet, or smart phone.

One of the dirty secrets of software development is that, even in relatively small organisations, the sheer number of users tends to stretch the usage of the software in directions that might not have been anticipated on the whiteboard.

The person (or people) with the initial itch face something of a paradox when designing a software product meant for mass-use.  And that paradox boils down to two contradictory mandates when bringing the product into the real world:

• Commandment 1:  Know Thy Itch.
• Commandment 2:  It's Not About Thou.

Confusing, right?  Actually, it doesn't have to be.  Because really, these commandments are two sides of the same proverbial coin.  Allow me to explain.

In the earliest phases of product design, everyone--and I mean everyone--involved absolutely must understand the itch.  Top to bottom.  Backward and forward.  Inside and out.  No excuses.  Why?  Because misunderstandings make for bad assumptions.  And bad assumptions solve the wrong problems (at best) or non-existant problems (at worst).  And in either case, waste time and money.

In practical terms, that means that the everyone, including the designers and coders, need to be allowed to experience, first-hand, the pain-points.  Even if it's in a shadowing capacity.   Even if they don't actually work at the organisation.  Actually, make that especially if they don't actually work at the organisation.  Mainly because there's no substitute for first-hand experience.  But also because the outside perspective can see past the politics to strip the personalities away from the actual problem to get to its essence.

After that point, it should merely be a matter of implementation, right?  Not so fast.

Software development is expensive--let's not pretend otherwise.  It's expensive in terms of the time the organisation spends on the development process as well as the quoted budget.  Thus, the temptation is always there to leverage that investment by making it available for others.  Those "others" could be different parts of the organisation.  Or they could be working for companies in the same (or a similar) industry.  I've seen it happen both ways.

That's the point where Commandment #2 kicks in.  Maybe the software will do 95% of what these other folks need--but the catch is that the missing 5% is mission-critical.  At that point, the original group has to decide whether or not to add that functionality and, if so, how to fund the additional work. 

Even when the monetary cost is shifted to those requesting the changes, there's also a loss involved--namely a slight loss of control over the product.  It's not logical, but this can be more painful for some than writing the cheque.  But it's understandable--all the work that the original team put into researching, brainstorming, evaluating, testing, training, etc. is something to be proud of.  Particularly when the product is useful enough that others are interested in it.  But now these unappreciative barbarians want to change it!

Again, the reaction is perfectly understandable.  Unshockingly, it even happens to your faithful blogger from time to time.  But that reaction is also the warning that you've strayed away from Pride and wandered into Ego.  See, the process of initially scratching the itch requires checking egos at the door.  In practical terms that meant things like...

• Not taking "That's how we've always done it." for an answer.
• Not allowing office politics to shape the design.  
• Not using information to play favourites.  
• Not pawning off responsibility on those who have no authority.  
• Not postponing tough decisions.

It's time to repeat the process.  Good news!  Everyone involved in the original software development cycle already has practice with this.  Better yet, they probably even internalised the basics of the itch.  All of which can be applied to the new-and-improved-and-ready-for-prime-time edition.

So, in the end, Commandments One and Two really aren't contradictory.  They're both about zeroing in on the pain-points, and making the pain go away.  The shortest route to that more often than not cuts through personality and power-dynamics and especially egos.  Compared to that, the challenges posed by technology should be a breeze, right?

Scratching at scale, Part I

All software starts with an itch.  Sometimes that itch is practical:  "How can I easily manipulate business data as rows and columns?"  Enter Lotus 1-2-3.  Other times, not so much:  "How can I meet and hang out with other Harvard students without actually having to leave my dorm room?"  Enter Facebook.

But when folks approach me to develop software for them, the practical-vs.-frivolous distinction isn't the one that matters.  Instead, the real question boils down to whether or not the software should be built for scalability.

In I/T terms, "scale" largely translates into, "How many users does this software have to support?"  The answer to that question drives decisions such as hardware and even language/platform.  But it also drives decisions at a more fundamental level than that--and not only on the I/T side of the team.

Software usage is kind of like a democracy--people can vote.  Sometimes votes come in the form of dollars.  But even with "free" software, people vote with their feet.  That also applies to software that's mandatory--for instance, time-sheet/expense apps. at the office.  And, just like political democracies, more users translate into various "tribes" pushing and pulling at how the software is ultimately used.  True, its use can be nominally mandatory.  But if it's poorly designed (or incomplete), it will be avoided, circumvented, hacked, abused, or misused whenever possible.  Anyone looking to it to provide an accurate insight into what's going on is screwed.  (Because we all know that false metrics are worse than no metrics, riiiiiiight???)

For someone with an itch looking to build a new (or just improved) back-scratcher, it's critical to understand that the features-to-user ratio does not stay constant as the number of users rises.  There will be inflection-points along the way, and they invariably tick upward.  To wit:

1. A revolutionary back-scratcher, The ItchEraser3000, is invented.
2. A few dozen are sent to the reigning "lifestyle" taste-makers.  A handful of reviews are written, largely glowing.
3. A surge of orders triggers a mad scramble to ship a few thousand out the door before the buzz dies down.
4. Uh-oh, several are returned for the money-back guarantee because the ItchEraser3000 was designed and tested exclusively by right-handers.
5. Thanks to small manufacturing runs and the miracle of computer-aided design, a version optimised for the left-handed is made available.
6. Targeted marketing (and cultivating some of the dissatisfied clientele) lands a mention on the SouthpawsUnited Facebook group.  
7. A scramble to find a manufacturer capable of larger batches ensues as the virtuous cycle of word-of-mouth grows sales, but life is generally good.
8. The cash-flow hit from the January sales slump is exacerbated as users with upper body mobility issues return the IE3000s purchased for them by family members.
9. The hit-and-miss process of developing an ergonomic version of both the left- and right-handed ItchEraser is costly, with no word-of-mouth payoff except kudos from one or two advocacy groups.
10. The ergonomic models have slow and fitful sales, resulting in a net loss.

Software product development is no different, really.   There's the Big Idea, which never really escapes its brushes with capital-R Reality unmodified...assuming, of course, that it survives at all.  All because rarely do two demographics itch in exactly the same place.

A veteran software developer will recognise this pattern, and help her/his clients understand the implications--at least from the standpoints of system complexity and maintainability--as each new demographic appears.  

Ultimately, though, it's up to the client to understand (even if they might not actually anticipate) the afore-mentioned "inflection points," in the adoption curve, and the risks/rewards of pursuing them.  Unless the software being developed is extremely narrow in focus (and its user-base is small), dealing with those inflections requires a bit of mental gymnastics.   That's another blog post for another time.  Barring unforeseen complications, that time will be Wednesday.

Frivolous Friday, 2015.05.15: Acadian spring

During these last four springs spent the Maritimes, I've noticed some harbingers of the season that are different from those I knew "back in The Old Country." 

It's not that I don't appreciate green grass and dandelions and being able to hang out the laundry and hearing the chatter of birds (that aren't crows or gulls or  pheasants).  Oh, no--they're every bit as relished as they ever were.

• Fiddlehead ferns in the produce department at the grocery store
• The local lobster fleet heading out of port
• Klatches of pheasants no longer hanging around our front door
• Clam-shacks opening for business
• The almost impossible blue of the ocean on sunny days
• News that multi-kilometer-long chunks of ice are no longer threatening to dam up the rivers
• The lack of reports about ferry routes or the Confederation Bridge being closed off
• The DNR fretting--and rightly so--about anglers catching the wrong (i.e. farmed) kind of salmon in the rivers

Mind you, the up-tick of traffic in an already-bottlenecked Shediac downtown is not at all welcome during my grocery run.  That's when I have to remind myself that maybe it wouldn't be there at all if not for the shot in the fiscal arm that is tourist season.  All the same, I don't envy a town whose population jumps from 5K to 30K in the course of a few weeks.

And I don't care for the way the stretch of Highway 530 in front of the old boulangerie (bakery) turns into a "kidneys are overrated" washboard, I suppose.  (Yes, I remember frost-heaving in the roads back in WI, but it turns out there's an appreciable difference between sand and clay.)

I'm told that spring returns to l'Acadie later than in my stomping grounds of the Upper Midwest.  True, we're compensated somewhat in the form of a cooler summer and later autumn.  Alas, it still makes for a lot of impatience on my part--even without snow in the waning days of April. But, happily, it seems that Grande-Digue may even be ready to greet its guests and part-time denizens by Memorial Day. 

"Brungee Cord"

Just a random thought in the wake of tonight's annual meeting of the Shediac Chamber of Commerce.  (And, truth be told, after dipping yet again into The Lord of the Rings over the weekend.)

Seeing as I still barely know anyone, my preferred tactic--barring random collisions--is to scan the room for someone who looks as out of place as I feel and try to strike up a conversation with her/him/them.  Of course, that's not how one expects to meet the proverbial movers and shakers.  (Because those folks are already part of a crowd or systematically working the room.)  But it does lead into interesting territory.

Alas, it involves having to tell a bit of my story, and with that the (almost) inevitable cringe at people being surprised that, with all of Canada to choose from, Dennis & I staked our tent in New Brunswick.

I say "almost" because there's one demographic that never asks me that question.  And it's a healthier demographic than one might expect.  It's comprised of the folks who grew up in N.B. (or the Maritimes), left for "the west" (which, to the uninitiated, almost always seems to translate to the Alberta oilfields, British Columbia, or possibly Toronto), but then returned to raise their children.  It's like New Brunswick attaches its own special bungee cord--or "brungee cord," if you will--to many of its children.

If there's any surprise to be had, I would think it would be the brungees rather than we arrivistes who should trigger any sort of head-scratching.  After all, for all our neighbours know, we threw darts at a map...although a quick peep (followed by a morbid laugh) at the Toronto and Vancouver housing markets should tell anyone curious everything s/he needs to know. 

Yet, while "How Ya Gonna Keep 'em Down on the Farm after They've Seen BC?" doesn't quite have the same ring as the original version, the basic idea isn't all so threadbare, even after nearly a century.

Some Hobbits (e.g. Sam, Merry, and Pippin) find that their adventures among "The Big People" (not to mention Elves and Dwarves and Orcs and more far-fetched creatures besides) ultimately make them see The Shire again with fully-opened eyes.  Others--like Dennis and your faithful blogger--find that sometimes that the path never circles back.  And, like Bilbo and Frodo, we are pleasantly amazed to find more welcome than we have any right to expect among people with different customs and history and even language(s).

Either way, New Brunswickers, could you pretty-please stop being surprised?  Because in doing so, you're underrating your home--and by extension yourselves.  Yeah, yeah, yeah--I totally get the whole self-deprecation schtick.  I mean, I come from a long, loooooong line of Minnesotans and Iowans, fer cryin' in yer Molson's.  Self-deprecation was hard-coded into my DNA several generations before I was born:  If you cut me, I'll bleed humility (along with coffee, tater-tot hot-dish, and Jell-O salad).  Nonetheless, could'ya do both the immigrants and the "brungees" a solid and validate our choice of postal code, m'kay?  Merci d'avance.

Hats and headspace

The mobile-friendly application that I hope to be dog-fooding by the end of the summer has three main components:

1. The bits that you actually see and tap and swipe on the phone itself
2. The database that not only contains all the data, but also does a lot of the heavy lifting, logic- and security-wise
3. A relatively lightweight web interface that more or less acts as a traffic cop for bytes flowing between the mobile phone and the database

It's no secret that I'm more comfortable working in parts #2 and #3.   Normally, what we coding primates call "front-end development" I try to do with people who are blessed with an eye for layout, aesthetics, an appreciation of minimalism, and a blissful ignorance of what goes on behind the curtain.

(Normally, I don't champion ignorance...unless it's of the cultural graffiti that each celebrity leaves in their fifteen minutes.  But in software development, it can actually be an asset.  Whenever possible, I try to give myself a few days' distance from code before I demo. it to a client or user.   That's time enough to start to forget about the intricacies of what's going on under the proverbial hood.  It's like taking a car out for a test spin, really--anyone but a mechanic should rightly give more attention to the steering wheel than the spark plugs.)

This time, however, I don't have the luxury of a front-end developer.  Partly because I'm trying to do Version 1 on a tight budget.  But also because I'm using this project as an excuse to learn the Cordova platform.  (Aside to non-developers:  If you don't know what Cordova is, don't worry about it.)  The shiny new platform aside, my natural inclination would be to leave front-end until last.  It's simply not my strength, after all. 

But the problem with doing the "middleware"--the web API ("Application Programming Interface")--next is that, of the three layers, it's the least in touch with reality.  The database has to be done first:  It defines the shape of the information--what's related to what else and how.  That's real.  Equally real are the buttons and text and fields that allow the user to control their data and how it's presented/manipulated.

The web interface?  Not so real.  I mean, yes, it still does important things like making sure that each user is properly logged in before s/he is allowed to look at, much less touch any data.  And while the database contains the bulk of the machinery required to read, update, and delete data, something has to pull the levers and flip the switches.  Also, however much sanity-checking and error-handling is done w/in the database, it would be downright irresponsible not to build any filtering into the API as the proverbial first line of defence.

In normal operation, the front end logic and the back-end logic would evolve in tandem and symbiosis.  But I've found that having to wear all three hats does something different to the head beneath them--at least in this instance.  I think I already have a healthy respect for the user interface folks; doubtless this foray outside my comfort zone will only increase that.  More to the point, I'm hoping for an even bigger bump in empathy for that forgetful, easily distracted creature of habit typically known as "the user."

"The 'vision' thing"*

Have I ever mentioned that I hate painting?  Yet last year I decided that I simply could not face another winter of staring at white walls.  So I made lemonade from the lemon of a downswing in work.  And while I'm still ambivalent about the "Shamrock Shake" green of the bathroom, everything else has (so far) lived up to expectations.

Podcasts are good for improving the time spent inching a brush along trim and drywall.  Sometimes, too, it's good just to unplug and go on walkabout through one's own head. Ultimately, though, there's only so much edge that can be taken off the tedium for days on end. 

That's where the big picture--the "vision" thing--has to step up. 

Running back a dozen years in memory, it recalls the crunch of getting one-point-oh of a bet-the-branch-office web application out the door.  The boss--a born schmoozer and salesman if ever there was--turned his considerable talents on us, "selling" us on what a successful project meant to us.

A per-transaction business model, according to him, meant that eventually we could scale to the point where we might occasionally stroll into the office to work...if only as a break from spending all that money we'd be making.

It was horse-hockey, and we all knew it.  We knew darned well how profit-sharing worked in the context of the larger firm.  We knew that the CAD folks would still have to produce drawings to make the app.'s floor plan component work.  We knew that the boss (a huge admirer of Steve Jobs) would never, ever run out of ideas for the programmers to implement.  Besides, someone had to bring in new clients for someone else to set up and baby-sit.  And, for pete's sake, we were slogging through the tail end of the dot-com bust recession: That whole instant millionaire thing was soooo 1999, don'cha'know?

In short, we didn't for a minute buy into the notion that we were creating the business equivalent of a perpetual motion machine.  Jokes about how we would spend all that money (e.g. cappuccino bars in every cubicle) were common currency.

In 2015, that web application is still chugging along, albeit downgraded from "flagship app." to merely the nucleus of a more comprehensive (re-branded) product.   Of course, the "vision" never panned out.  There were layoffs and re-orgs and fire-drills and over-orchestrated "innovation" initiatives and nearly every other productivity-nuking trick management has its arsenal.

Yet there's a reason Mark Knopfler's (slightly NSFW) Stand Up Guy is indelibly linked in my mind with the boss.  He's good at what he does.   The vision of coming into work just because you feel like it is undeniably seductive.   It covers both the extrinsic motivation of having great wads of cash (and vacation time) to burn, plus the intrinsic motivation of offering a venue for the mastery of one's craft.   

Similarly, the motivation for all that futzy painting (tri-colour in the case of the living room) had nothing to do with aspirations to interior decoration and everything to do with how it would feel to wrap my line of sight in colour while white and gray warred for dominance outdoors.  Even burrowed under a slanket, warmed only by the laptop fan and the sandbag-like weight of a sleeping cat, it was worth it.

- - - - -

* The second-most infamous sound-byte from George H.W. Bush (after "Read my lips").  The 1988 U.S. Presidential election (a.k.a. "The shrimp, the codger, the wimp, and the dodger" was not exactly a banner season in politics.)