For this particular post, I would like to share a white paper I recently came across summarizing a major research on the security of various types of software from off the shelf to custom built applications either by in house or by 3rd party developers.

As a software architect, looking back from my own experience over 20 years, I can easily agree with the results in this paper.  While it's foolish to think any software is 100% secure, it's undeniably true, aside from financial sector, business software is many times built with minimal focus on security.  In fact I would go as far and add, the levels of security obtained in the software is many times directly related to the level of experience the developer or team involved has.

In a room of 3 developers, with 1, 5, and 10 years of experience each, each would claim to have developed good and secure software based on the scope of their knowledge at the time.  All three can develop a sound solution meeting the functional requirements from the perspective of business or product owner.  However, as with any practiced discipline, the developer with 10 years of experience will usually build some additional safe guards for security or at a minimum is aware of certain of advanced topics such as code signing, etc. where such is unbeknownst to the less experienced developers.  Consequently the level of security in each is starkly different and is not easily measurable without explicit validation.

How do we apply metrics and quantify the level of security?  A business owner, unaware of programming details, is not able to measure this. A manager similarly, would be primarily concerned about timely delivery of functional aspects over any security needs which may delay the actual deliverable. Furthermore as the paper mentions, less than 20% "of organizations surveyed view security as the most important criterion when developing custom applications internally or when having customer software developed by third parties".

As a result, a concerted effort must ensue for education on secure development. Similarly a concerted effort must ensue to adopt patterns for security validation much like we have validation for functional requirements.  Some can be automated while some require human validation similar to automated unit tests and manual human tests of functional aspects in software.

In this day and age, its abundantly clear the software we write for the web is directly exposed to thousands and even local software running on computers or devices, is indirectly accessible by just as many -- security should be at the forefront moving forward.

Here is the white paper, which although shocking, I vouch for it's factual findings and is a worth while read for anyone in the business delivering quality secure software. 

ISC_The Need for Improved Software Quality_0.pdf (1.90 mb)

Quick Start

Details of how this works

I had a few Apple gift cards laying around and now using apple's Touch ID more often, I wanted to place these into Passbook for safe keeping and easier access. So how do we go about adding Apple gift cards to Passbook?

First, the simplest way to add a gift card to passbook is tapping the "Add to Passbook" button when receiving a gift card over email.  It looks something like this.

However, what if you already have a physical gift card and want to add this one to Passbook?  It turns out it's not too easy or straight forward.  Some people recommend downloading the Gyft iPhone app which allows you to import many gift cards from many merchants, however I'm a little skeptical of adding them to an app from a 3rd party other than Apple.  This app, and others similar to it, require you to enter all the confidential information from the gift card into the app and transmit it over the internet to their servers.  Although I'm pretty sure these are legit applications, I still had concerns over the security of my information.  Are the connections from the app to their cloud servers secure?  How secure are the servers themselves, etc.

So I then started to investigate the URL apple generates for "Add to Passbook" button.  Part of the URL includes the card number, but the remainder of the URL seems to be some unrecognizable encoded string.  Not relenting, after some research over the web, I discovered Apple has a specific URL they use to add Apple store gift cards to Passbook.  Since this URL is hosted by apple over a secure SSL connection, I feel quite comfortable using it to add my gift cards to passbook.  The url is:

https://storepass.apple.com/pc/v1/card/9999999999999/AAAAAAAAAAAA

where 9999... represents the card number and AAAA... represents the PIN of the card.

When I enter this URL into Safari on the iPhone, Safari reports it as an invalid card even for a valid one. The Passbook app however expects to scan a QR code to add cards, so I then searched online for a free QR code generator and came across this open source javascript project on github¹ which generates a QR code on the clients browser with JavaScript.  After reviewing the code to make sure there was no transfer of information, I used it to generate a QR code for the URL above replacing the 9999... and AAAA... with the numbers on the back of one of the Apple gift cards.  Once the QR code was generated, I then used the Passbook app to scan this code successfully adding my gift cards to passbook as shown.

I added all of my remaining cards with out issue.

I'm now embedding the generator for anyone to use as the wish here. This is pure javascript running on your browser and no information is delivered from your browser elsewhere.  Intact, the QR code changes in real time as you enter digits or letters. Simply enter your gift card number, pin number and then scan the generated QR code with passbook to add it to your passbook.

1.  http://davidshimjs.github.io/qrcodejs/

I came across some dialog where adjustment to daylight savings time was being applied manually in SQL Server stored procedures or functions to calculate the appropriate timezone shift (e.g. sometimes -5 for EST and sometimes -4).  I figured it can be done automatically, so I did some research on the definition for Day Light Savings time and came across two rules:

The old rule states:

