A few days ago my wife left for Guatemala, since her “permission“ to stay in the U.S. expired, even though her visa's good for much longer. INS (or Citizen Services or whatever lame name they've come up with now), allows you to apply for an extension. In this case, I only wanted a 3 month extension, and applied a month in advance.

Their website indicates it only takes a few days for processing... great! Well, by “few days for processing“, they mean “few days to notify you that we'll start processing“. Their estimated processing time was around 6 months. We'd have had to applied for an extension before we even considered moving to the U.S. $200 for that... sigh. I'd like to dispute the charge since they are purposely misleading on their site, but I'd actually have to spend time dealing with them, so it's not worth the hassle. So off to Guatemala it is.

Seems like just a few weeks ago I was moving to Atlanta... anyways, there are some other good reasons:

  -I did what I came here to do (get some work done on InvisiSource)
  -I remembered that I don't like living here that much after all (OK, I noticed that months ago)
  -Trying to stay here legally long term is too much of a PITA (which is funny, considering this country was built on people leaving other countries)

There will be some things I miss such as my 3Mbps Comcast line. And...that's about it. Fortunately, Bellsouth is offering a 2Mbps wireless connection where I'll be living so perhaps that'll be close enough...

On the plus side:

  -I'll be near family (both my immediate family and my wife's family)
  -I'll no longer have a problem driving without a license or insurance
     (actually, pretty much any issues like that are cheap enough to solve)
  -I'll make more money (cheap cost of living, no IRS worries)

Of course, there are a lot of annoying things about living in a 3rd world country, so this won't be long term. I'm planning on getting my wife Canadian residency while down there, so we can eventually get Canadian citizenship for her. After that, then we can move anywhere we want without immigration troubles. Then the only issue becomes finding a decent country (Canada looks nice)...

I interview people as part of my job. Many times I know of someone who's looking for a good developer and I interview people every so often. I'm not by any means an expert interviewer, but I've learned a few things. Here are some notes for both sides of the table. These apply to technical interviews.

My goal as an interviewer is to determine what you know, and what you do not know.

1: Be honest
It's ok to say your an expert in a certain area, but know where you are not. Unless you wrote the entire system in question from start to finish, there's probably a few areas you are unsure in. Take .NET for instance. .NET is huge. It's impossible that you are a guru and know every IL and x86 instruction in every single class. You might have worked on many different parts, but don't try to say you aren't weak in any of them. The interviewer will find an area you're weak with, and you'll be forced to make a retraction “Oh well, actually, I've never touched remoting or Windows Forms.” It's not BAD to not know something. During an interview, the goal is to find if you're smart and will work well. If a question is asked and you have no clue, *say so*. I try to ask a question like that every time (some esoteric thing). Good candidates will answer with “Well, I believe this is related to that, but I'd have to look this up to be sure.“ or “I'm not familiar with that.“ Bad candidates will try to make up some BS answer, perhaps thinking that you have no clue what it is either. In other cases, the interviewer just wants to know your limitations.

If you are interviewing, and feel like you're getting BS'd, start drilling down. Perhaps the interviewee misunderstood the question or is unsure of what you want. I like to give people a second chance if they start something, just to show that BS isn't going to fly. However, if the second answer to “So, you have no weaknesses?“ is “No...“ -- red flag.

2: If your resume says you know something, you better know it
Don't copy and paste the .NET Framework class library reference into your resume unless you truly understand how to use each class in detail. If something's on your resume, we'll pound you on it. That's how we determine how well you know technology. The specifics aren't important. If you write “.NET Remoting”, you better be able to tell me what MarshalByRefObject does and how statics work in this context. If you have a CS degree you better sure be able to tell me what a binary tree is. And by all means, don't say you're a C# expert, and go on to describe that C# is actually just a mix between JavaScript and Visual Basic. (Yes, that really happened.)

When interviewing, many times a great candidate won't have experience with the particular technology you're using. That's ok, provided they can learn and are good in other areas. The problem is always trying to find something you can quiz them on. I look to their resume and see. Whatever they list, I ask them to rate themselves in it. If they still say they are experts in it, then I'll drill in with a few questions on that technology. “How good is their best?“ -- that's what I want to answer.

3: Know some basics
Everyone who can type can use Visual Studio. Saying you built a data-driven app with ASP.NET only tells me that you have basic mouse and keyboard skills. You better be able to handle some fundamental *thinking*. Traverse a tree, reverse a string, add items into a sorted array. Don't bother trying to defend saying “these are impractical -- when's the last time you used BinarySearch in a real app“? Umm, let me think... yesterday. You won't get hired for *real* work if you are just a IDE groupie. Sure, you can make cool things happen, perhaps even get paid. But I'm also interested in that the code you generate is decent. Sure, in many cases you might be able to go allocation crazy and box 1 million ints for fun. In other situations, you'll need to write better code, and you need to know how to do that. If you don't want these questions, say you dropped out of school and have been just programming for years. While it might not save you if you're an idiot, at least it gives the interviewer a frame of reference. At least that's better than saying you have a CS degree, but not knowing what a BinaryTree is, how to sort an array, or so on.

