Nerdlife

Fun story: I needed to borrow a friend’s car today. He gave me his set of keys, and said if he found his spare he would swap them. As I was leaving, he ran out. He had found his spare, and tossed them to me. My hands being full, I missed them, and they slid right into the vent behind me. They made a cluck as the hit the bottom of the vent. Then a few seconds later they made another clunk as they flew into the wall below. We both looked at each other and burst out laughing.

The next hour and a half was a parade of ideas and experiments trying to get to the keys. The opening in the vent was about 3 inches thick and twisted around a block of cement such that hands wouldn’t fit in the gap. Throughout the evening ideas were suggested that ranged from a coat hanger with a hook to an electromagnet plugged into a 110-volt outlet (we have a lot of Physicists and Mechanical Engineers in the house…).

We started with an exploratory mission: we taped a flashlight to the top of a webcam, taped the whole thing to a coat hanger, and lowered it into the vent. After a bit of digging we found the keys:

We then spent about an hour sticking every contraption imaginable into the vent trying to grab the keys: magnets, hooks, balls of duct tape. The gap was just too small to maneuver. Finally, everyone had given up as I struggled with the hanger, and I too eventually gave up and went downstairs. That’s when another friend and I decided to try to get into the ceiling of the second floor instead of the floor of the third floor. We took apart a big light fixture, stuck our heads up, and lo and behold, we saw the light from the webcam contraption we still had sticking down the vent. From there it was a hooked wire and some careful reassembly, and we were golden.

Lessons Learned:

• Open vents on the floor are a bad idea
• Either I suck at catching or my friend sucks at throwing
• If your current approach isn’t working, try a completely different one
• When you get your friend’s keys back after he throws them in a vent, don’t scare him by throwing them at him

cmu

jQuery 1.3 just came out, and I must say I’m really looking forward to trying it out. They seem to have made some really great performance improvements, and “live events” will definitely come in handy.

The thing that most caught my eye, however, was the new use of feature detection instead of browser detection. There is an article I read several months back that outlines the concept very well (referring to it as “bug detection”). It’s great to see a framework implement this, as it’s a powerful way to free browser developers from having to leave in their bugs to keep sites working on their browsers (ironic, isn’t it?).

What made me chuckle is looking at the jQuery.support page that outlines what “features” are detected. There are 11 features looked it, and the only time any of them are false are in IE. 8 of them are false in all versions of IE, one is only in IE7, another is in IE 6-8, and the last is in IE 6 and 7 when in Quirks Mode. I always figured that all browsers had compliance issues that required hacks, and IE was just worse, but this makes me wonder: is IE the only one with problems regarding CSS/JS compatibility?

While working on my new WordPress plugin (announcement post coming soon), I stumbled upon an interesting point in the way WordPress plugins work (well, Jorge stumbled upon it, I debugged it). Plugins are loaded as files in the global namespace, not within the confines of a function. This means that variables you declare can have an impact on the rest of WordPress.

A specific example: my plugin had the following lines of code:

foreach($custax_style_pages AS $page)
    add_action('admin_head-'.$page, 'custax_styles');

Harmless, right? Wrong! Unfortunately, the way WP parses queries includes this code:

for ($i=0; $ipublic_query_vars); $i += 1) {
    $wpvar = $this->public_query_vars[$i];
    if (isset($this->extra_query_vars[$wpvar]))
        $this->query_vars[$wpvar] = $this->extra_query_vars[$wpvar];
    elseif (isset($GLOBALS[$wpvar]))
        $this->query_vars[$wpvar] = $GLOBALS[$wpvar];
    //...
}

The end result is that, since $page gets registered in $GLOBALS, and “page” is common enough to be a query variable, everything goes to hell fairly quickly.

The moral of the story? Prefix your variables – all of them – unless you’re positive your code is encased in a function.

wordpress

So I figured I’d jump on the blogger bandwagon in the debate on whether or not PHP is a good first language.

First, a little context.  PHP was the first language I did anything useful in.  I learned QBASIC in middle school, which I used to make some neat games.  Around 7th grade I taught myself PHP by hacking on phpBB installations.  I didn’t learn any other language until college, where I quickly picked up Java, C, and SML (in that order).  I agree that PHP is a horrible language to teach proper programming practices, but that’s not the point of it.