Starts on the first Sunday of April at 2am and ends on the Last Sunday of October at 2am.

Comparing the results I realized something was off when compared to my current computer clock so I rechecked and found the revised rule enacted a few years ago:

The new rule states:

Starts on the second Sunday of March at 2am and ends on the First Sunday of November at 2am.

Over the fall quarter of 2012, we created the Bank Failures app for iOS.  I thank a colleague of mine for the detailed graphics and CSV parsing library we ended up using extensively for this and other apps. The idea is very simple -- banks have been failing at a very fast pace since 2008 and there is no easy way to access this information in an organized way to search or simply filter this data by year or by state.

Since we were applying techniques in iOS development, we decided to leverage this need while at the same time applying advanced UI techniques in iOS such as UITableView among others. A recently blog covers some interesting details with UITableView's.

The following are some screenshots of the app as submitted to the Apple App Store.  In a future blog update, I will decompose the entire application from the nightly process which pulls bank data from us government web sites to the filtering, tab views, etc.

xCode allows for multiple convenient ways for configuring the UITableView cells.  Using one of default custom configurations, specifying it in storyboard as a prototype, specifying it in a nib file which is then reused, and simply creating it in code directly.  While developing an app which makes use of the UITableView, I came across an interesting dilemma where I wanted the flexibility of using xCode's UI to configure it however I wanted to avoid certain issues each approach carries as described below.

One approach is to define each UITableViewCell as a prototype of each UITableView directly in storyboard as shown below,

however if there are going to be multiple UITableViews displaying cells in a similar fashion, the inclination is to configure them repeatedly in each UITableView.  This is very repetitious and may even lead to inconsistencies if one is not careful and generally is considered bad programming practice similar to copying a pasting an entire method just to make one small modification within.  One can improve upon this approach by inheriting a common base UITableView class where the configuration is specified in code, however this defeats the flexibility of using xCode's UI to custom configure the UITableViewCell's various sub views.

Another approach is defining the UITableViewCell in a separate nib / xib file, you can then register the nib and reference the UITableViewCell for reuse accordingly from any UITableView controller.  This method retains the configurability of the UITableViewCell via the xCode interface as shown below.

When reusing the UITableView cell in this fashion however, most online examples indicate to register the nib file for reuse and then dequeue as usual to populate the data for each individual cell.  The problem here is, the UITableView's rowHight property is not updated automatically as it is when one specifies the UITableViewCell as a prototype and at run time, you may see something like this:

Many online blogs emphasize the height should be specified as part of the cell construction while executing with the cellForRowAtIndexPath method within the UITableViewController.  The problem I have with this solution is quite frankly, even though perhaps only 10 or actual cells will be constructed and then reused, this code is repeated unnecessarily for those 10 or so times.

The easier route is simply to specify a fixed height in the nib file, say 60 and then specifying the same 60 points in the UITableView's rowHeight property as shown in both images below.

 This will produce the balanced height we are seeking as shown below:

While this has improvements on reuse as we will have consistently looking UITableViewCell's throughout our various controllers and retains the ability to configured and edited via the xCode UI, it still has the ill effect of having to maintaing the rowHeight in two or more different places whenever the height changes and is not yet to my satisfaction of cleanliness.

Further research online reveal many blogs emphasizing the implementation of the heightForRowAtIndexPath method for the UITableViewController. This method is great when there are UITableViewCells with dynamically varying content which need varying height for each cell, however this is not the case here. The problem with this approach continues to be the repeated calls for a UITableViewCell which doesn't vary in height.  Furthermore, in the various examples I found not only is the height specified repeatedly, but registration of nib is repeated as well and some additional lines of code which could also be avoided.

The Solution:

Since in this particular example, the UITableViewCell height will remain the same across all sections and rows and UITableViews, it makes sense to programmatically tell the UITableView it's rowHeight much like we would via the xCode UI, however do so once and be done with it.  The value should also be extracted programmatically from the UITableViewCell residing in the nib / xib file so if the height is ever changed in the future via the design tools, the UITableView is automatically adjusted accordingly without any further intervention in the code.

To accomplish this, the logical place to put such code would be in the UiTableViewController's viewDidLoad method as this code is executed once regardless of the number of rows to rendered.  In this method, we simply load the nib by name, register this nib with the UITableView, and then simply set the rowHeight of the UITableView to match the height of the first view in the nib which we already know is simply a UITableViewCell.

    UINib* nib = [UINibnibWithNibName:@"ADTableViewCell"bundle:nil];

    [self.tableViewregisterNib:nib forCellReuseIdentifier: [ADCustomCellIdentifier]];

    self.tableView.rowHeight = ((UITableViewCell*)[[nib instantiateWithOwner:selfoptions:nil] objectAtIndex:0]).bounds.size.height;

