Personal Internet Security: follow-up report

July 8th, 2008 at 13:05 UTC by Richard Clayton

The House of Lords Science and Technology Committee have just completed a follow-up inquiry into “Personal Internet Security”, and their report is published here. Once again I have acted as their specialist adviser, and once again I’m under no obligation to endorse the Committee’s conclusions — but they have once again produced a useful report with sound conclusions, so I’m very happy to promote it!

Their initial report last summer, which I blogged about at the time, was — almost entirely — rejected by the Government last autumn (blog article here).

The Committee decided that in the light of the Government’s antipathy they would hold a rapid follow-up inquiry to establish whether their conclusions were sound or whether the Government was right to turn them down, and indeed, given the speed of change on the Internet, whether their recommendations were still timely.

The written responses broadly endorsed the Committee’s recommendations, with the main areas of controversy being liability for software vendors, making the banks statutorily responsible for phishing/skimming fraud, and how such fraud should be reported.

There was one oral session where, to everyone’s surprise, two Government ministers turned up and were extremely conciliatory. Baroness Vadera (BERR) said that the report “was somewhat more interesting than our response” and Vernon Coaker (Home Office) apologised to the Committee “if they felt that our response was overdefensive” adding “the report that was produced by this Committee a few months ago now has actually helped drive the agenda forward and certainly the resubmission of evidence and the re-thinking that that has caused has also helped with respect to that. So may I apologise to all of you; it is no disrespect to the Committee or to any of the members.

I got the impression that the ministers were more impressed with the Committee’s report than were the civil servants who had drafted the Government’s previous formal response. Just maybe, some of my comments made a difference?

Given this volte face, the Committee’s follow-up report is also conciliatory, whilst recognising that the new approach is very much in the “jam tomorrow” category — we will all have to wait to see if they deliver.

The report is still in favour of software vendor liability as a long term strategy to improving software security, and on a security breach notification law the report says “we hold to our view that data security breach notification legislation would have the twin impacts of increasing incentives on businesses to avoid data loss, and should a breach occur, giving individuals timely information so that they can reduce the risk to themselves“. The headlines have been about the data lost by the Government, but recent figures from the ICO show that private industry is doing pretty badly as well.

The report also revisits the recommendations relating to banking, reiterating the committee’s view that “the liability of banks for losses incurred by electronic fraud should be underpinned by legislation rather than by the Banking Code“. The reasoning is simple, the banks choose the security mechanisms and how much effort they put into detecting patterns of fraud, so they should stand the losses if these systems fail. Holding individuals liable for succumbing to ever more sophisticated attacks is neither fair, nor economically efficient. The Committee also remained concerned that where fraud does take place, reports are made to the banks, who then choose whether or not to forward them to the police. They describe this approach as “wholly unsatisfactory and that it risks undermining public trust in the police and the Internet“.

This is quite a short report, a mere 36 paragraphs, but comes bundled with the responses received, all of which from Ross Anderson and Nicholas Bohm, through to the Metropolitan Police and Symantec are well worth reading to understand more about a complex problem, yet one where we’re beginning to see the first glimmers of consensus as to how best to move forward.

Entry filed under: News coverage, Politics, Security economics