Interviewing people for .NET positions can be hard, because Microsoft's done the hard work for us in most cases. One red alert is “Well, perhaps I'm not that good in that, but I know my way around .NET.“ That's like a mechanic saying “Well, hmm, I'm not sure of the difference between these fluids and those hoses, but I've got 101 power tools and a lot of rags, so I can get it working.“ You don't want people who just “get stuff working“. You want people who are going to build something nice, something you don't mind working on later on.

4: Ask for clarification
If you are unsure about something, ask to clarify it. If you think there could be something else, ask. If you have to write a function, get some context. Is this part of a realtime process and needs to execute with a given amount of resources? Or is this a drag-n-drop application that runs once a year? Sometimes it won't matter, but when it does, you've saved yourself the trouble of saying “Oh, I didn't know you wanted *efficient* code. Let me go rewrite that.“.

Sometimes it's a good idea to hold details back to see what the interviewee does. Good candidates will try to gather requirements or probe you to see what's going on. Not so good candidates just start blasting away. On the job, that means they might be likely to just write some code without much forethought of how it's going to work with everything else. Or it means that they might spend 10 hours writing a super-efficient algorithm in x86 for something that's only called once a day or will never be a bottleneck, thus lowering productivity. Try to see what balances they strike out, what trade-offs they make. If a candidate seems hestitant, volunteer some information. On interviews, people react differently than they will on the job. Hesitation might just mean they want to ask, but are afraid of negative points.

5: Have a good attitude
Almost always, you'll be joining a team and have to work with other human beings. While it might be “right” to get the smartest person ('cause intelligence is all that matters, right? :)), even if they are arrogant, it probably won't happen. You'll want to show that you will get along with other members on the team.

When interviewing, I try to make sure that this person is going to cooperate. Are they going to write code while getting feedback from others? Or will they write their “own” code and defend it at all costs? Will they help out other team members, or try to fight for the “top”?

Anyways, those are just a few notes I've realised when interviewing people. Hope it helps someone!

Before you form another stance on DRM, read this briefing. Cory Doctorow presented this talk to Microsoft last month. Cory's exactly correct about DRM. He talks about exactly WHY *I'm not* going to buy any more DVDs or CDs until someone fixes the technology. Very excellent article; a definate must read if you're working with anyone in contact with DRM.

Anyone who knows me knows how much I like Microsoft. That company has repeatedly improved my standard of living. Since I spend too many hours a day using their products, they've made a huge impact on me. Sure, people can make their comments about MS, but the personal computer industry would not be the same had individual hardware makers (IBM) gotten their way (just think about if no one had a common software model to work against). Being a developer just really increases my fondness of Microsoft, since Microsoft loves developers a lot. Visual Studio is an amazing product. So, you can imagine how excited I was to interview for Microsoft.

I had been “hoping” to get an interview there someday, a hope that I really never expected to come true. Thanks to someone, I got my resume submitted via the internal site. Knowing that many hires come from internal referrals, my hope was now increased. My chances were now somewhere less than 1-in-the-length-of-a-whale-in-nanometers. Quite some time passed and I had heard nothing (as expected). Then, one day, out of the blue, I get an email from a recruiter asking if “I'd be interested in an opportunity at Microsoft”. I thought it was a joke at first, but after verifying that person does indeed exist at MS and is indeed a recruiter, wow was all I could think.

Now, let me tell you a bit about myself. Internally, my emotions are held in an signed 16-bit register (ok, it's technically more complex than that, as any 8th-year-neurosurgeon knows, but I'm making a point). Usually that works just fine. Well, not in this case. My excitement levels quickly overflowed and then I calmed down. And then I got excited again, and so on and so forth. This continued to happen over the next few weeks. Perhaps the closest experience was when I installed the first Whidbey alpha, where I promptly hyper-respirated, blacked out and fell out of my chair. At least I had soft carpeting.

Well, I responded to the recuiter, saying that “Yes, I'd be interested.” This was followed by a phone interview, to see what experience I have, what I do [not] well, and so on. I was told that I looked interesting because of my C# background. I also found out that I wasn't found in the internal database, but just by searching on the web. Wow. The recruiter was from HED, the Home Entertainment Division. This includes XBox, Encarta, and so on. I still didn't know what the position was, but I tried to find it on the online site, and thought it might have something to do with an XBox server, since that was the only posting that was geared towards a C# person. I don't have any experience programming games or 3D so this seemed a bit odd. The only info I had was that it was an SDE position involving C#.

