Got Geek?

Apparently there is no power in half of Christchurch city today. Some businesses in the CBD are suffering because of it, such as Pulzar FM – a local radio station who are off the air due to the outage.

In a previous life (read: job) my colleague and I spent a lot of time learning css tricks and tweaks to get our work looking just perfect in all browsers under all conditions. We even discovered and developed a few of our own. No flash? No problem! No javascript? No problem! No brain? No problem – it handled IE as well!

Here’s one of the latest tricks from Eion Robb that’s worth an email home about: a gradient background on a stretchy box with rounded corners.

In summary,
Use an svg image for the background. They’re stretchy, and can have rounded corners.
They can’t usually be background images, so wrap your content in a div, absolutely position the image inside it to be the background.
Use a fallback for IE, e.g. VML, or a normal 4 corners/ 2 sides / top and bottom / no rounded corners solution.

A Mac… with a virus? That’s unheard of! Who would believe it? Certainly not a mac geek. Nor even a reasonable PC geek. So as an iPhone geek, I was surprised to hear the media reporting an iPhone virus.

If I have to explain to you what an iPhone has to do with a Mac, go away!

Ashley Towns, a geek from Wolongong, Australia has created what the media are hailing as the first iPhone virus.

Those iPhone geeks who took the time to jailbreak their iPhone in an attempt to gain some of the expected functionality that Apple has been rationing out may be at more risk than a cheap slut.

As most of the tutorials explain, you must change your password for OpenSSH to protect yourself. Many of you haven’t.

Ashley Towns has found you.

You have been Rickrolled.

Change your passwords now!

Despite what the popular media believes, this isn’t the first iPhone virus of it’s sort. The process of jailbreaking is itself a form of virus, intended to reduce the security Apple worked so hard to build into the iPhone. I doubt this will be the last iPhone virus.

In an old Tom Cruise movie, his incarcerated brother conveys with disparity how he misses the sky. The worst part of prison is not seeing the sky.

At the time this was a fairly meaningless sentiment to me. Prisons these days purportedly have varying degrees of yard time or work during which prisoners surely see the sky. Oh, and I’m not in prison!

Am I free though?

I look out the window today, and I see neighbours’ houses. Trees. Pavement. I ventured outside in search of vastness but was still imprisoned but a solid grey blanket. I scanned the horizon through a full 360° turn but the blanket was unrelenting.

Suddenly depressed by the realisation that I couldn’t gaze at the heavens, I searched my mind for the last time I’d truely experienced the sky.

All I find are shreds and glimpses. Some blue through this window. A cloud through that window. A thin beam of morning Sol between the curtains. Stars are a faded memory.

Until a few years ago anyone with an email address had a very personal relationship with penis enlargement, cheap meds, and nude celebrities.

These days email providers are making a real effort to protect the helpless civilians from an ever increasing barrage of spam, and most are learning not to give their email address to questionable websites.

While said civilians go about their lives receiving “poked” notifications, and sending jokes they insist are “OMG the funniest thing you’ll ever see” we ask that you take a minute of silence to remember us webmaster@s, support@s, and contactus@s. In the name of business we climb from the trenches and publish our contact addresses to the enemy.

Before you decide this is Gallipoli all over again, we have been given a few defenses to use at our discretion.

1. Secret Question – We can start our defense by removing the blindfold. We realize spam bots exist, and that sooner or later they will try to take advantage of us. This is a poor man’s attempt at a Turing test where we can ask the user to answer a simple question the answer to which both parties are likely to know. “What animal is man’s best friend?”; “What is one plus two?”.
2. Hidden Fields – Most spam bots know that if they don’t fill out all of the fields (name, email address, message) their submission will likely be rejected. Thus they simply fill in all of the fields. This is where we can out-smart them by deploying our decoy. A hidden field. It’s not visible to the user and should never be filled in.
   A spam bot, on the other hand, reads the code and not the screen. All it sees is a field, thus it fills it with text.
   If your form is submitted and the hidden field isn’t blank, you’ve got a spam message and can safely discard it.
3. Sessions – Any good soldier is suspicious of a new face. The comrade to your left has fought by your side before. You trust him. When he submits the form he does so with a hidden one time code. It can be hidden so he doesn’t even know he had it.You gave him the code in a hidden field when he loaded the form, and kept a copy in his session. Upon submission you compare the code he’s offered with the one in his session. If he’s given you the wrong code, burn the message.
4. CAPTCHA – This is our super power. Like all programs, spam bots are bound by logic. A CAPTCHA leverages a human’s interpretive powers to deduce an answer a spam bot’s logic can’t. Again this is a secret code that our server knows.. but instead of giving it to the user in plaintext (even hidden a spam bot can still read it!) we encode it as an image. Sometimes even warp it or bury amongst tangles of superfluous lines. This makes the code unreadable to a program. Even one with character-recognition.

A good soldier doesn’t step onto the battle field unprotected. Neither should a web developer.

If you ask anyone “who are the biggest software giants in the world?” chances are their response will be:

