David Glance's Blog

Australia Medicare digital signatures using java and C#

David.Glance — Sat, 07 Mar 2009 14:47:00 GMT

So, the problem is how to sign a message using a personal certificate on Australia's Medicare iKey in a browser and being able to verify the signature in a web app. Well, it is more complicated than that but this was the basic problem to start with.

The signing part was relatively simple PKCS#11 using an applet example from Svetlin Nakov (http://www.nakov.com) - the iKey is a SafeNet one (Medicare use a smart card, the 2032, 3000 and 1000 (?) iKey) and comes with a PKCS#11 driver (dkck20.dll).

Note: I did find that the SHA1withRSA didn't work and I used MD5withRSA instead.

The issue was how to verify the signature in C#. I had the X509 public key from the iKey (or you can get it from the Healthcare Public Directory). Searching for how to initialise the RSA Cryptographic Provider from the X509 certificate took me forever until I hit the magic sequence of terms and it turned out to be surprisingly simple. In .Net 35 there is a class X509Certificate2 which can be initialised from the path name for the public key.

A property of the class, PublicKey.Key gives you an initialised RSACryptoServiceProvider which can then be used to verify the data (specifying MD5 as the hashing algorithm).

Disabling backspace in forms with Javascript

David.Glance — Thu, 01 Jan 2009 09:02:00 GMT

A constant usability issue has been users losing their data entry on forms by inadvertantly pressing the backspace button when the focus is not in a text box or other appropriate control. As very few users realise that backspace has another function in IE to go back a page, this then gets blamed on the web application as a bug. Of the solutions that are out there, the best I found was one posted here which is reproduced below. We use master pages and so it is just put in the master page.

I have seen some posts from over-zealous accessibility people claiming this is a bad thing - changing default browser behaviour. Since most people believe this default behaviour to be fundamentally broken in the case of web applications, I don't think this is a valid critiscism.

Here is the BLOCKED SCRIPT

Failed to Enable Constraints error in DataTables

David.Glance — Mon, 19 Nov 2007 05:13:00 GMT

This is an error I run into frequently and is frustrating because of course their is no indication of what constraint is being violated. So now I run through the three most frequent problems that will cause this:

Having a primary key specified on the DataTable where a query can potentially return duplicates. Sometimes duplicates are unavoidable and so removing the not helpful primary key will sort this one out.
Finding the columns that have been set to not allow nulls - again, this is sometimes unavoidable and so going through all of the columns and allowing nulls will fix this.
Exceeding the size of a column. This happens if you have created the DataTable and then for some reason alter the column size in the actual database table. The DataTable will not automatically update even if you alter the main query.

Occassionally I have found that nothing you do will get rid of the problem other than creating the DataTable and queries in a new DataSet (a tedious exercise).

Using multiple MasterPageFiles in an application

David.Glance — Mon, 19 Nov 2007 05:07:00 GMT

We have an application that we have 2 skins for reflecting the 2 customers of the application. When I went to using skins, I defeined the MasterPageFile in the web.config file rather than switching it programmatically in each page. Unfortunately, this meant that every time I wanted to view a page in Visual Studio 2005, I had to put the MasterPageFile statement back in the page - an extremely tedious problem. Since then, I have discovered that it is relatively easy to set the MasterPageFile in the Page_PreInit method which retains the statement in the aspx file making viewing in the designer still possible. I think this problem is sort of fixed in VS 2008 but switching it programmatically means one less thing that needs to be changed in the config file.

Security decisions – why are they so hard?

David.Glance — Sat, 28 Jul 2007 11:06:32 GMT

We are currently writing an internet-based application for use by doctors and health providers to exchange information. Because of this, security and privacy is obviously a concern (although if the laws around this in Australia were the only guide you may be forgiven for not thinking that!). This has lead to me looking at a number of different possible approaches to keeping the data sent between the users secure and private. The trade of course is quite a few of the other 'ilities like usability, flexibility, mobility, performability (I've always liked that one). Here were the choices with the pros and cons:

VPN vs SSL: the option of running everything over a VPN was ruled out because we wanted to include a large range of people in a large range of locations – VPNs just don't work in this setting.
Client certificates: remember the NBT (next big thing) – PKI? Good because we could have another level of identification – bad because of the overhead of managing certificates, people forgetting their passwords, management of installation or use of the certificates.
Encryption of data: Generally a good thing because even though the systems administrators could theoretically get access to the keys to un-encrypt, that is a step further than just casually seeing in–the-clear text of messages or data.
1. Public key via client certificates: good because the information is encrypted with the recipient's key – would be even better if this was done on the client – the difficulty is that the only real way of doing this is to use Active X which only works on IE (bad since we support Firefox as well). Bad because of (2) and browser dependencies. If it is done on the server, there is no advantage over symmetric encryption and the overheads are greater.
2. Symmetric encryption using a private key: good mostly – another level of protection – the main issue being where to store the key but that can be put on a smartcard or other off-box device.

In reality, the decision tree for using a particular variant for security is complicated and the path depends on context. This is probably why it is so difficult to come up with specific recommendations on what is necessary when it comes to security of medical records. The bottom line is that reasonable steps should be made to protect privacy and security of patient information but the advantages to patients of systems that facilitate accurate and timely sharing of information far outweigh the risks of breaches providing a base level of security including SSL, usernames and passwords and content encryption, is applied.

10 reasons why programming takes so long

David.Glance — Sun, 08 Jul 2007 15:30:00 GMT

[1] The context switch: you are constantly switching between tasks (especially if programming is only one of the jobs you do). Each time you come back to your programming task, you have to remember what you were doing, how you were doing it and what you actually intended to do at the end of it.

[2] The library/control/feature you are trying to use doesn't work as advertised: You then have to spend time trawling blogs, forums, and yes, even documentation, to try and find out what magic word you forgot to incant!

[3] You have forgotten how you did it before: the thing design patterns were supposed to fix (ha!) but each time you implement that particular trick feature, you have forgotten how you did and worse still, where you did it last so that you can copy it.

[4] You are coding with someone else on the same project: so why did they set up that table in that way???

[5] Procrastination: each time you do [1],[2], [3] (and possibly each of the others) you get side-tracked on the web reading the news or finding out how to do some unrelated feature.

