Contemplation of circuits and society
I was recently privileged with an opportunity to troubleshoot a system outside my computer lab; my car. What follows is a little walk through on how I fixed the issue as well as some philosophical musing that occurred to me while working it.
Full disclosure, I'm no shade-tree mechanic. I can put gas in the tank, change my oil and filter once in a while, but beyond that I tend to leave the car to professionals. This particular issue however combined with the state of the world prompted me to do a little more digging myself before taking it somewhere.
The Problem
When I came home after running some errands, I found my brake lights remained on after I turned off the engine. Thinking a switch was stuck somewhere, I proceeded to restart the car, hit the brake a few times, toggled through the light settings, turned off the car, and rechecked. No change. I think disconnected the battery under the hood, let it sit a while, then reconnected. The lights came back on as before.
The Theory
I texted a buddy who is a mechanic to see what they thought, laying out the particulars as clearly as I could. They validated my thoughts that a switch had most likely gone bad. Apparently with cars, particularly with brake lights, the circuits are often designed to fail closed (meaning the circuit stays in a connected state), thereby allowing the light to stay on when the circuit fails. This was counter intuitive to me initially given my experience with how often computers are programmed to fail closed (meaning breaking the connection) in cases where something fails. Expired cert? Most browsers won't even take you to the page anymore. Network loss? You're getting nowhere fast. Locked account? Foiled again!
Brake lights are different story though. They're one of the many life-saving systems that must continue working through anything short of a full system halt, like the battery dying or the engine being turned off. If the electrical switch fails, they can often stick closed (again, closed being a contiguous circuit).
The Cause
In my case, the failure happened to be that the brake actuator bumper had disintegrated. While not the switch exactly, it's purpose is depressing the brake light button attached to the switch. I found it in pieces after I pulled off the fuse box cover under the steering wheel.
Here's a picture of the shattered actuator bumper
All this piece does is fit in a hole on the brake pedal arm. It depresses the brake light switch button when at rest, opening the circuit and turning off the lamp, much like a dead-man switch. When you press the pedal, the switch button is release as the bumper is pushed away, closing the circuit and lighting the brake lamp at the rear of the vehicle. When my bumper disintegrated however, there was nothing to depress the brake light switch and the circuit remained contiguous.
The Fix
After some trial and error I fabricated a suitable replacement which will hopefully last the duration of the vehicle. Below describes some of that process with pictures to save a few thousand words.
Here I'm cutting down my spacer I'll use to replace the bumper. Was I a good engineer and used a caliper for the measurements? No...I was not. There was a lot of Kentucky windage with this build. (bonus points if you know what Kentucky windage is!)
Here is the full assembly, complete with an oblong 'washer' to fix it in place which I scrapped from the inside of a locking mechanism I had laying around. And before you ask, yes, I blurred my fingerprints in this photo for those of you involved in OSINT forensics. You're welcome!
Installation time!
Kick the tires and light the fires! I was almost as proud of my makeshift brake-stomper as I was the repair itself. Aren't pullies great?
The Contemplation
While I was putting all this together in my garage, I thought a lot about what safety and security means across different industries.
In my world, things are usually configured to fail closed so that the enemy (or unwitting user) is unceremoniously cutoff from whatever it was they were trying to do. Examples include certain DDoS counter measures. When your system comes under attack, your DNS records can begin redirecting the flood to a sinkhole until the bad packets stop flying. Sure, you might have some business loss or unhappy customers, but at least you're systems won't be molten puddles of metal and silica. Additionally, without the DDoS noise, maybe you even managed to catch the secondary attack flying in under the burning firewalls.
In other industries though, locking systems down when they come under attack is unthinkable. My car example is one; a system failure resulted in something staying on instead of turning off so I would be safe(r) for as long as the battery lasted. But how does this look outside my garage? What are these other differences I'm driving at?
In Business, for example, security is an inwardly focused objective, protecting the customer or product information at all costs by minimizing attack surfaces from the outside and mitigating risks inside. This tight and often paranoid perspective dominates much of Finance, Legal, and other information based industries. They are, in a word, keepers. Keepers of money. Keepers of secrets. This is their solumn duty.
In the Medical industry, however, safety and security is largely outward concept, caring for the health of the community as whole at the risk of medical staff. Religious organizations and First Responders would be other examples, along with most Critical Infrastructure services. In these realms, the successful delivery of a service is the safety and security sociaty needs. These are the givers, exposing themselves to high risk situations for the good of others.
Neither of these camps is right or wrong in their view of security. They're just different. For all their differences though, one thing they have in common is technology. This commonality is where somebody like me gets to help, literally bridging gaps between worlds and minds with a bit of wire and AES256 encryption standards.