Wednesday, September 25, 2013

Social Change and Hyperbole

150 years ago, our President would have been owned by someone. 100 years ago, our First Lady couldn't vote. And 60 years ago, they would have had to ride in the back of the bus together. Today, they lead our country. Social change happens, and it's slow and hard. Mere decades before each of these events, these outcomes were unthinkable, frightening. And here we are today. Let us not think that other major social change would, as some say, "ruin the foundations of our country" or similar. To make such statements is clear hyperbole: ridiculous, not applicable and desperate.

It is our right to disagree, and to have our own opinions. It is good that we have disagreement: it drives change and improvement while keeping checks and balances in place. However, we are a democracy and we need to let the majority speak and then respect that outcome. Sometimes you get your way, sometimes you don't. If you don't like it, go be the dictator of a small country and see how well that works out for you. Or start small as the overbearing head of a household and see just how happy others under your roof are.**

** - Don't be the overbearing head of a household. Or small country.

Monday, September 23, 2013

Hacking a phone

Phones are rapidly moving to the forefront of our electronic connectedness (or really, they are already there), as opposed to being a sort of auxiliary device that can also do some things. The super-fast hacking of the iPhone's fingerprint scanner security feature got me thinking about some of the assumptions we make.

First, more ways to log in, perhaps unintuitively, makes a platform less secure. This is exactly analogous to having multiple doors into your house, all with different types of locks. A thief only has to figure out how to exploit one of those, and they are in.  The key here is that any one door gives full access, as opposed to multi-factor authentications (ex: voice+fingerprint+passcode) where the thief has to go through ALL of the doors to get in. But really, let's assume a good thief can break through any of these doors and therefore we have to have a backup plan.

A technique to help users mitigate the loss/hacking of their phone is remote-wipe. Since we're talking about Apple, we'll keep using them as the example (though the concept should apply equally for any phone maker). I was debating if a thief could do something like:
1. Steal phone, turn it off
2. Turn on the phone in their underground lair where there's no cell signal
3. Take as much time as they want to hack the fingerprint reader using a print left on the phone by the original owner (** - what are the odds, actually?)
4. Connect to a firewalled internal network that blocks attempts to communicate with Apple's services (and therefore presumably could avoid the remote-wipe instruction)
5. Go party with data on the phone (email, pics, texts, ...), syncable by the phone (email, ... ), pushable by the phone (bank account app, perhaps ... ).

Turns out the iPhone can be put into airplane mode in iOS7 without even unlocking the phone, so steps 1 and 2 converge to "put phone into airplane mode". In this particular vein, the fingerprint is only valid for 48 hours after the last successful login (seems a pretty long time ... ), so the thief would have 2 days to replicate the fingerprint. At any rate, the remote-wipe may be easier to block than desired. At that point a user would have to resort to changing all their passwords, but that still leaves a thief access to anything cached on the phone (which would be quite a bit of personal data ... ). Hmm. Perhaps security features should be left as simple as possible?


** - I don't know how clear a print needs to be for a thief to be able to reproduce it. Just looking at my phone, I think there was one "good enough" one after I pulled it out of my pocket. For the scanner feature to be useful, it seems like a user would have to use their thumb, which is also a finger they are most guaranteed to place all over the rest of the body/screen as well.

Friday, September 6, 2013

Cracking the code

In this case, the NSA cracking various encryptions ...
Let's assume the media has the details right (which can be a pretty big if) and take a looksey.

"U.S. and British intelligence agencies have cracked the encryption designed to provide online privacy and security, documents leaked by former intelligence analyst Edward Snowden show." - USA Today.

They then go on to say that they actually mean individual keys. This is very different. There's no question that given enough effort, the NSA could reverse engineer a private key. Really, lots of people could ('people' here means those with access to serious computing power, though I wonder if you could successfully run cracking codes on Azure, EC2, etc?)