[6] To do the feature you want to add, you have to change the way everything else works: yes, I know, this was what design (and yes, don't make me laugh, UML) was supposed to fix - but as they say, you don't know until you find out.

[7] Ajax: everything has to work like gmail.

[8] Visual Studio/Windows: when it decides it has had enough and simply stops working or forces your computer to arrive at the same conclusion.

[9] Boredom: you have had enough of this particular project and wished you were back doing open source where there were no deadlines and no users complaining.

[10] The rest of life: meetings, writing reports, and yes, a little r & r.

Delivering on IT - the abstraction of simplicity

David.Glance — Wed, 06 Jun 2007 15:17:00 GMT

I was wondering why IT was so hard to do well. Or at least, why so many organisations run into so many problems when dealing with their computing needs. The main thing that seems to paralyze everyone is making a decision. And the reason this is so hard? Like many things, it is because people can't abstract a problem and model it based on the fundamental properties of that problem. Instead, they over-complicate the task by looking only at the individual interconnected parts and then add unrealistic pre-conditions for good measure. This is why the principle of "deliver early and often" works so well. You can start off with a simplified version of the software and through early use and feedback, people get a much better idea of what it is they want, concentrating on the important elements - usually the abstracted core of the system. It also helps if this is also driven by the pragmatism of either small budgets or tight deadlines.

KISS (keep it simple, stupid), it seems, is a hard lesson to learn, one that has to be reinforced on a regular basis. Achieving simplicity is, as I have said, a product of being able to abstract effectively and then being able to implement a solution which is internally and externally consistent.

the startup lifecycle

David.Glance — Wed, 30 May 2007 14:30:00 GMT

You decide to start a company. You may even have a business plan, or you have taken the off-the-shelf approach of starting off as a service company with the hope of providing a product which is eventually going to sell in sufficient quantities that it will pay for further development, expansion etc. In the meantime, you are answering the phone, doing the sales, doing the hiring/firing, consultancy and even development. How long does this last? Usually as long as you are prepared to forgo having much of a life outside of it all. The chances of it working out? Not very high. But at least you tried, developed some software and kept some people employed for a while. That can't be a bad thing? And you never know...

Research-based Practice

David.Glance — Wed, 14 Mar 2007 04:16:00 GMT

Cross posted from myResearchSpace

I have recently been looking at issues around best practice in web design. Best practice is often encapsulated as the perceived wisdom of professionals which has become enshrined in the collective mythology of the profession. An example of this in web design is that "users will give up on a website if they have to click more than 3 times"; a hypothesis with no experimental basis and with at least anecdotal research evidence (http://www.uie.com/articles/three_click_rule/) suggesting that it is false (there is little correlation between the number of times a user clicks and a user's successful accomplishment of a task).

With a growing sense of frustration at not being able to establish the relative credibility of any of the advice that was been given on best practice in web design, I came across a book published by the US Department of Health and Human Services called Research-Based Web Design & Usabilty Guidelines which uses research findings as the basis for web design guidelines. Apart from being beautifully presented and freely accessible online, it is the methodology used to present the guidelines which is truly impressive. Each guideline within the book is given 2 scores. The first is one for 'Relative Importance' rated by a panel of 16 reviewers, half of which were usability specialists and half web designers. The second score is for 'Strength of Evidence' for each guideline, again rated by a panel of researchers, authors and designers on the basis of a 5 point metric.

I wonder if there are lessons to be learned from this in the application of presenting research in a thesis?

Anatomy of a Good Website

David.Glance — Wed, 28 Feb 2007 05:26:00 GMT

The University of Western Australia's website http://www.uwa.edu.au is constantly complained about. In the last user survey, 43% of staff expressed some dissatisfaction with the site. But the site does have lots of good parts to it and has been improving over the past few years as more people become aware of the importance of their web presence. And when compared to other university websites, is it really that different?

So what is it about the site that doesn't work for its users? Were the issues simply a reflection of a problem at a given point in time that has now been addressed as there are improvements of parts of the website occurring constantly? Probably not. The problems with the UWA website are systemic even though there are numbers of exemplars of good design, content, architecture and usefulness.

University websites exemplify a type of website that supports multiple "personas" or "role types" in its users. 15 year old school kids will rub shoulders with undergraduates and professors (both UWA and non-UWA) all utilising the website for different purposes. The most common way that websites have dealt with this is either to offer different navigation paths through the same content with or without superficial text around the links giving "user-appropriate" guidance. But it ends up being the same content that they end up with and that may, or may not, be appropriate.

Looking at the problems of the UWA website and abstracting those to guiding principles for good website design, some general characteristics of good website design has emerged. Although these have resulted in a review of a University website, the principles are general. Applied to a great site like the BBC, all of the principles apply.

A good website is one that is...

[1] COHERENT

Different areas of a website serving the same function to look function in the same way i.e. if you visit the School of Plant Biology's website, it should be structurally similar to the School of Humanities' website. Staff lists should be in the same place with the same details.

[2] CURRENT

There is no point in putting information on the web if it is out-of-date or inaccurate. Maintaining the web is a daily activity.

[3] USEFUL

The content serves some purpose. It is useful, consistent, discoverable, well written, customised to the reader's persona and meet some need even if this is simply entertainment.

[4] PERSONALISED

The experience of the website is tailored to the individual visiting it. The BBC website for example configures the news based on whether you want an International, UK or other perspective. External visitors to the site shouldn't have to navigate or see pages or links that they have no interest or access to.

[5] DATA-DRIVEN

Wherever possible, content on the web should be driven out of structured data stored in databases rather than "hard-coded" into web pages. Examples of data-driven web content would be staff lists, research profiles (publications, grants, and research interests), unit, and course information.

[6] INTERACTIVE

People interact with a website – the model should be push as well as pull. The website should allow comments, blogs, feeds.

[7] ATTRACTIVE

The design should be coherent, attractive, customised, accessible, and follow best-practice design guidelines. Current design stresses simplicity with a content focus.

[8] RESPONSIVE

The website should be responsive and make allowance for users with different data access speeds (this can be built into the personalised aspects of the site).