I’ve had the privledge of talking to Rasmus a number of times over the last few years, and while I didn’t get permission to reproduce his comments and so I won’t (I will say he has some funny stories about David Filo…), I can quote an article he wrote approx. 4 years ago on PHP:

PHP was never meant to win any beauty contests. … It was designed to solve a single problem: the Web problem.

It does this very well, as shown by it’s outstanding adoption rate.  The truth is that PHP is hacky, but it’s hacky in a logical way.  It was written to help a programmer have an easier time writing for the web by one in that exact situation, and it does it’s job.  If you need to throw a page together in 5 minutes, you can do that!  Which is exactly what budding programmers should be exposed to.

Think of it this way: why do people learn programming in the first place?  Nowadays, it’s either as a career path, in which case they probably aren’t destined to be hackers in any sense, or because they need to solve a problem and writing a program is the best way to do it.  What is going to turn a newbie on to programming faster: learning proper structure, or being able to pump out a solution to his/her problem in 5 minutes?  I would bet a lot it’s the later.  That’s what hackers do, they pump out a solution to a problem quick and, quite possibly, dirty.

“But Brian, have you ever seen dirty code?” you ask.  Of course I have, and I despise it.  But I contest that proper style is something that can be learned after the fact.  The ability to pump out a prototype in 5 minutes can’t be learned as easily.  The ability to ignore all convention and generate an import script to move all of your data from A to B to get your site back up, or hack together a script to bulk rename files in a really wonky way, while trivial to do for most programmers, can be done much faster with a hacker mentality.

I am a hacker, but I have no problem following convention.  I don’t like to, since it slows down coding, but when I’m in a group of programmers, or working on code that needs to be maintained, I do recognize the point of doing so and follow them (to the letter even).  Of course, I’m by no means the norm on anything, so take what I say with a grain of salt, but it seems to have worked well for me: I can follow convention, but at the same time I can adjust, I can change my style as the situation demands, and I can code up a storm when need be.

programming

Today TechCrunch reported on a paper describing a way to use Facebook for malicious means.  The paper describes a DDoS attack that can be done, leveraging the large number of users of an application to attack a victim site.

While this attack vector is legitimate, I see a number of things that make it inherently infeasibly, and don’t think it really warrants being called a “FaceBot” (implying similar power to a botnet).

In order to create an application, one obviously needs to create a Facebook account, though that can be done anonymously.  The real issue is that in order to execute such an attack, one would need to make an application that is incredibly popular.  The attacker would need to devote a large number of resources to keeping such a popular app up, which would all need to be done anonymously (though would need to be paid for in one way or another).

Let’s say an attacker has gone through all of this to make a popular application: why doesn’t he/she just use those resources for a direct attack?  One possibly answer is that the Facebook DDoS would be hard to shut down, or better in some other way in executing the attack.  This is false because as soon as someone realizes that their traffic is coming from Facebook (whether by referrers, or FB trying to pull images for its cache, or some other mechanism), it can in most instances be stopped immediately, especially considering how most Facebook calls to other sites include the application’s API keys.  Even barring that, IP addresses and Facebook’s logging can be used to determine what application a user was in when they requested the victim’s site.

Additionally, DDoSs using this attack vector are relatively easy to mitigate.  If a hacker already has all of these resources dedicated to keeping an application up, why wouldn’t they just launch a TCP SYN flood or similar lower-level attack, much more potent DoSs, even if launched from a more limited IP range.

Let’s take a different route: suppose a hacker attacks one of Slide’s applications and somehow manages to break in and add an attack iframe.  This is a completely legitimate and anonymous way of attacking a site (though it begs the question of why the hacker didn’t just break into the target site in the first place, assuming both have similar levels of security).  While this is a legitimate issue, the same holds true for all websites.  Should someone hack into Yahoo! and figure out how to deploy a new home page (somewhere between almost-impossible and no-freaking-way on the difficulty scale), almost any site on the internet could easily be taken down.  I certainly hope top app developers take security as seriously as top website owners, but this is nothing special for Facebook.

On the topic of information theft, this is why Facebook requires you to explicitly permit an application to access your information.  The concept of an API implies this potential for theft…users are trusting applications to access their information and not keep it.  There is no way to prevent this for the same reason DRM doesn’t work: if people can view things they can store things.  While this is a legitimate concern, again it is nothing new, and not much can be done about it short of user education.

facebook, hacking, internet