In the example code above, we additionally reference a predefined class method for the cell identifier we conveniently placed in the strongly typed class representing the UITableViewCell with [ADCustomCell Identifier].

Web sites have a simple way to tell search engines how to index their site.  This consists of a file called robots.txt the web site places on the root of their site specifying the rules on how the "robots" can come in a traverse their site.  It was first established in 1994 around the time when search engines were being born.

It recently resurfaced in the news not too long ago when Rupert Murdock was creating waves in the media about how search engines steal and reuse their content -- particularly their news and aggregating them such as news.google.com.  Google's shameless response, to Murdock's embarrassment too, was simply "place a robots.txt file and let us know not go there".  For the record, Murdock's news sites didn't do this and the story ended there.

Now with the Facebook IPO only a fews days away, I was curious to see the contents of facebook's robots.txt file.  In a nutshell, most search engines (explicitly) are told to not index many of the main pages like photos, feeds, etc. So here is Facebook collecting tons of information on people, pictures, preferences, etc. and yet google can't even touch it -- ouch.  That's like going to a fight with your best weapon -- just that you're weapon doesn't work.

You can see it here http://www.facebook.com/robots.txt

Google's plus.google.com robots file looks like this and can be viewed directly here plus.google.com/robots.txt

This is the latest update to the original cross multiplication application released a few weeks ago -- original posting here. 

Version 1.1 of the app allowed me to practice with threading as well as state.  The app has an interactive timer which is not intrusive by starting/stopping automatically.  Your best error-free scores are saved so you can challenge yourself to beat it over and over.

When deleting a file using FileInfo.Delete() method, the .NET framework sometimes throws an exception as shown below:

Yet, when you delete the file manually through explorer its removed fine from the filesystem.  At first I though this was a glitch of some type because the program runs with my login credentials much like the local logged in user credentials applies to windows explorer.  It turns out if the file is marked as ReadOnly it also throws this exception.  Changing the attributes prior to deleting will automatically resolve this problem.

An additional note, since this program was working with a directory where files were continually being created and removed, there was an additional observation with the File.CreationTime.  In very few cases when iterating through the files in the directory, the CreationTime would show a date time value of 1/1/1600 despite the file already existing.  I attribute this to simply a race condition where the FileInfo.CreationTime of my program gets to the file just before the actual creation date of the file is set by the operating system. This would need to be validated as I would expect the creation time of the file to be set in an atomic way along with the file creation.

Today I came to an interesting observation of public & private accessibility with regards to using the new keyword.

The scenario was exceedingly simple, almost too trivial to even write about but warrants a mention under the subtle but interesting observation as described below.  First lets set the stage.  The following program simply adds two items to a specialized list and then iterates over them to display them.  The output is shown.

Now, lets assume you are asked to sort the output and are limited to only working with the specialized collection and the Node objects exclusively.  So after some deliberation of what would be the optimal route from creating a SortableList (e.g. always sorted at the cost of a delayed insert) vs sort upon delivery, you go with the later and implement iComparable on the Node and decide to override the IEnumerable on the specialized list with the new keyword as shown.

The interesting observation here is the breakpoint inside the enumerator never hits.  Why? This stumped me for some time and was in denial as Visual Studio wasn't reporting any errors or warnings.  The keyword new is very powerful yet dangerous as it can be considered to bypass standard OOP principles and should be used sparingly because of these subtleties.  Visual studio's lack of warnings, in this particular case, was of no help also.

The problem resides in the function signature not matching the signature expected by iteration -- particularly the public accessibility.  As a result, you never actually hide the underlying one as expected. This is a very important observation and is the primary cause for the breakpoint not hitting.  As a seasoned developer, I was expecting the compiler to warn on the use of new with a matching underlying function name but doesn't actually hide and replace it -- solely because of accessibility. To emphasize this further, you can rename the function anything else and and the warning will popup indicating the use of new is not required as nothing is being hidden so naturally if reverted and it doesn't warn when compiled, one can easily and wrongly assume it was hiding the underlying method assuming the existing public accessibility too.

Just out of curiosity of what's going on in the internals, I used reflection to inspect the methods with and without the public attribute with the following code:

MethodInfo[] enumeratorMethods = typeof(MyList).GetMethods().Where(t => t.Name == "GetEnumerator").ToArray();

foreach (MethodInfo mi in enumeratorMethods )

    Console.WriteLine(String.Format("{0} - Public: {1} - Virtual: {2}", mi.Name, mi.IsPublic, mi.IsVirtual ));

 

I was writing an email about iPads and iPhones and found it amusing Microsoft decided to exclude them from their default spell checker despite their prominence in the market place and yet decided to include some of their product names despite their lack of prominence.