Virgin Blue - Sexist Policy

I travel virgin blue quite frequently, but today on my way home from a visit to Sydney, I ran foul of one of Virgin Blue's policies that I find to be overtly sexist.

I had boarded the plane, and was sitting in the very last row, in the isle seat. I was thinking I must have been extremely lucky when it appeared as though there was going to be no-one else sitting in my row. It meant I could get out my laptop and not have to worry about bumping elbows with the person next to me as I wrote a blog post I am currently working on. Just as they were closing the doors, one of the stewards came down the back with a young boy who looked about 8 years of age, and sat him in the window seat. Still good, the middle seat was still vacant, so I would still not be bumping elbows with anyone. It appeared as though the woman who was supposed to be sitting in the middle seat had not shown up. It was at this point the stewards asked the woman sitting in front of me to change to the middle seat between me and the child. When I looked quizically at the stewardess she revealed that "it is virgin blue policy to ensure that a male is not sitting next to an unaccompanied minor". I couldn't believe it!

I was not given any reason for the policy, I can only assume that with all the media hype around child abuses that Virgin Blue management feel that it is safest to treat all men as potential child molesters, and the obvious assumption, based on a 1920's understanding of gender, is that it is better to have a female sitting next to a child, because obviously a woman would never abuse a child.

I expressed my indignation to the stewards, not that it really bothered me who I sat next to on my hour and a half flight from Sydney to Melbourne, and told them I thought it was sexist. One of the male stewards agreed with me and encouraged me to file a complaint form which I did.

When all is said and done, it may seem like a silly little thing to complain about, and not something that I should get too upset about, but what bothers me is what it says about the kind of society we are becomming. What this kind of policy does is to make males feel uncomfortable around children. We are already at a point where the first thought when an adult male hugs or shows any kind of affection towards a child in public is one of suspicion. I fear that attitudes like this will feed into the already stark gender imbalance in our education system, and into other social activities involving children meaning that a generation of children will grow up not quite knowing how to have healthy relationships with adult males.

Defense in Depth at Tech Ed

Last week I attended Tech Ed Australia, and as usual at Tech Ed, I found it impossible to stick to one track, instead picking and choosing interesting bits and pieces from almost all of the tracks. One thing that I am starting to get realliy interested in is Security, particularly code security. One thing that I don't think a lot of developers a really aware of is that you can have the best infrastructure security money can buy, you can have fire walls, and DMZ's set up so tight that no un-authorized traffic can possibly get through, but it just takes one bad line of code to blow a whole so wide in your defenses that it can render these measures meaningless.

The buzz these days is on Defense in Depth, which roughly translated means having multiple layers of checks and safe guards so that if a bad line of code up stream lets an attack through, there is a high probability that code further down will pick it up and dispense with it appropriately. I attended a number of security seminars at Tech Ed, and I'd like to expound on a concept that I have have been using in my current role, and it was really good to hear it codified into three basic development pratices at Tech Ed.

 

The three pillars of this approach to code security are Constrain,  Reject and Sanitize, and I want to explain in this series of articles how these concepts fit in with day to day development, and how they can form part of a defense in depth approach to your products.

 

I'll start in this article by explaining what the three trems mean, I'll then go on and spend an entire article on each of these three concepts and explain how these can fit into the software development life cycle.

 

Constrain

At the root of almost all code level attacks is user input. SQL Injection exploits the single quote (') special character in the SQL language, Cross Site Scripting (XSS) exploits the web browsers propensity to want to render HTML tags. Generally speaking the developers of the system never intend the input to be in this format in the first place. The constraining of data should be done at the point where the user is entering the data into the system. This is commonly referred to as "white list" checking.

 

Reject

There are certain known common attack vectors that should be rejected out right. If you are accepting input from a web site comment field, and the user types in "<scrpt>...</script>" chances are you are not really going to want that users comment, and the safest thing to do is to reject it, and tell the user that the input was not acceptable. The rejection of suspect data can be done at multiple phases such as code layer boundaries, or even as an aspect of the way your system works. This is commonly referred to as "black list" checking.

 

Sanitize 

Sanitizing the user input is what I like to call the last line of defense. This is usually done just before user input is presented to the attack target (ie SQL Server in the case of SQL Injection, or the browser in the case of XSS). Sanitizing information is usually done by escaping potentially malicious data before presenting it. As an example, in the case of XSS where the browser is the attack target, a string such as <script>...</script> is rendered harmless if it is HTMLEncoded to &lt;script&gt;...&lt;/script&gt;.

 

Putting them all together

By now you may be able to see the idea of "defense in depth" starting to form. In the first place, we constrain, only allowing data that we expect to be entered. Secondly we reject any known attack vectors so even if we can't constrain every field on in our application (or a lax developer forgets to constrain), we can at least protected ourselves against known attack vectors, and finally if constraining and rejecting fail to pick up a potential attack vector, then sanitizing the output will render the attempted attack harmless.

Readify Developer Network Launched

An ambitious project by Readify is about to start up. the Readify Developer Network is a way of Readify staff being given the opportunity to learn from and present in front of their peers, and it is open to anyone who is interested.

I'll be speaking on the Ajax Control Toolkit in Melbourne on the 1st of November.