In the evil corner: Microsoft; And in the good corner: Google.

As I am a big fan of playing devil’s advocate, my stance on the the accuracy of these reputations often varies depending on that with whom I’m discussing it. The dichotomy aside we can all agree these are metaphorical giants.

Google in particular has piqued my interested in the past few days in large part due to the failure of some Gmail accounts (mine among them). There are so frequently minor issues and outages related to Google that I find my programming ideals challenged.

In programming I am characteristically defined by my moralistic and idealistic upbringing, a good base education in software engineering, and frequent struggles with others’ esoteric programming methodologies. I thus strive to achieve solutions that are error free and that don’t cause disruption to the user.

This is not an easy road to take in modern programming environments. More often now we are reporting to a manager with knowledge limited to what he wants and when he wants, without any sense of the scope of the work he’s asking of you. It’s a constant battle for the time and resources to plan, to implement, and to test new features (hopefully in some variety of iterative process!)

Google, however, seem to have many minor issues with their software. Their flagship product – Google Web Search – fails an html validation with many more than a few errors. The translator fails in different areas. They have the Google Dance, coined to describe the phenomenon occurring due to the lack of synchronicity between their datacentres.

The issue that concerns me here is: nobody cares! There are murmurs and grumbles and gripes but for the most part people seem to accept it and move on with their lives. I was very inconvenienced by not having access to my work and personal email for a couple of days while Gmail refused me entry, and yet I’d still swear by it, and have no intention of discontinuing my use of the service.

Is it worth banging your head against your boss’ brick wall? Do you really need to tear your hair out on behalf of your less meticulous colleagues?

Perhaps, against everything your heart tells you, the answer is:

No.

Sure, it matches joe.blogs@example.com, or joe-blogs@example.com… But how about joe.blogs+work@example.com, or joe.blogs+support@example.com, or e=mc^2@example.com, or many other valid (albeit uncommon) email address varieties?

Email address validation and storage is a rarely considered but often encountered  concept on the web.  Many developers thoughtlessly implement validations that prevent legitimate email addresses being entered into a membership, support form, or being subscribed to a newsletter.

The most common barriers I’ve encountered are length limitations, domain black lists, or imitation standards compliance.

Length Limitations

One of the implementations of this blunder that I’ve come across is database field lengths. Arbitrary lengths are painfully common.  Next time you’re designing database and think to yourself “100 characters seems long enough” please stop, and ask yourself why you’re imposing a length limitation. And why 100?

• By old standards (RFC822) an email address could be up to 320 characters long.  That’s 64 (local user) + 1 (”@”) + 255 (domain).
• And by new standards (RFC 2822) up to 992.  That’s 1000 – 6 (”From: “) – 2 (\r\n).

The other reason email address lengths are often limited is more forgivable as it is conceivably the result of migrating from a specifically chosen login username to using an email address as a login.

Domain Black Lists

Spam is now an accepted inconvenience. But blocking @hotmail.com, or @gmail.com email addressed from using your support form is a misguided defense mechanism. Amongst the proportionally few spam email addresses with each provider are many legitimate users. Don’t punish them for your site’s popularity in a spam network. There are a variety of more effective anti-spam techniques you can implement.

Standards Compliance

This is my second most hated web development faux pas. One that even MSDN .NET documentation has screwed up for 7 years. Disallowing characters like +, %, *, $. At first glance a developer might see these as harmful, but such a developer would be amateur in thinking so. In any syntax where a character might be considered something other than it’s literal meaning an escape sequence is available. For example + and % are special characters in a url, but a thorough developer should encode them to %2B and %25 respectively.

I recommend the limit to your email validation to checking for the “@” character, and testing the domain part for a “.” character. This will ensure your users have at least attempted to enter an email address. The rest will be resolved in what experienced developers say is a significant part of any email validation:  sending an email. Here you may find such an address as e=mc^2@example.com is valid, while  john@example.com may not exist and thus be invalid.

Monday through Friday we rise with the sun and for a brief period divide our time equally between grooming, travel, and a daily attempt at caffine absorbtion.  Thus far a fairly typical beginning for much of the corporate population.

From there a full third of our day – half of the awake portion – is slightly deviated from the managerial or marketing type.  We spend a little more time at our desk and a little less at the water cooler.  When fielding an enquiry we are quick with the verbosity but lacking in circumlocution.  We’ve answered the question, but they still look at us quizzically! WTF?

It’s Friday.  Tradition says we are released of many of the bonds of  office protocol to join our peers in social splendour.  Do we accept?  We’ll come down soon, but we should really finish debugging this latest iteration and commit it to the repository…  19:00!?  Already?  Oh well, perhaps next week.

Until now we’re just regular every day corporate I.T. people.   But when Saturday night comes around and we’re staying in instead of heading to town; gaming instead of drinking; chatting instead of socialising…  have we gone too far?  Does this transcend conscientious career involvement?  Have we now become a shut in?  Have we got…

The Geek?

Welcome to the beginnings of my geek philosophising.