The article goes on to say that the NSA has maintained control over international encryption standards. I don't think that's actually true, that's NIST's job (and it's not 'control'). The NSA weighs in on the quality of new algorithms, etc, but they don't set the "rules" ... after all, people can use whatever they want. So we already have some bad info.

So far the NSA has done nothing that anyone else isn't trying to do. Then there are the allegations of back doors (either by hacking or pressure). Hacked back doors are, well, possible by anyone. China hacks stuff all the time. So does the USA. Nothing novel going on here.

The only allegation that's interesting is the possibility that backdoors are being added as a result of pressure from government agencies. This I like a lot less .... for obvious reasons.

Delicious places to eat in Tucson

Beyond Bread
BisonWitches
Rosa's
No Anchovies
Magpie's

Well, these are all very college-y (in that they all cost under $10). I have no idea about fine dining because it's really not my thing (even now that I make lots of money).

School is real life

I spent a big part of this week doing recruiting-related stuff around UofA. It was a really great experience to (re)connect with professors, see what's going on, and get a different perspective on the department and job hunt process. I've talked about some of the good and bad versions of applicants before, so I'll skip that here. Instead I'll focus on the realities that I basically refused when I was a student in their shoes.

I heard in multiple classes that difficult group members happen, that projects require testing, that I probably suck at writing. I didn't believe any of it. However, all these things translate directly. Let's take a look, one by one.

You can't write:
I never ever believed this one until I started working at IBM and one day read a bug report:
"when I put the RDP in, it flashes then gets stuck" it read. What? Huh? There's like 100 versions of this. I wandered over to check it out, and on the way over grumbled about how this person is not considering that I have no idea what they are looking at. And then I realized that I was guilty of the same. This was a mini epiphany, and I suddenly got much much much better at writing effectively. And yes, most people suck at this. It takes practice. Not only do you want to be effective, but also concise. There's a big difference between a colloquial ramble like this and a well-composed, tight piece of prose. Opt for the latter in formal situations.

Sloppy testing:
As devs we want to believe that our code will always be perfect. Tests prove this. Unit testing is growing in popularity. I don't believe it's the be-all-end-all, but it's certainly a good way to help organize. If you're having a hard time creating unit tests, you probably don't have good units. Having good units leads to clean code with clear boundaries. These have clear roles with clear expected behaviors. It's just good policy.

But my teammate dropped the ball, give me a break!
Yeah, this happens. And guess what? You're at fault too. But you can't be expected to make them do their work, right? Well, true, sorta. The key here is to develop the ability to manage a project. Establish the pieces you need. Figure out the dependencies. Make sure the deep dependencies get taken care of first. Look at the pipeline here. If a piece is critical, make sure it gets done. If your assigned person isn't delivering, prod them, take over, whatever, make it happen. Understand the downstream effects of any particular piece slipping. Clearly N-1 people can do less than N, but you can mitigate the damage of the missing person by making sure that critical pieces roll off them. You may still not love the outcome, but you should be able to avoid getting burned.

Awesome possum. Go rock'em.


Monday, September 2, 2013

Another fucking Chevy

This trip's rental car is the bare-bones Chevy Cruze. While it solves many of the shortcomings of the Chevy Equinox, there are different random issues instead. Let's explore!

For starters, the car is just as impotent in the acceleration department (barring stomping the gas and doing the whole hunting for a gear, etc, thing), its 138 peak hp engine not exactly getting all its power down to the wheels easily. This is again due to the crappy tranny configuration. Why is this so hard to adjust and make not suck?? Is Chevy still putting trannies from the 60s in their cars?

The B pillar is absolutely right smack dab in the middle of my vision when looking left. I can barely see oncoming traffic during a right turn, and I can't peek behind (at my 7-8 o'clock) while making the turn. All I see is a metal bar.

The A/C controls are goofy. There are two knobs, one for the temp and another for the fan speed. In the middle of each of those are buttons for the heated seats. Separately elsewhere is the button for turning on the actual A/C. Reaching the fan control requires snaking around the shifter doodad (whatever you call that in an automatic). Despite all these buttons, the car doesn't remember what volume the radio was set to and always starts off at the same very low volume when turned on.

The seats are terrible. The lumbar protrudes like one of those bad orthotic desks that make half your lower body fall asleep. I'm not relishing the 1.5 hour drive to Tucson tomorrow. Also when I left the car out in the sun for a couple hours, it started to smell like used snorkel gear. Yeah, that slightly rotting rubber smell.

The headlight does that annoying thing where it's always fully on, including for a good 30 seconds after turning the car off. Why must the car try to be smarter than me? Why can't the light just turn off? In related news, I couldn't even find a control for turning the light on/off. How do I turn the headlights on without turning the car on? Is this possible?

The trunk is a marvel of energy conservation. Unless I gently stop it at the top (when opening it), it will quickly bounce back and fall down upon my unsuspecting arms/head. The key on the other hand likes to get stuck halfway out (on a car with < 1000 miles on it).

There are so many controls and buttons in the car, each backlit, that the lower half of my field of vision on a dark night is filled with a glow. Quite a distracting glow. I haven't looked to see if the backlighting can be made less intense, but given the headlight control situation I'm gonna bet no. Seriously, it's like the Milky Way in my lap in here.
 
I guess I should say something good about the car too. It... goes? It.... turns? It.... stops? I can have it display the speed digitally right next to the analog dials for double confirmation? I guess I'll go with "good turning radius", though my bar's pretty low. I'm pretty sure my RSX is about the worst turning small car on the planet. However, it has zero of the issues that the Cruze and Equinox have, combined. Get it right, Chevy.