ID cards consultation response

January 29th, 2003

The UK Government recently undertook a consultation on “entitlement” cards – another term for identity cards. Whilst I’m very aware of the issues of identity fraud and other problems which ID card proposals purport to reduce, I have misgivings about whether they will actually help, and serious concerns over personal privacy implications.

My response, submitted to the Home Office, is below:

I am aware of the Government’s consultation on the possibility of introducing some kind of identity or “entitlement” card to the UK.

For the purposes of aggregation of for/against responses, I am against such a move.

Nevertheless, I would like to provide some more constructive and granular feedback than a simple yes/no response. Whilst resources limit the time I am able to devote to this topic, and therefore this response is less substantial than would be ideal, I would like to make the following observations which cover a number of points raised in the consultation:

  1. The potential for abuse of such a system is worrying. Whilst I have no doubt that the strict security procedures and processes mentioned in the consultation would be implemented, the practical reality is that centralising such a large amount of data, and introducing complex links with a variety of services employing a large number of people creates a substantial risk of abuse, not only by those involved in administering and using such a system, but by police and other bodies. In particular, when combined with recent legislation such as the Regulation of Investigatory Powers Act, I can only conclude that such a system will open up new possibilities for widespread intrusion of privacy, albeit by a perhaps limited number of people. As an engineer by training and someone involved heavily in IT and database systems, I certainly appreciate the elegance and efficiency which centralised and rationalised data storage can bring, but in public systems (such as that which would be required for an identity card), the technological idealism and search for efficient delivery of services has to be balanced against the privacy and other risks to society. In this case, I am of the opinion that a system of the kind proposed may very well dangerously undermine some of the inherent safeguards in a somewhat decentralised system; primarily that the administrative burden to correlate disparate data naturally limits the potential scale of widespread surveillance and/or abuse of private information.
  2. Whilst acknowledging that there is evidence that “identity fraud” is on the increase, I am not convinced that an identity card scheme will help to significantly reduce the incidence of such fraud. Whilst it may provide some benefits, I feel these may be offset by the fact that a universal identity card will provide a “high value” target for fraudsters. History shows that the higher the potential gains from forgeries and suchlike, the more resources that potential fraudsters will invest in circumventing the security provided by a system. Although a single centralised database certainly provides some benefits in this respect, only with a compulsory card and the introduction of biometric data would there be, I believe, a significant increase in the difficulty of committing identity fraud – but I do not believe that a system encompassing these features which will be acceptable to members of society at large is likely to be available in the foreseeable future.
  3. Similarly, I am not convinced of the implicit assumption in the consultation that an identity card will necessarily reduce the incidence of illegal immigration or work. A “black market” for illegal workers is likely to always exist.
  4. As correctly identified in the consultation, the risks involved in such a large-scale IT project would be significant. Past evidence of very large public/private sector IT projects shows that such projects tend to be under-estimated and may spiral out of control. With costs already estimated at £1.5bn, this is by all means an extremely large project, and I would voice a significant concern that the true end cost in purely financial terms may be much higher.
  5. If it were to be decided that introduction of an identity card was mandated, I would strongly prefer a “voluntary” rather than “compulsory” card (as defined in the consultation).
  6. The concepts discussed in the paper seem to follow very much “traditional” thinking on identity cards, whereas perhaps what is required here is some fresh thinking and new concepts. For example, whilst I don’t offer this by any means as a proposal (simply “food for thought”), how about a large-scale *decentralised* system, the fundamental concept of which would follow the lines of the PKI (public key infrastructure) trust/identity assurance system in use on parts of the Internet and other networks? The building of a nationwide, offline, optional, decentralised yet secure system where ‘networks’ or ‘webs’ of trust could be created would certainly be without precedent in the world and might easily be dismissed as “out of the question”, but perhaps in fact this is the kind of system which, with suitable planning (the enormity of which I do not underestimate) might actually enable some of the goals sought by an identity card system to be achieved, without introducing the centralisation and possibilities for abuse that “traditional” identity card systems may bring.
  7. I sincerely hope that you will take account of these views/opinions, and find them useful as part of the consultation process.

Tim Jackson

Draft Policy on the Use of Open Source Software (OSS) in UK Government Response

March 10th, 2002

I recently wrote the following response to the Government’s consultation on the draft policy on the use of open source software:

With regard to the Public Consultation Draft on Open Source Software in Government, I have the following observations and comments to make:

  1. The overall spirit of the Draft (and the QinetiQ report on which it is based), is to be commended. Open source software offers real advantages to society at large and any recognition by the Government, however guarded (as in this report) is to be welcomed.
  2. The definition of OSS within the Public Consultation is not consistent with the Open Source Initiative’s definition at http://www.opensource.org/ . I propose that the OSI definition is used.
  3. Looking at the specific policies outlined by the report, there is potential for a conflict between different criteria laid out in the policies relating to the choice of software. One the one hand, value for money is cited as the basis on which contracts will be awarded. On the other hand, it is stated that UK Government will “seek” to avoid lock-in to proprietary IT products and technologies. However, it is crucial that it is made clear that “value for money” considerations must extend far beyond the superficial and easily-manipulated figures provided by vendors for initial outlay and/or TCO. It is quite possible (in fact, likely) that closed-source vendors will offer solutions which may at first glance appear to offer better value for money as compared to competing OSS alternatives. However, the long term impact of choosing a closed-source solution may be onerous:
    • There may well be considerable future upgrade costs (which may in turn be unavoidable in order to maintain interoperability with other products, organisations or other entities).
    • There may be ‘lock-in’ to proprietary file formats which in turn will mean the Government is forced to purchase other closed-source solutions in order to interoperate, and this effect can easily permeate an entire organisation, creating wide-scale lock-in and very high medium to long term costs.
    • Upgrades or modifications to the software will generally have to be made by the vendor, rather than allowing other companies to bid for such work. A similar argument applies to the provision of support for the software – whilst third parties do sometimes provide support options for closed-source software, the vendor inherently has an advantage over the third parties.

    Furthermore, point 4 states that “UK Government will obtain full rights to bespoke software code…wherever this achieves value for money”. The ‘value for money’ qualification in this policy must be examined carefully in the light of the points raised above. Once again, it may be initially cheaper to choose a closed-source solution without rights to the code but this will almost certainly force vendor lock-in, which may cost more in the long term.

    In summary, if OSS and closed source software are to be compared fairly on a value for money basis, it is crucial that “value for money” should be assessed by an unbiased and independent party and should be calculated as a total cost of ownership over the anticipated lifetime of the product, including all secondary effects on future purchases as discussed above.

  4. Point 2 (relating to interoperability) cannot be overstated. Even if it were to be decided that in a particular situation, a closed source solution should be chosen, it is critical that the solution should not only support completely open and documented standards for data interchange but use them by default. This will avoid lock-in to proprietary formats which in turn will allow uninhibited future interoperability with other software (OSS or otherwise) and ensure that the product may, optionally, be replaced with an alternative solution from another vendor (again, OSS or otherwise) if it is deemed appropriate at some point in the future. A specific reference to the e-GIF may be appropriate here.
  5. I believe that point 5 (using OSS as the default exploitation route for Government funded R&D) should be stated more strongly. OSS should, unequivocally, be the default exploitation route for Government-funded R&D. If society at large is funding software research via central government, then the results of such research should be made available to society in the form of OSS.There are undoubtedly issues to be resolved in certain cases should such a policy be chosen, but these should not deter the Government from implementing such a policy. For example, in the current age of aggressive and often predatory intellectual property rights assertion by large corporations, jointly-funded projects may potentially be threatened by commercial co-funders wishing to aggressively assert IP rights. Whilst an equitable and proportional assignation of IP rights is of course necessary, any joint-funding agreements should, by default, be written to ensure that software resulting from said jointly-funded projects (or at least a fair proportion thereof) is made available as OSS.
  6. There is no stated policy on software patents, yet software/logic patents threaten OSS and therefore impact on this policy. Hence, alongside this policy on the use of OSS, there should be a clear and unequivocal policy statement on software patents, which should state the Government’s support for Article 52(2) (http://www.european-patent-office.org/legal/epc/e/ar52.html) of the European Patent Convention forbidding patents on computer programs. This restriction is currently being unilaterally disregarded by the European Patent Office as well as the UK Patent Office and UK courts (see http://www.patent.gov.uk/patent/notices/practice/computer.htm) – a problem recognised by a recent European Commission Directive on patent harmonisation (http://europa.eu.int/comm/internal_market/en/indprop/com02-92en.pdf). In conjunction with this, the Government needs to ensure that the aforementioned harmonisation resolves any uncertainty in favour of a clear ban on software/logic patents, including guidance on the possible conflict with the “all fields of technology” aspect of TRIPS Article 27(1).
  7. The ‘Justification’ section sums up the spirit of the policies well.

In summary, this Draft contains a generally well-written set of policies which could benefit from some expansion and qualification but which otherwise provide a fair and balanced framework for the use of OSS within Government.

Tim Jackson