I soon got an email from the recruiter with details on the position (it's a new product), and asking when I could meet with the hiring manager. About a week later had an interview with the hiring manager, the person who would be my boss if I was accepted. This was more technical, asking about specific technologies, having me explain some design decisions I'd make, and a technical question. I thought I was doing pretty well up until the technical question. It was a trivial question about linked lists, but it seemed like it took me forever to answer it. I suppose it was only a few minutes, but I sure was sweating. We then talked a little bit about the order of complexity of the solution. At least the asymptotic analysis came quickly to me.

After the question, I figured I had blown it. I thought that surely even a half-year CS student could answer it in 5 seconds (something that I later found not to be to true of many people). I never did much formal education, dropping out after grade 10 or 11. So I haven't learned or memorized any “basic” CS stuff via any normal channels, but instead mainly through experience. The next question confirmed it: “What's your education level?”... “Umm. None. I've just been using computers since I was 3 or 4.” “Ok, I see. Well, the recruiter will follow up with you...” I wasn't going to take that for an answer. I really wanted to know “Was I a total dumbass?” The hiring manager then said that it was not a negative (not having formal education, that is), and that he would like to move forward with me, but that the recruiter needs to handle those details. Ok, so I wasn't being blown off.

Soon I get an email from the recruiter, saying that they'd like to move forward and fly me to Redmond for interviews. Wow. A dream come true. I'm actually going to Redmond. I had only been there once before, for the Global MVP Summit. It was extremely impressive, to say the least. During the next week, we got all the details arranged. Microsoft buys you the airplane ticket, hotel, rental car (although I can't legally drive in the states, ok, well, I can't legally drive anywhere, but at least in Guatemala a few bucks fixes that) or reimburses you for taxis. They also reimburse you for food and other expenses. However, they do not reimburse you for gambling expenses, haircuts, alcohol, or other “personal entertainment”, which includes the pay-per-view porn at hotels. They make this very clear on their website, leading me to wonder how many people tried to pass of a $10,000 bill for a complete makeover, champagne, and a couple of call girls. Their websites handle everything, including making your appointments. Very smooth (it'd have to be, with the number of people they interview).

I had a trip coming up, so it was actually about 3 weeks before I could get out there. I re-read “How to move Mount Fuji”, which was o.k. Some of the answers were wrong (I had read it a year earlier, just for fun) though, and it doesn't cover any technical questions. Nice flight out, easy taxi over to the Marriot Courtyard, which is just a block away from campus. The night I got there, I met up with a friend from MS, and had some Pho'. He was very reassuring, telling me about his interviews, which was quite helpful. I didn't get to sleep until quite late, and I slept quite poorly as well. Due to the time change, I also woke up quite early too. Not a good start. I went down and had a few cups of yogurt, and noticed that my hands were shaking. Quite a few other people were there on Microsoft-related business. Maybe the whole hotel was rented by MS. Who knows.

First off, I had to meet the recruiter. That building was not on campus, and was actually about 4km away. Not being able to calculate the time a taxi traveling at 50km/hr would take to go 4km, I left about an hour an a half before my appointment, promptly arriving 1.3 hours early. Well, better early than late, eh? I nervously paced around the waiting room, perhaps annoying the receptionist who was frantically trying to reschedule a meeting room she overbooked. I think I finally got a bit calmer, somehow. Or maybe I just thought I was calm. Finally, I was entered into the sacred building and sat down in the recruiters office.

He gave me a brief overview of what I was here for, telling me the routine. One piece of advice I was given “Do not bullshit these people. They are very smart, and it will not work. Don't even try. Just be yourself.“ I had 3 interviews scheduled. The second one was a lunch interview. From what I had heard, they give you a few interviews. If you suck, they don't give you any extras, or come up with an excuse like “The next person to interview's kids just got hit by a truck, so he won't be in today. So you can go.” If you don't suck, then you'll get “bonus” interviews. Without much ado, I got on the shuttle and headed over to the (or one of the) Encarta building(s).

My first interview was with a dev lead for Encarta. The entire interview was writing code on the whiteboard. Most of it was writing a string-lookup function, so we dicussed dictionaries, hashtables, and so on, as well explaining some .NET-specific code (since string interning can be used). I think I did alright there. Very friendly and nice person. Right before I left, I had to write a simple C++ function to deal with linked lists, mainly to make sure I knew what pointers are and how they are used. No problem there.

My next interview was with another dev lead for Encarta, this time on the online version. We went to an Indian restaurant, and the food was great. I had never had Indian food at an Indian restaurant before, so that was quite enjoyable. Looking back, perhaps I enjoyed the food too much and maybe shouldn't have eaten, so as to answer more questions. On the way over, I was asked to explain things about garbage collection, disposing and finalization. I was on solid ground there. In fact, that's a question I ask many people I interview. During lunch, we talked about ASP.NET, different kinds of controls, caching strategies for search engines, and so on. When we got back, I had to write some code to do some caching, making it syncronized so that data is never retrieved more than once. I also did a small “reverse a string“ sample in C.

The next interview was finally with someone who was on the new product team. A good portion was spent talking about what the product actually was (since I was still rather in the dark). Then I had to write some code to randomize a deck of cards (in other words, randomize an array order). We had some fun discussions about random output and probability. I did well there too. By that I mean I was correct, and I'm pretty sure he thought the same way too. I say this, because in another discussion with someone else, they pointed out an “optmiziation” to an algorithm when we were leaving (so I didn't get a chance to rebut it) that was based on a false assumption, and was thus wrong, especially in light of the optimizations the JIT engine does.

One troubling thing revealed was that it was not sure that C# was going to be used. Apparently, Microsoft suffers from internal politics like any other company and due to some situations out of this team's control, having the .NET Framework was not a given. I told them this was utter crap, and that the other team should fix their thinking (in fact, I told this team that they should do so during the last beta of their product), and they seemed to agree. But that didn't change the situation that we might have to use C++. I'm not that good with C++. I haven't done much work in it for a while, and the last time I did use it, it was Managed C++. Of course, I'd write in C++ if they wanted me to. I told them that for MS, I'd write in Cobol, Ada, Prolog, or even Brainf*ck. At this point, my hopes went down. There are definately more experienced people for the job if they want a C++ Windows application. Considering that a reason the recuiter called was for a “C# expert“, this was quite a letdown.

However, I did get a bonus interview, to see if I was smart enough to really do a good job C++, or to see if I was just a .NET-groupie. This time, I met with a dev lead on an educational product. She posed quite a few different design questions, asked about order of complexity, different algorithms, explaining dictionary versus hashtable (and what is the “HybridDictionary“ .NET class), and so on. I had to write a search function for a binary tree in C++, which I did alright, except for one syntax mistake at the end (hey, I told them I hadn't used C++ for a while). I think I did well overall, because I got another bonus interview: The End Boss.

The first think the hiring manager asked me when I sat down with him was “How are you doing?“ to which I responded “Well, I'm seeing you, so I guess I'm not doing that bad.“ “Oh, so you know how things work here...“ We dicussed more of the project at hand, talked about my past experience (“What was the hardest non-technical thing you've done?“). Then the technical question. Before I describe this, let me note that I had only slept about 5 hours the night before, and had been up since 6 or 7, and interviewing since 11. It was now 6:30PM. This would throw me off my game any day, but adding the pressure and excitement of being on campus, and well, I wasn't in my top-coding mood by now. I might not have realised it unless he had pointed out that it was late (I was doing o.k. in the last interview). Anyways, up to the whiteboard.

“Find the smallest element in a circular array.” I chucked internally -- damn, this was easy. I instantly knew how to approach it, so set about it. He takes one glance, and “Nope, that doesn't work.“ Red Alert. After a few off-by-one errors, I thought I had it. “Nope, still doesn't work, but you fixed another small issue.“ Panic mode. Hmm, should I open my wallet and take some Xanax? Nah, it was too late. The pressure was already on. I wish I had brought Xanax. “Hmm, that, no, I don't think, nope. Still wrong.” This guy was smart (as was everyone else, but I didn't embarrass myself as much in front of them). I felt like he could see right through my mind, laughing at each weak neuron. He gave me a simple hint, and it was a small, obvious thing, a particular case. Something I would have caught in VS in about 10 seconds. Of course the code didn't work. So I added some checks for the case. “Nope. Still doesn't work.” Fixed a few other issues with the recursion. “Yea, ok, that's more or less it.“ I had lost. Perhaps it worked, but the whiteboard was a mess. “Well, you're tired, it's been a long day, and it's late.“ Then I made the biggest mistake of the day.

“Look, give me another question, so I can prove I'm not a dumbass.“ And another, retardedly easy question he gave me. And at that precise moment, my brain decided to stop functioning. Somehow, 0xF5 got sent to the part of my brain that does coding and thinking. HLT. How simple can it be? “Write a non-recursive function to do inorder traversal of a binary tree.“ Nothing that should take much time at all. But boom. I profusely apologised and promised to email him the code. He said that was ok.

For the next 48 hours (which consisted of sleeping, riding an airplane, and sleeping), I could do nothing but berate myself. I got seriously depressed/annoyed. Not because I blew my chance, but because I felt so utterly stupid. I could handle “We are looking for a different skillset.“ I couldn't handle “You're a bloody idiot. Give us back the hotel fare.“ I finally sat down, spit out the code, make a quick pass at refining it for elegance, and sent it off. At least I had done it. Now all I could do was wait. The recuiter promised to get back to me within a few days.

Well, a few days and nothing, so I pinged him. “They haven't made a decision yet. However, if they don't want you, I'll look for another position for you.“ A week later (which was last week) “Not for that position. They have another opening soon, maybe there. I also am sending your data to two other managers for other positions.“

And that's where I stand. I know these things take time, so maybe I'll get some good news. Looking back on everything, I'm not sure how bad the last interview was. Maybe they were just looking for someone, who, say, knew how to write a Windows app in C++ already. I'm guessing if I totally flubbed it, they'd tell me “You sucked, no thanks.“ From reading The Moon Gals Blog, I know it'll take time. At any rate, I'm feeling great now. Interviewing was more than I had hoped for, so that's pretty cool in and of itself. I'd love to be hired, obviously, but at least the suspense is over.

According to the film companies in the UK, terrorists sell pirate DVDs to raise funds. So, forget all the benefits that I mentioned the other day, now, buying a DVD off the street means supporting terrorism. That really does it explain it all, eh? Pirates are painted as evil vile villains, and terrorists also fit that bill, so why not connect 'em? I'm just surprised it took someone so long to come find the link. I wonder how long it'll be until we learn Saddam has stockpiles of counterfeit DVDs, just waiting to flood the market and make the economy collapse... The industry makes it quite clear that there are more people than just terrorists (no, really?) who are pirates.

My favourite quote from the article was “By purchasing pirated DVDs, many consumers are unwittingly helping to fund hardcore criminals with links to people trafficking, drugs, guns and money laundering” -- wow. I'd hate to think what people who sell pirated copies of SQL Server do!

They also make a lame attack at the quality of pirated wares, saying “They were rubbish, they were shaky, out of focus, camerawork was bad, they had muffled sound”. Well, sir, it looks like you bought a SCREENER, something no decent pirate would sell. Oh wait, they're evil, vile criminals. So I suppose the moral of the story is: Don't buy unprofessional pirated DVDs 'cause they suck. Find a pirate who knows what they're doing, and in the process, stop funding terrorism.

For those of you who played D&D (here's a funny video to see what it's like), you might recall that there were magical tomes that could increase or decrease your abilities, just by reading them. Of course that's impossible in real life since we'd need powerful magic... right? Well, as I have unfortunately learned, no. A while ago, I had to maintain someone else's app. I believe in the process of reading this app's code, I have lost a few IQ points. Let's take a look, shall we?*

All the code in this app uses horrible variable names. In a 250 line block of code (a single method -- the writers must have thought there to be huge drawbacks to using methods), the first line starts off by declaring the variables. A sample looks this:

dim objconn,objrs,strDatabase,mysql,mysql1,sqlstring,rstemp,dbConn1,objrs1,query

This is a truncated line. They actually declare about double that much. Regardless on how you feel about declaring everything at the top of a file, this is bad. They don't use these variables at the same time. For instance, they'll open objrs, do something, and then close it, then open rstemp and repeat. There aren't actually two objects in use at once. They just declared extra variables for fun. Or maybe they thought they had to give the variables a rest. I don't know. And I don't think they did either. Of course, it's better than using no variable names at all.

They have a process to read values from a comma-delimited file. So, one line at a time, they use VB's split function, storing the result in a variable named “split“. So far so good. Then they proceed to use constants for the next 100 lines to refer to different fields, giving way to wonderful code as so:

if split(6) = “true“ then
  objrs1.open “SELECT * FROM Table WHERE Field1 = “ & split(2) & “ Field2 = '“ & split(9) & “'“
  split(4) = objrs1(“SomeField“)

At a few places in the app, a field is selected from the DB for absolutely no reason:

someId = Request.QueryString(“someId“)
rs.Open “SELECT SomeId FROM Orders WHERE SomeId = “ & someId, objConn1
someId = rs(“SomeId“)

That's right. They select a single field (an int), constraining it to the current value of their var, and then set the var to the same value. Maybe there's something special in SQL that I'm not aware of. To their credit, there's actually a check for rs.Eof first (omitted for clarity of stupidity).

Here's a brilliant idea for performance: Don't use SQL's COUNT. In quite a few places, they'll execute a semi-complex query that returns, on average, 10,000 rows. But why bother with SELECT COUNT, when we have SELECT *?

The entire app is built like this. The people who wrote this should have their text editors confiscated.

* Some variable names have been renamed to protect the innoce-- mentally challenged.

When I first heard about DVD technology, I was pretty excited. 9GB on a single CD-sized disc seemed pretty cool. Having video on it seemed just like any other application of this technology… you got space, so put something there. What I thought was cool is that we’d be able to jump to any area at a time (like CDs), and that there could be lots of extra information along with the video. Listen to it in a different language, have subtitles in 10 languages – cool.

Well, imagine my disappointment when I first got “The Matrix” on DVD. English only. What? Why on earth would they put only one language on it? Can subtitle files be that big? Then I was introduced to the utterly stupid system known as regional codes. Region codes were invented so that the movie studios could keep their current business model of releasing a film much later in other countries, by coding a DVD to work only with a certain coded DVD player. The idea is that in each region of the world, you can only obtain DVDs and players of a certain code. Why they have this business model is beyond me (it’s certainly not a logistical limitation). How they thought this had any chance in the world of actually being effective, is even further beyond me (wait, not it’s not, these people also fought VHS…). When I lived in Guatemala, I could rent DVDs at the local video rental store before they had hit cinemas in the u.s. let alone in Guatemala.

Region coding is such a horrible idea – it’s like programmers who think all text is ASCII (or who think there’s an 8-bit ASCII). When I watch movies with my wife’s family, many times we’ll have Spanish subtitles turned on. Everyone can enjoy the original voices (Mexican/Western dubbing is atrocious), as well as get clarity on parts they might not understand. Well, of course, under this system, that’s impossible. Also, my family doesn’t use Spanish at all, but they live in Guatemala. Half of the hardware/DVDs available (well, nearly everything in the retail market) won’t work on their equipment. Fortunately pirate sales are all over ($2 for a DVD!) and have region encoding removed.

I got the “Tonari no totoro” DVD, but guess what? Fox thought “who needs Japanese audio?” and left us only with a horrible English dub. So much for enjoying their product. But I could always get a foreign version with English subs and original audio… oh wait, but that’s region 2, so I won’t buy it. So much for the business model. One exception I did notice: “Dr. Strangelove (Or How I Learned To Stopped Worrying And Love The Bomb)“ (Special Edition) has 7 languages, including Spanish and Korean. *That's* how DVDs should be made.

To make things worse, the geniuses who invented the DVD virtual machine, thought it’d be cool to have “Prohibited User Operations”. This allows the designer of a DVD to decide that you can’t switch subtitles, audio tracks, or jump to a different chapter/title. I just received Lost in Translation DVD from Netflix. When you start to play it (and after the useless and annoying FBI warning), a screen comes up saying “You may fast forward to the menu”. Excuse me? Fast forward? What is this, a tape? Sure enough – they disabled all skipping, *forcing* the user to watch their previews (even at a high scan speed). On the player I was using, going to another title (there are 4 or 5 of them before the menu) takes the playback out of scan mode and sticks it back into play. So here I am, in 2004, repeatedly hitting “Fast Forward” to get to the menu of the DVD. Sigh. On the bright side, most DVD ripping software (to make copies) removes prohibited user ops, so anyone with a pirated copy might not have to sit though this.

What a strange world it is when pirates actually get things better of than those of us who pay. The MPAA blames the Internet as the reason why people pirate. Perhaps there’s another reason (hint: Regardless of what the RIAA says, pissing customers off is not good for business).

Well, after quite some time, we've finally sent out the first beta of InvisiSource. It's an encrypted loader/obfuscator that I've been working on for quite some time. The reason it's been taking so long is that when we approach obfuscation, we try to make the obfuscation break as many rules as possible, to make the code even harder to reverse engineer. Unfortunately, it's quite easy to break too many rules and end up with something that won't run in every scenario. Over the past while, I've discovered many tricks that'd throw quite a screwball at a potential cracker. Unfortunately, the conditions on them make them unsuitable for every app. Other factors that took a while: debugging encrypted code and obfuscated code is, by design, hard :).

Anyways, we're going to be giving out Xbox systems to the top three beta testers (which is a good amount, considering the size of the tester pool). So, head on over to www.invisiSource.net and sign up!

Two things that are often confused are safety and security. Aren't they the same? Well, no. The difference can be quite subtle in some cases, and not-so-subtle other times. Understanding the difference will help you see each for what it is, and not get a false sense of security.

Being safe means that you are free from harm via accidents. Being secure means being free from harm via attacks. What's the difference? Engineering a safe building might mean that it won't fall over if 100 extra people get in it, or if an earthquake occurs. Designing a secure building might mean that it won't fall over if someone fires a missle into it, for instance. The sandals I just bought have safety features (non-slip soles), but I don't expect them to be secure against someone leaving caltrops out on my balcony.

Most things we encounter in daily life are designed for safety. Even things sold for “security” are sometimes designed more with safety in mind: consider a can of mace. The models I've seen are designed so that it's actually a tad more difficult to fire them, as well as being weakened for “civilian” use. As civilians, we're under much more threat of accidents than attacks. I'm more worried about some drunk driving a car into me than an assassin waiting to run me down. This is a good thing: in real life, being secure from attacks is quite difficult.

Kidnapping/robbing/killing/whatever someone in most places is easy. The threat of punishment and an effective enforcement is what acts as a deterrent. In places that lack enforcement, say, where I used to live, such things occur much more frequently, not because they are any easier to do, but because there's no penalty. My dad was kidnapped down there, and almost executed. Our neighbours had something similar happen, but they weren't so lucky :(. However, even there, a bigger worry is a bus like this, this, or this.

However, in computer systems, the equation does not hold up. Users can delete their own documents. Or pour coffee on their keyboards. However, when connected to a network, you can get attacked from around the globe, millions of times per second. People are being blackmailed simply via sending a single email. And electronic attacks, unlike physical attacks, are usually harder to prosecute. If you have worked in IT for a while, you probably have a story or two where you could have made quite some money by breaking a law or two (my favourite is the bank that called me for some work: they had one network with all their data on it. This network also had an NT4 machine running Exchange, and was directly connected (just a router) to the Internet.). These attacks would have been much harder in the physical world. In the real world, the bank should probably worry more about clearly marked emergency exit lights than someone driving a car through the wall.

Deciding how safe or how secure a system should be becomes very difficult. A classic example: data backup. On one end, we want our users to quickly recover from any problem. However, each backup copy made introduces yet another item to be secured. Your data would be safe from accidental deletion if you burned a CD with it and mass-mailed it ala AOL. However it wouldn't be very secure. You can secure it be encrypting everything with no unencrypted backups and a single key, but if you lose the key, your data remains secure, but not safe from loss.

How should a file delete function work? Safety says that the file shouldn't be wiped, just marked as deleted (or in the Windows Recycle bin case, just moved to another folder). Security says the area where the file is should be at least zeroed out.

AntiVirus software (for instance) is almost completely a safety product. It helps stops a user from accidentally running something bad. It does nothing if someone deliberately crafts an attack at them. It'll detect if a 10-yr-old installs NetBus on your machine. It won't do anything if a 16-yr-old first plays with the NetBus executable with a hex editor.

”Disabling” VBS and WSH scripts on your computer doesn't really increase your security. It just lowers the safety problem of someone accidentally clicking a script that is known to be harmful. It won't help if someone compiles that script into x86 and throws a .exe extention on it. On most modern PCs, there is no secure way to run arbitrary code (although managed code/virtual machines should alleviate this eventually).

People who place trust in these fake-security measures are being deceived by safety measures. It works because real-world counterparts are hard to come by. While this is good for the makers of such software, it can be devastating if it's not taken for what it actually is. For instance: If your computer is infected with some virus/trojan/whatever, cleaning it with AV software is *not* secure. The only secure action at that point is to re-install (or at least verify) that the entire OS and configuration is correct. For all you know, the trojan could have modified the Windows' kernel, the AV interface, and everything else.

Fortunately, many times safety software won't actually hurt your security. Just running AV in a proactive mode doesn't make you less secure. It's the improper use and faith in this software that's dangerous. So, as always, getting a secure system can be really difficult. This is just one more potential pitfall to watch out for.

If you've dealt with symmetrical algorithms, such as DES, 3DES or Rijndael, you're probably aware that you must supply a key and and IV to encrypt/decrypt. If you're not aware of this, you shouldn't be writing code that works with cryptography :). Everyone knows what the key is, but what's the IV? IV stands for initialization vector. IVs are used to “jump start” the cipher stream. Not clear? It helps to understand how to look at a cipher.

Think of a cipher as a random mapping from a piece of plaintext to a piece of ciphertext. Most modern ciphers are block ciphers: they work on n-bit blocks of plaintext at a time. Thus we can imagine a cipher such as Rijndael (which uses 128-bit blocks) to have a huge dictionary: one entry for every possible plaintext and it's corresponding ciphertext. In reality, there's not that much memory available, so instead the ciphertext is computed.

So lets take a sample message: “Hi Bob, how are you?” We'll split that into blocks: “HiBob HowAr eYou?”. With a particular key, the ciphertext might be “LaAHz IAtXm LyJxr”. Everything's nice and safe. Now, let's send another message: “Hi Bob, game?” This becomes “HiBob Game?”, and ciphertext “LaAHz KozhW”. Notice a problem? Since the first two blocks have the same plaintext, they will have the same ciphertext. If an attacker knows the format of the message, he can start to guess the first part of our messages (since “HiAlice” and “HiEve” would have different first blocks). This can get worse.

Imagine that the messages are orders, and the first block is the item number, the second the price, and the third the quantity. Now an attacker can determine (say by entering an order and looking at the output -- called a chosen plaintext attack) which ciphertexts correspond to which items/prices/quantity. Modification of the messages can be stopped by a digital signature algorithms. But what about reading? Enter the cipher mode.

The cipher mode I've been describing is ECB, Electronic Code Book. It's exactly as it sounds -- basically a big lookup. Each block is processed by itself. As shown, this isn't very secure for most applications. The most basic improvement is the CBC mode. (There are other modes as well, but CBC works for this article.)

CBC stands for Cipher Block Chaining. CBC takes the ciphertext of the previous block, and XORs it with the current plaintext block before encrypting it. Thus the ciphertext block for “10000” won't always be the same, but it'll depend on what the preceeding plaintext is. So, the message “12345 10000 29500” will have completely different ciphertext than “54321 10000 29500”.

So, using the previous block is easy, but what about the first block? This is where the IV is used. The IV is the “previous encryption“ for the first block. So when we encrypt “HiBob“, we're going to first XOR “HiBob“ with our current IV.

IVs are not sensitive. You do not need to hide the IV. Many times, a unique message ID is used as an IV, since many applications require a unique ID anyways. It's perfectly fine to send along the IV as the first piece of ciphertext. Thus, we read the first block, and use that as the IV when decrypting. This makes managing the IV very simple, since it's right there with the message.

However, just remember to never reuse an IV! If you reuse an IV, it defeats the purpose, since the benefit of the IV is negated. Any given plaintext will always be the same with a given key and IV. But since IVs aren't sensitive, and easy to manage, this shouldn't be an issue.

Are you a strong ASP.NET tester or developer? If so, I might have a job for you. We're currently looking for a tester with strong development skills who can create and automate test cases for an ASP.NET application. Strong coding skills in C# as well as understanding of ASP.NET, HTML and SQL are required. We're also looking for strong developers to join an existing team and work on a medium-sized project.

If you are interested, drop me a line: mgg AT atrevido . net.

Quite some years ago (8 or 9?), I played a game called One Must Fall, a cool robot melee fighter game. Now they released a new version with cool effects, Internet play, and so on: One Must Fall:Battlegrounds. I just recently learned it was shipping (they did good job of press before it shipped, but I never heard about it after it shipped). My copy finally arrived in the mail today. I start it up, check it out, and after winning a level, the game quits with this message box:
---------------------------
Protection Error
---------------------------
Debugger detected  - please close it down and restart! Windows NT users: Please note that having the WinIce/SoftIce service installed means that you are running a debugger!
---------------------------
OK  
---------------------------
This is wrong. I work from home, as well as play games from home. I've got a few debuggers installed (not SoftICE though). At the time, I had Visual Studio closed, and hadn't been running the debugger since my machine started. But what's worse is that apparently they thought this perfectly acceptable! Note that this doesn't stop piracy *AT ALL*. Experienced crackers are going to crack the game, and serious “pirates” are going to apply patches. Having a CD check stops “casual piracy”. Having a debugger check stops wannabe crackers from cracking. That's it!

I've emailed support with my current plan of action: Try a pirated version and if that doesn't work, return it for a refund (something publishers don't like). Sigh.

Update: Well, I reluctlantly installed a crack from a game backup site. And guess what? It works just fine. No more debugger complaints (and I get to take the CD out too).

Last update: Got in touch with one of the developers. At first, they thought it was a problem with DirectX, or the video card or likewise, since their code doesn't do any checking. However, they were using SafeDisc (which is less safe than rolling your own, since there are a few tools that instantly remove SafeDisc). However, after I told them that a pirate crack makes the game run, he said he'd get me an unprotected version. Hey, at least their support is good!

At the PDC '03, and the time after it, it seemed like Microsoft was really liking ATI. I remember using their cards a long time ago, and it was a very bad experience. So, I've been quite loyal to nVidia for the past while, since they hadn't disappointed majorly... until a few days ago. I just left for a trip, and was counting on using Remote Desktop to get access to VS, Outlook, etc. while on the road.

I connect to my machine from my laptop. User... pass.. applying settings -- window closes. Try again. On another machine. Try with a different user (perhaps the profile was messed up...). All the same. After login, the window closes.

Google group search for “remote desktop closes”... and tada! Are you using nVidia's drivers? Guess what? Their drivers install a service and yep, that service kills remote desktop. Stop the service, and you're set. Well, I'm 3000 miles away from my computer, so that's pretty hard (two firewalls, so I can't connect to SQL Server and run a extended procedure or likewise).

Apparently, this is nothing that new (judging from Google groups), but I don't remember nVidia mentioning this in their release notes. Why can't hardware vendors just make drivers? That's all I need. Drivers and an optional configuration app. Seems like this trend is only getting worse...