15 comments Add your own

  • 1. Benjamin Wright  |  July 8th, 2008 at 17:32 UTC

    Richard: I fear that software vendor liability will curb innovation and the rapid delivery of new software features I love. What do you think? –Ben http://hack-igations.blogspot.com/2008/01/liability-for-publishing-insecure.html

  • 2. Richard Clayton  |  July 8th, 2008 at 18:40 UTC

    @Benjamin

    Hardly the post on which to argue the complexities of software vendor liability… but the bottom line is that you’re having to spend extra money on “protection” products because vendors don’t need to worry about pesky inconveniences like “security” or “testing” or even “working” before they ship.

    The Committee actually recommended taking the first step of considering negligence: and it is surely negligent to ship a product today with a stack overflow in it. It suggests a lack of training, a lack of knowledge of available tools, or just a lack of concern for the consequences.

    We don’t usually go around decrying the effects on recipe innovation or rapid delivery that come from our insistence that all food vendors follow hygiene legislation — why should software vendors be uniquely insulated from the consequences when their products turn out to do damage?

  • 3. Alex  |  July 8th, 2008 at 21:21 UTC

    The situation with food is hardly the same. Food should all be held to the same standard, no matter what kind it is, because the safety risk is the same for all food for human consumption. It’s far from obvious how vendor liability for software would work.

    At the moment every image viewer or whatever has to be considered trusted because you might use it to view content from the net, but arguably the OS should ensure that just viewing an image can’t cause a security problem even if the viewer contains a security hole. Who is at fault, the OS vendor or the viewer vendor? And that’s without considering open source.

  • 4. alarmed  |  July 8th, 2008 at 23:47 UTC

    I appreciate you don’t want to get into this but…

    “it is surely negligent to ship a product today with a stack overflow in it”.

    A straight stack overflow perhaps but one buried under an API where a bounds check can be avoided by deliberately crafted malicious input? We’d hardly hold car manufacturers liable for a snipped brake cable or other such deliberate malicious interference with their product.

  • 5. j  |  July 20th, 2008 at 20:27 UTC

    The questions surrounding software vendor liability should deserve a wider debate. Here I agree with the report. As it also suggests, this should be done at the European or international level.

    Yet, shouldn’t the open source be taken seriously in the current situation? Who is even liable in these settings? If I together with a small academic community write a new product with nasty stack overflow in it, will we be liable and to whom? Or will these so-called “vendors” take the burden? Vendors that have possibly no commercial assets?

  • 6. k  |  July 21st, 2008 at 00:48 UTC

    j,

    With apologies to both our host, and to Mr Schneier, these vendor liability schemes look designed to drive free software underground.

    I can kinda understand the desire to knock out Theo DeRaadt and OpenBSD. But what on earth do these people have against the FreeBSD project?

    And why is Mr Clayton proposing to kill off the Mozilla project?

    No matter how theoretically attractive it might seem, vendor liability isn’t going to improve security in the real world. It’ll just further cement Microsoft’s dominance. And I find it hard to believe that Mr Clayton and Mr Schneier don’t know that.

  • 7. P  |  July 22nd, 2008 at 11:19 UTC

    @k,

    There is no Mr Clayton.

    But you have to look off this blog for the record-breaker.
    http://news.bbc.co.uk/1/hi/england/cambridgeshire/7510565.stm

  • 8. j  |  July 25th, 2008 at 19:10 UTC

    Excuse me. Doctor Clayton has even less of an excuse for being ignorant then, doesn’t he?

  • 9. Richard Clayton  |  July 25th, 2008 at 19:21 UTC

    I have no interest in seeing free software “driven underground”, but I do wish to see an end to incompetently written software containing glaring security holes, where the author is clearly unfamiliar with modern software development technology. Such software, whether written “for free” or as a commercial product is totally undesirable. In other areas we don’t cut a huge amount of slack for “free” goods — if your burger flipping stand gives patrons salmonella poisoning then the environmental health people aren’t going to be over-concerned about quite how much you’re charging.

    In practice, a fair amount of free software reaches the public via aggregators such as RedHat or via organisations such as the Apache Foundation. They would be the ones who would test the software, assure themselves of its quality and then stand behind it in the marketplace.

    oh… and do try and be reasonably polite, or your comments will just disappear and your point of view will be unseen.

  • 10. m  |  July 27th, 2008 at 16:28 UTC

    Dr Clayton,

    Your considered reply is appreciated.

    With your powerful gift for colorful analogy, I’m confident that you’ll command very admirable fees as a litigation consultant and expert witness. I venture to expect that you’ll earn a quite respectable fortune.

    Incidentally, I have received advice that, under the common law, unilateral license or leave shall be revoked upon actual notice. Please cease and desist forthwith any and all public display of posts deemed objectionable.

    Regards,

  • 11. j  |  July 28th, 2008 at 07:37 UTC

    @Clayton:

    I am still curious about liability of individual open source developers. If I am the sole distributor of software developed by me alone, will I face, say, civil prosecution in case of fatal security issues in the software distributed directly by me?

    Does this also mean that the clear-text legalities in all major open source licenses are to be interfered? A quote from the BSD-style license:

    THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
    OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
    HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
    LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
    OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
    SUCH DAMAGE.

    Good luck reversing something that is so clearly expressed by the copyright holder.

  • 12. Richard Clayton  |  July 28th, 2008 at 08:25 UTC

    Under English law it is already the case that some exclusions are unlawful — and hence without effect. The key exanple is that you cannot exclude responsibility for negligence that results in a death. You will often see this brought out as a special term (lest the court cross out more of the (lack of) warranty when removing the unlawful section).

    The bottom line is that warranties such as the one above can be made void by statute — and that is what has been done in almost every other area (certaiinly when individual consumers are involved).

    Arguing that software is uniquely special has little intellectual merit when you consider the complexity of modern civil engineering projects or transport systems. Arguing that the industry cannot run on exactly the same lines as now is self-evident and illuminates little …

    …but as I keep trying to indicate, this wasn’t a detailed post setting out all of these arguments — it was drawing attention to the latest Lords Science & Technolgy Committee Inquiry report; which considered tentative steps in this area as only one small part of the issue — and not one that can be expected to bring about change in anything other than the long term.

  • 13. j  |  July 28th, 2008 at 09:31 UTC

    @Clayton:

    I agree that this is not the right place nor the right time to argue for or against software liability, but given that you were a specialist adviser of the report, I would hope and enjoy your public clarifications to what you are promoting.

    I am unfamiliar with the legal details, but I am curious if such warranties can be nullified in cases (read: open source software distributed from *any* particular country) where there is no clear evidence of any kind of contract being made between the author and/or distributer and the *potential* user (i.e. not a consumer) of the software.

    How about design of software? Should IETF be held responsible for the recent flaws in the DNS protocol itself? IEEE for WEP?

    All in all: advocating liability for one’s negligence for issues unknown at the moment of writing software feels like a disastrous route for the whole software development, even more so when the advocates seem to downplay public debate (yet urging the government to take the recommendation forward).

  • 14. Surreptitious Evil  |  July 29th, 2008 at 16:10 UTC

    I think that Bruce Schneier’s point in his 28th July blog post is a sensible way to look at it. If we (or uk.gov) merely make it illegal to exclude otherwise lawful liability claims in consumer contracts (or make it clear that the Unfair Contract Terms and Conditions Act applies to software sales) then open source software would be partially protected as there would be no contract giving the user a claim.

    Hence there would need to be a claim of negligence, requiring a much higher degree of proof.

    I would note re “j”’s point @13 that the DNS flaw is not in the DNS protocol – it is in most DNS implementations (i.e. everything I’ve heard about except djbdns) – that is that the source port for the DNS response is predictable, hence a fraudulent UDP packet is trivially constructed, The IEEE 802.11 committee would be similarly insulated as, I would expect, competent WEP implementers (that they implemented, correctly, a flawed but better than anything else we had at the time, protocol is unlikely to be actionable in the UK, at least. After SCO vs everyone, I refuse to speculate on the inanities of the US civil justice system).

  • 15. athena  |  July 29th, 2008 at 22:27 UTC

    @j

    I certainly am of the opinion that this is neither the time nor the place for any involved discussion of the ins-and-outs of California law. Nonetheless, the drafters of the University of Calfornia Regents\’ license (original BSD license) almost certainly had California law in mind. Thus —if I may interject— privity of contract is immaterial to a tort complaint that bodily injury was proximately caused by a negligently designed product.

    Caveat: These general remarks are not intended to be applicable to any specific circumstances. You should obtain legal advice from professionals duly licensed in the jurisdictions to which you may be subject.

    @Clayton

    With respect to the University of California Regents\’ license, may I be assured that you have not recommended to the House of Lords\’ committee that they should alter or abolish the present status of the State of California in Her Britannic Majesty\’s English courts? In other words, some software “aggregators” will still escape liability.

    But that leads me to questions about your designs on technology licensed by institutes within the Commonwealth of Massachusetts, at Cambridge, near Boston, and elsewhere.

    Despite the present interest in comity amongst Her Britannic Majesty\’s English courts and the courts of the United States, certain unique features of law and constitution seem to make it rather doubtful that US courts would enforce foreign judgments against US persons, or against assets found within the US, for publication of non-libelous expressive materials.

    The software economy is a truly global one. Trade disputes over software liability could cause severe upset.

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Subscribe to the comments via RSS Feed


Calendar

July 2008
M T W T F S S
« Jun   Aug »
 123456
78910111213
14151617181920
21222324252627
28293031