We need to teach Computing that has purpose and meaning

which I think is what Applied Computing tries, but often fails, to do. The idea that is sugested in the linked post is for CS teaching to tell a story (perhaps metaphorically) and to have a beginning, middle, and end. In the real world many people do not need skills from the more theoretical end of CS. I say this with my tongue ever so slightly in my cheek, having thought that I wouldn't need any of those geometry and trigonometry skills from Mathematics until I started working on visualisations of argument structure. Although I say that for effect as I actually needed those skills when I worked building sites doing joinery in the real world. In computing though, the skills that people do need are applied computing skills. These are good, practical, real-world computing skills that cover at least formal skills in:

•     problem solving,
•     ideation,
•     coding,
•     source control,
•     development methodology,
•     team-working,
•     communication
•     probably others but I can't think of any right now...

Additonally there needs to be sufficient background and experience of the academic side of CS to allow the student to have some idea of the breadth of tools and techniques that CS can offer as well as how to aquire and apply them to their own problems. However I don't think that Applied Computing should be taught in isolation as I do not want to turn Applied Computing into a vocational course. I think that what is required is the story, provided by an associated application domain that scaffolds the use of computational tools to solve problems. For example, Applied Computing with Life Sciences, Psychology, Law, Engineering, or any of a myriad of subject domains. At university level these should of course be selected from those areas that the University is already good at. For example, the University of Dundee has a large and successful College of Life Sciences and increasing numbers of vacancies for software developers which it struggles to fill. Unfortunately there is not sufficient joined-up-thinking to ensure that LifeSci students are getting a thorough grounding in computing so the graduates that are being produced are not suited to some of the jobs that are becoming available. With the increasing trend towards heavy computer use in the life sciences this is a bad situation. Additionally, the Applied Computing degree does not have close ties with many of the range of other subject domains that Dundee does well, so ends up being a kind of theory-light CS. This gives graduates lots of tools to take away with them but no subject matter of their own to which they can apply them.

Interestingly this approach might be useful in tackling that age-old question of how to attract and retain women undergraduates in CS. In "Is Teaching Computer Science Different from Teaching Other Sciences?" (1997), Bernstein suggests that women see computers as tools and men see computers as toys. Whilst I think that this is an overly simplistic view, gender bias and preferences are much more complicated than that, I think that teaching computers as tools is essentially what I have suggested above but with the caveat that an application domain gives you the structure and narrative into which to fit those computing tools.

Permalink | Leave a comment  »

• Tweepy - Twitter API Python Library
• NetworkX - Network/Graph Python Library
• Gephi - Network Vizualisation Application

Essentially the class did the following:

1. Used Tweepy to access Twitter API & grab lists of users related to BetaWorks and for each user access their relationships
2. Used NetworkX to build a graph of relationships using the data retrieved from Twitter
3. Export the graph in GraphML format
4. Import the graph into Gephi for manipulation, personalisation, investigation, &c.

Example code is available from GitHub

Permalink | Leave a comment  »

This is because Scooby-Doo is not about the supernatural, its not really a cartoon about kids fighting monsters but about kids looking for truth.

"the world is full of grown-ups who lie to kids, and that it's up to those kids to figure out what those lies are and call them on it, even if there are other adults who believe those lies with every fiber of their being. And the way that you win isn't through supernatural powers, or even through fighting. The way that you win is by doing the most dangerous thing that any person being lied to by someone in power can do: You think."

Seen through the lense of late sixties idealism, Scooby-Doo becomes a cartoon in which the viewer is trained to understand that whatever the mystery, you just have to observe, ask questions, and think to come up with rational explanations. The monsters don't really exist, just bad people who want to make you too scared to look, let alone ask questions or think, so that they can take advantage. Against this backdrop Scooby-Doo becomes a really nice way to educate children in the prerequisite skills of critical thinking: (1) observing, (2) questioning, and (3) thinking.

Addendum: There is also a nice discussion thread about this over at BoingBoing

Permalink | Leave a comment  »

One thing I was unsure about was how to handle versioning at deploy time, especially as I move towards continuous deployment of various projects. Turns out that one way of doing this is to name the Javascript file with the hash of the file instead of just calling it all.js or adding a query string. This gives a unique name for your src file without subjecting you to the vagaries of any cloud deployment infrastructure that may be operating on eventually consistent principles. This is nicely explained, with diagrams in this post over at Ben Kamen's blog. In the comment thread from that post, one commenter suggests also that using an Amazon S3 bucket to hold Javascript files and ensuring to deploy  the new Javascript file there before any code that accesses it is made available to users is a good approach also.

Permalink | Leave a comment  »

So Jeremy Clarkson said something else that was stupid and designed to inflame public opinion. As Ben Goldacre points out "Complaining about Clarkson expressing an offensive view is like complaining that the wheels just fell off your clown taxi". The problem I have with what he said was that he sought to isolate an identifiable group of people and advocate bad things happening to them. Do I want that kind of speech restricted? No. Definitely not. I support freedom of speech especially for those people who say things with which I disagree because freedom of speech does not exist without the freedom to utter unpopular speech. That said, if you say something that causes offense then there may be repercussions, I just don't believe that these should be legal repercussions but that repercussions, if any, should come from public opinion, perception, and reaction.

But that is an aside to what this post is really about. The thought that was stirred up by this was more about a particular type of argument associated with this kind of outburst. Specifically the way that we react to this kind of statement. For example, Clarkson, referring to are public-sector workers who were on strike on November 30th, said the following:

   "I’d have them all shot. I would take them outside and execute them in front of their families."

One of the reasons that he should not have said this is that if you replace the group "public-sector workers" with Black people, women, children, homosexuals, transgender, Jewish, or any other minority group then you get a much more serious statement. A statement that in some cases could conceivably see you landed in jail. For example:

    "I’d have Homosexuals shot. I would take them outside and execute them in front of their families."

In these cases the defense of "only joking" rings hollow on most occasions. I suspect that, given that Clarkson is also a public-sector worker he doesn't literally advocate what he said but rather uttered something that stemmed partly from an "I'm alright Jack" perception of events and partly something that  was calculated to cause some amount of offense as his job in relation to anything that isn't related to cars seems to be taking potshots at easy targets like some kind of BBC sponsored bully. If Clarkson had used the exact same words in reference to black people then he could have been charged under one of those heinous little incitement laws that target the effects of discrimination rather than the underlying causes so that the government can be seen to be doing something without really doing anything of consequence.

For the moment I will refer to this stereotypical pattern of reasoning as the argument for the substitution of subjects which essentially has the following structure:

CONCLUSION: Alpha's argument about subject X should not be accepted .

SUBSTITUTION PREMISE: The argument would not hold if you substitute subject Y for subject X.

EQUIVALENCE PREMISE: What holds for subject Y also holds for subject X

MINOR PREMISE: Subjects X &/or Y are groups of individuals that have a special status.

What is interesting here is that an evaluation of the original argument or statement can be made based upon changing the variables. An argument with respect to group Y would not be acceptable so the argument with respect to group X is not acceptable either. This is interesting because it has a flavour of strawman about it. The defense against the position deliberately misrepresents the stated position of the speaker by ascribing a position to them that they haven't stated that they hold. Usually this is considered to be a rhetorical practice; misrepresent your opponents position to create something that is easier to attack than their actual stated position. In this case though it is a quite devastating rhetorical technique, particularly because when used in a public it creates an indefensible position. It is a difficult defense to maintain to say "of course I wouldn't support doing X to Y but Z are different" because it has the feeling of creating a minority that it is alright to do terrible things to because somehow they are different or 'other'.

We see this kind of argument quite often when dealing with tough real-world problems. This usually occurs in relation to problems that are affected by some form of prejudicial feeling. For example, some quite dispicable things are said in discussions on so-called 'gay marriage' or 'gay adoption' (NB. these terms are quoted because in my opinion there is JUST marriage and JUST adoption regardless of the sexuality of those concerned).

For example, I have heard people say that homosexual people should not be allowed to raise adopted children. If you substitute an alternative minority group for gay then the argument immediately becomes ludicrous. However the same people will rarely say that they do not believe that black or Jewish or disabled people should not be allowed to raise children.  Generally these utterances and the associated substitution expose the prejudices of the speaker more than they provide an edifying and well reasoned argument for or against a given stance. They are in fact one of the ways to distinguish whether the entire dialogue is worth having in the first place. Gilbert suggests in "How To Win An Argument" that you should never argue with a fanatic, perhaps this should be extended to bigots as well.

Permalink | Leave a comment  »

My other point was to give children a head start in learning their tools and to ensure that they have the time necessary to learn them well. There is an article by Peter Norvig named "Teach Yourself Programming in Ten Years" [ http://norvig.com/21-days.html ] which takes issue with the teach yourself programming in x days/weeks/months series of books. Basically you can learn the syntax of a language in a few days but to really program well using that language requires experience and knowledge of the capabilities and limitations of that lanaguage, not to mention learning the, probably extensive, standard and third-party libraries that mean that you don't have to constantly reinvent the wheel. This obviously takes time, and I am not for a moment suggesting that our Children should be learning a vast array of languages and leaving junior school as ready-made software developers. What I do expect though is that, given that a lot of active learning is about assimilating and organising information, a child should be able to reach for the computer as the primary tool to work with information, in the same way that during the pre-computer age we would reach for a pen and paper when needing to make notes. I want to go further than this though, using the computer as an information management tool is quite straightforward with tools such as text editors and spreadsheets but this is to deny the child the real power of the machine, the power to bend the machine to their will, the power of coding.

How do we do this? Well the approach taken by the Raspberry Pi [ http://www.raspberrypi.org/ ] project might be a start. However I worry that this approach distances us from the computers that we meet in every day life. What might be better would be to make sure that the computers that our children encounter contain the basic tools that they need in order to use the machine in the ways that I outlined above. One approach might be to start installing a Linux as the default learning environment so that programming tools are there as standard but that is a whole 'nother can of worms that I don't fancy opening today. Another approach might be through play or writing games. Yet another might be through embedding computing tools at all levels within the curriculum. Of course any of these approaches will require effort but isn't that a part of the continual process of ensuring that our children are taught the things that they need to know and that teachers have the skills necessary to do so.

Why is it worth doing this? In the "Reading, Writing, Programming?" [ http://www.itworld.com/software/228381/new-school-curriculum-reading-writing-... ] article at ITWorld there is the following comment:

We're living in an exciting time when someone with a hot business idea, Javascript coding skills, and a free Amazon cloud account can get an internet application up and running in a weekend - and put out iOS and Android apps almost as quickly. That kind of freedom should be the kind of thing that appeals to kids looking for their 'ticket out of the ghetto'.

Perhaps this is the path we should be enabling. Inspiring the entrepreneurial spirit, as early as possible, and giving young people the tools for success.

Permalink | Leave a comment  »

When and why should we start teaching our children how to code?

My own position is that this should start as early as possible. Why? Partly my belief is based on fond memories of doing simple programming in Basic on my Commodore 64 at the age of seven, if I enjoyed it then why shouldn't anyone else? Quite apart from my personal belief is the knowledge that:

"The tool of the 21st century is the computer"

In other words, regardless of what area of work you are in, there is a good chance that you will need to use a computer. The sooner our kids are comfortable with computer use, up to and including coding, the better.

However, just using a computer is not always enough and reiterates a common misunderstanding of computing that can be delineated into clerical computing, using the standard tools that somebody else wrote and applying them to our problems without any deep understanding of how they work, computer science, which is not really about computers and their use and which I explored in a previous article and which can get rather theoretical, and applied computing, which is the use of computers to solve real problems by being a tool builder rather than merely a tool user. I think that teaching kids to code sooner will lead us to have less of the clerical computer users, and more of the applied computer users, which can only be a good thing.

Doing applied computing, which is what most coding really is, needs us to understand that the computer is a practically limitless tool that we can shape to our needs. We don't just use a computer, we shape it, we mold the computer so that it provides the kinds of tools we need to provide solutions in our own individual problem domains. If you sit at another person's machine you will intuit this when you see that they have things set up differently, or different software installed. But this is just skin-deep. When you really use a computer you start building new software that nobody else has installed, because you, and possibly ONLY you, need that particular piece of software. This is most apparent when you sit at the machine of a Unix or Linux user. You will find scripts and tools written by the user to perform their own tasks, to solve their own problems. Usually these tools are created in the spirit of the Unix philosophy, do one thing, do it well, communicate with other tools, facillitate reuse, &c. but most importantly they are symptomatic of a computer user taking control of their machine and fashioning new tools to supplement the standard ones.

I will reiterate, just using the computer is not enough, you need to own the computer. You need to ensure that the computer is your tool and that you know how to use it as such. You need to know the kinds of problems you can solve as standard with the computer and how to adapt that tool to solve new problems as they arise. It is the skill of tool adaptation that is what coding give you and the sooner you learn to code, the sooner it will become just another internalised skill that enables you to use your computer to solve problems quickly and accurately whenever they arise. A child that learns to code at high school age will have a lead over those who start coding at college or beyond. Similarly, a junior age child who can sit at a computer and produce code to satisfy their need will have a huge advantage over those that cannot. Note that I am not suggesting at this point that kids should be writing code that is ready for production use, although that would really change the nature of child labour and outsourcing in some areas of the world. What I am suggesting is that children are empowered to ask questions and seek answers for themselves, and that their primary tool for working with problems can be, and should be, the computer.

For me, a second, and more important question is not when should we start teaching children to code, but how shoud we teach children to code? We need to frame this in such a way that children of all genders are empowered to code. Finally, against this backdrop the percentage of male applicants to undergraduate computer science courses is increasing despite some efforts being made to make computing more attractive to all genders. So my final corollary today is, how should we present coding as an interesting and useful skill for Children of all genders to cultivate?

Permalink | Leave a comment  »

One of the commenters in the thread on that post illustrates this idea in relation to other engineering disciplines such as automotive, electrical, and civil engineering where the maturity of these fields can be evaluated in terms of the management of complexity within them and the develoment of a hierarchy of reusable components and agreed abstractions which mean that, unless you have exceptional circumstances, it is not necessary to make those components yourself. To some degree, software engineering as a discipline is maturing in this regard; we have middleware tools and database tools that stop us from having to re-engineer those layers ourselves, choosing instead to use off-the-shelf solutions, and we also have software design patterns, languages that enables us to communicate solutions with each other.

The second post also explores the same space, but instead of from the interconnection perspective, focusses on the widget building nature of software engineering. The key take away from this is the idea that "(software) engineering would benefit from a more explicit focus on plumbing skills", a more explicit focus on building, testing, and maintaining the APIs that allow these complex modern software systems to be built from individual components. I know that the design, implementation and use of programming interfaces is, at best, poorly handled in most formal taught software development & user centered design courses at university level in the UK. Whilst the value of well design graphical interfaces has long been an important part of computing degree courses the same cannot be said of the design of textual & software interfaces. Given the increasing interconnectedness of modern software systems, this is something that has to change as we move towards software development as a real engineering discipline.

Permalink | Leave a comment  »

This tool does not just simplify the process of building CouchDB to the point of needing you only to kick off a rake process, it also manages all dependencies and allows you to specifiy particular builds of CouchDB from the git repo. The process is much simpler than my earlier attempt:

• git clone git://github.com/iriscouch/build-couchdb

• cd build-couchdb

• git submodule init

• git submodule update
• rake

When the rake process has finished, which might take some time depending upon the speed of your build machine you should be able to start couchdb using:

• build/bin/couchdb

then access CouchDB from the usual url: http://127.0.0.1:5984/

I have plans for an upcoming series of posts on getting started using CouchDB and Python to build webapps. If you can't wait for that then the "Getting Started with CouchDB" articles over at NetTutsplus is as good a practical intro as any. If like me you like to also have a printed book to support you then take a look at "CouchDB: The Definitive Guide " and "Beginning CouchDB ". Whilst they are never going to be considered the classic texts on this technology they do provide a decent enough overview if you work at it.

Permalink | Leave a comment  »

There have been a lot of changes in my working life over the last year or so, with more details in an upcoming post. One of the things that I have come to reconsider is the basis of my research and how it connects to the wider real world. This is in the context of the "academic research" sphere where the drive to publish is currently the prime mover, at least in most computer-science departments. This drive to publish means that, in my experience, only journal publications are taken into consideration in setting the research agenda and managing the activities of early career researchers. This can be to the exclusion of meaningful real-world impact that actually gets the outputs of research into the hands of those whose problems the research was designed to tackle.

Over the last ten years I have seen many great pieces of research, that could have real-world impact, languish in computer science departments because, the grant had run out, or the work was entirely theoretical so there was actually nothing to release, or the journal paper was published so there is nothing left to do, or the university could not see any way to profit from the research.

Two illustrative examples sping to mind here; in a recent interview Andrew Tanenbaum opines that:

"I published a paper in 1978 on something very close to the Java Virtual Machine, but we never got much credit for it although we were years ahead of Sun."

This illustrates my conjecture that just the paper is not enough when we are talking about the outputs of academic research. You need to release the code as well, ideally via a source control mechanism. This should be in a form that is easily reusable including build scripts. This should be done to matter how "hacky" the code. One of the worst things to hear, and I am guilty of this as well, is "we will release the software as soon as we have cleaned up the source code". In my defense, at the time I didn't know any better, and am now actively taking steps to repair the situation. I actually heard this again a fortnight ago, and I know it is always said with the best of intentions but it generally means that the code won't be released because there is never the time to do the cleanup, and if you don't have the mindset to work in the open, warts and all, then you are unlikely to ever feel that your code is ready for release. This can best be tackled by starting the project in the open and continuing that way. If you already have code then just bite the bullet and release it. I suspect that if Tanenbaum had done this with his JVM code, assuming that there was such a thing to underpin the paper, then it is likely that such a useful technology would have garnered significant uptake and hence Sun would never have had to re-invent the technology to scratch their itch.

My second example deals with the notion of uptake of an idea and is important. If the fruits of your research are released in a form that is useable by those other than the research niche in which you are working and who also happen to have read your journal paper, and if the idea solves some real-problem, then there is every chance that someone outside of your immediate circle will find a reason to use it. This is the beginnings of community. I would suggest that a new software tool, based directly on current research, and which garners even a couple of thousand users, has at least an equivalent impact factor to the average mediocre journal publication. Yet it is this area, software released by academic departments, around which a large community coalesces, which I have seen abandoned because "it doesn't buy us anything to continue with this". Even when other universities move into the same area several years later and begin to spin-out profitable, university-backed companies based on less-functional clones of the original software.

So, I suggest two lessons for computer science research:

1. Where appropriate we should aim to release early and release often, whether that is code, data, discussion, or conjecture.
2. If this leads to community-building and uptake, even if it is not a scientific community then you must recognise the value of that community and argue strongly that the community is an existance proof of the impact of your research agenda.

An alternative would be to do the research in the open as much as possible. If code is written as part of the research then that code should be immediately released. Minimally the core project repository will be hosted at least on a publically accessible server. Ideally the repo. will be located on GitHub (other distributed source control tools are available) where it is more easily discoverable than your departmental project server. Ultimately we need to affect a seachange in expectations with respect to academic research. Yes, we need to clearly and cogently write up our results in a manner that is concise and easily communicates our discoveries to others, something that papers are an OK mechanism for. This should not change, it is a necessary condition of being part of the existing research community. We also need to recognise that in the longer term, this is not enough, and that we will develop new and better methods of not just distributing results and findings but also of making those discoveries in the first place.

Permalink | Leave a comment  »

There is a nice brief introduction to computability over at Good Math, Bad Math. My research has increasingly moved in the direction of this area of formal computer science over the last couple of years as I have developed the Dialogue Game Description Language, a domain specific language underpinned by a formal grammar expressed in EBNF and used to describe inter-agent communication protocols.

From my perspective, if you are interested in finding out more about what Dijkstra meant when he stated that "computer science is no more about computers than astronomy is about telescopes" then this article is a good place to start. Computer science is the study of the theoretical foundations of information and computation as well as the more practically oriented implementation and application aspects. It is these theoretical foundations that computability is concerned with. More specifically computability is a sub-branch of the theory of computation an area of computer science that addresses questions like "what problems can we solve using a computing device?" and "if we can solve this problem on a computer, how efficiently can we do so?".

Permalink | Leave a comment  »

Whilst not directly argumentation in the sense that I am usually interested in, the Filibuster is a political debate technique that has a long history going back at least as far as the Roman empire. The Filibuster is a type of gamesmanship that (mis-)uses the rules of debate found in the parliamentary procedures of a range of countries to enable a proposal to be delayed or obstructed. This happens because the procedures allocate a given amount of time for discussion and voting. If the time runs out before voting is complete then the proposal is effectively blocked.

Over at Filibustery, the Filibuster is getting some attention with a series of videos exploring filibustery. The first episode has been posted and we are promised that the second will be posted in the lab fairly soon.

Permalink | Leave a comment  »

There are a series of interesting posts over at Jean Goodwin's blog that looks at the process of debate and the tactics used therein, using the debate between Marc Morano and Mark Maslin as an exemplar.

The tactics discussed are:

1. Civility - How do the speakers interact? Do they interact directly with each other or via the interviewer (in this case). Do the speakers maintain the appearance of civility all the way through? How do they address each other? Does this change during the debate? How do the speakers characterise each other? Are the speakers having fun? Are they irritated? Are the speakers engaging each other or are they dismissive?
2. Hedging & Asserting - Hedging is using words or phrases to limit the amount of imposition on the other party. Whilst debate is, by its nature, about disgreement, hedging backs away from open disagreement by using phrases like "I think" or "I believe" out of a desire to avoid a confrontation. Asserting sets up a confrontational position and hedging generally weakens such a position.
3. What's the issue? - What are the speaker's arguing about? Why are they arguing about this issue? Have they been influenced or coerced into the debate? Has the motivating issue changed from the original issue? Did one of the speaker's manage to shift the issue from the originating issue to something else that is easier to win?
4. Bringing the arguments home - Assess the arguments made during the debate. Have the speakers managed to persuasively link their supporting data to their conclusions? Are all the steps in the argument explicit or are there gaps? Are these gaps because there is no evidence? or are they rhetorical? or both?    
5. The adverse witness - Do both speakers quote the same data or sources? Are these used to draw different conclusions? Do the speakers try to use their opponents quoted data or sources against them?
6. The appeal to authority, by the numbers - Sometimes we have to trust what the experts say? Are we being asked to look at the evidence and draw our own conclusions or are we being asked to trust the experts who have already done this for us. Goodwin makes an interesting point about the role of appeals to authority in the modern world:
   

   Appropriate appeals to authority were taken off the list of fallacies long ago. For good reason: we couldn’t survive without others’ expertise. We’re everywhere dependent on knowledges divided up into disciplines far more minutely than the work in Adam Smith’s old pin factory. In some cases our very lives may hang on the specialized knowledge that went into the design of a car’s floor mat or a factory’s system for washing spinach–although we’re only likely to remember it when the design goes bad.

7. Scientific Consensus - How do consensus claims work? Goodwin refers to one of her own projects which investigates this question. An interesting aspect is depicted called "rising above" which can turn the audience if they perceive that you are being condescending or arrogant. This is of course a risk if you are presenting yourself as the expert or amongst the experts as it could lead your opponent, or the audience, to perceive that you believe them to somehow be beneath you or not sufficiently educated to understand for themselves.

8. Repeating oneself all over again (Argument Craftsmanship) - Is the speaker taking a general idea, that has been expressed many times before, and adapting it to the current situation? Has the idea been formulated and refined in such a way as to provide a logically strong position, but no stronger? In this case, Goodwin suggests the use of topoi in the form of small but forceful chunks of domain knowledge that you can organise and assert as required to support your position or attack your opponents position.    

9. Take advantage of your opponents' commitments - Do the speakers each build their case based on the commitments incurred by their opponent? This approach was introduced in the adverse witness post where it was noted that in order to debate where there are numerous constrictions, e.g. issue complexity, limited audience knowledge, limited debate time, using shared concessions is a good way to make progress. Essentially, one of the most basic and powerful tactics for winning a debate is being able to take the things that your opponent has said and turn them around, use them against your opponent.

All in all a good analysis of the debate from a rhetorical perspective. Analysing those aspects of the debate that can be separated from the specific things that were said and the specific effect that they had on speakers and audience, and can be more generally identified as tactics for winning the debate.

Permalink | Leave a comment  »

The Lifehacker post "Open a Locked Suitcase without Leaving a Trace" linked to this video showing how to tamper with locked suitcases. A suitcase zip can easily be forced apart using a pen so that items can be inspected, added or removed. The insidious part of this hack though is that zippers are self-healing, by moving the locked-together zippers backwards and forwards along the zipper path, the zip can be re-closed leaving the suitcase appearing as though it has never been tampered with. This is a failure mode of luggage security that most people will not consider. Yes, we assume that a suitcase offers little security but we also, as a rule, assume that we would notice if our suitcase had been tampered with. We expect that either the lock will have been visibly tampered with or that the case will have been cut or damaged in some obvious way. We don't generally expect that we can close and lock our suitcases and that they are then quickly and trivially manipulated.

To give us our due, I think that most of us do not see suitcases as being particularly secure and would not place anything valuable into them unless forced to do so, so the risk of losing irreplaceable items is generally quite low. We also kind of expect that our suitcases will be inspected nowadays, at the very least using a non-invasive scan such as X-rays if not being opened up and pawed through. The big risk for most of us, especially if travelling to somewhere like Turkey or Thailand, is that something might be introduced into our suitcase which could make our trip through customs worse than usual.

Generally we see having a lock on our suitcase as a check on the integrity of the suitcase but now we cannot be certain that our suitcase hasn't had something inserted into it without opening and going through it. This scenario not only gives a real world illustration of a physical man-in-the-middle attack but also illustrates an important element of security engineering, namely integrity. Schneier's definition of integrity [Applied Cryptography, second edition, (1996), pp. 2] is as follows:

Integrity It should be possible for a receiver of a message to verify that it has not be modified in transit;    an intruder should not be able to substitute a false message for a legitimate one.

If we consider the suitcase as our "message", one of the receivers of our message is the owner of the suitcase who wants to get it back containing only what it contained when it was checked as baggage, nothing more and nothing less. The owner desires that the message has integrity and ostensibly relies on the locks as a means of verifying that integrity. In a more general communication-oriented sense, integrity comes alongside two other elements, authentication and non-repudiation, defined thus (ibid.]:

Authentication It should be possible for the sender of a message to ascertain its origin; an intruder should not be able to masquerade as someone else.

Non-Repudiation A sender should not be able to falsely deny later that he sent a message.

Because in this case the sender and receiver are, in one sense, the same person, the owner of the suitcase, then authentication and non-repudiation have little bearing on the circumstances because the lack of integrity is sufficient to consider the system broken. Under these circumstances it is enough to state that the luggage owner can be authenticated as being the person that they identify themselves as, and they have not, and perhaps cannot because of other checks and balances, repudiate their ownership of the luggage, the big gaping hole in the system is that the integrity of the luggage cannot be verified.

So how can we verify the integrity of our luggage? Simple methods like securing the locks so that they cannot be moved would stop this attack. Some suitcases have a built in mechanism or tie down point to allow this. I am sure that other mechanisms could be created but perhaps the integrity of checked luggage within a major airport cannot be verified cheaply, easily, or reliably. Perhaps ulitmately we have to openly accept this and not hold a person at their destination responsible for the contents of their luggage. Notwithstanding different laws on importation and prohibited items, we could ensure that the checks done at the originating airport are sufficient that they provide the owner with a defense should anything be introduced once the luggage is out of their supervision.

Permalink | Leave a comment  »

This Wired article gives a nice demonstration of Schneier's law which says that anybody can create a security system that they themselves cannot break. This particular security system is for scratch-lottery cards which the makers say are secure because they have been independently vetted by outside experts. But just because your experts can't break the system doesn't mean that nobody can, and if somebody breaks it then you can guarantee that the "bad guys" are going to be exploiting it even if the man on the street doesn't.

The weakness in this system stems from the need to control payouts. The lottery company can't just randomly allocate numbers to tickets and hope that they haven't produced too many winners. They have to carefully allocate winners in the right proportions to ensure not only that they don't bankrupt themselves but also that they make a healthy profit along the way.

The tickets are clearly mass-produced, which means there must be some computer program that lays down the numbers. Of course, it would be really nice if the computer could just spit out random digits. But that’s not possible, since the lottery corporation needs to control the number of winning tickets. The game can’t be truly random. Instead, it has to generate the illusion of randomness while actually being carefully determined

The nice thing about the breaks discussed in the linked article are that they achieved through inspection of the ticket only. The information given on the face of the ticket is enough to confirm whether or not the ticket is a winner or not.

The trick itself is ridiculously simple. (Srivastava would later teach it to his 8-year-old daughter.) Each ticket contained eight tic-tac-toe boards, and each space on those boards—72 in all—contained an exposed number from 1 to 39. As a result, some of these numbers were repeated multiple times. Perhaps the number 17 was repeated three times, and the number 38 was repeated twice. And a few numbers appeared only once on the entire card. Srivastava’s startling insight was that he could separate the winning tickets from the losing tickets by looking at the number of times each of the digits occurred on the tic-tac-toe boards. In other words, he didn’t look at the ticket as a sequence of 72 random digits. Instead, he categorized each number according to its frequency, counting how many times a given number showed up on a given ticket. “The numbers themselves couldn’t have been more meaningless,” he says. “But whether or not they were repeated told me nearly everything I needed to know.” Srivastava was looking for singletons, numbers that appear only a single time on the visible tic-tac-toe boards. He realized that the singletons were almost always repeated under the latex coating. If three singletons appeared in a row on one of the eight boards, that ticket was probably a winner.

What is most telling in this story is the reaction from the Ontario Lottery and Gaming Corporation; pull then game then claim that there was a design flaw, that it was a limited flaw that only affected this one game, carry on as normal. Meanwhile, other games had flaws and those who knew about them were able to exploit them as the office of the Ombudsman recognised:

..at least $100 million in prizes had been paid out to so-called “insiders” (i.e., lottery ticket retailers and staff of the Ontario Lottery and Gaming Corporation, or OLG) – some of it to “fraudsters.       

This is behaviour seen time and again in other so-called secure systems. For example, with so-called phantom withdrawals and flaws in Chip & Pin, and other supposedly secure systems, where, at least publically, the onus has been on the victim to prove that they are not at fault.

Another interesting aspect is that the payout statistics from the plundered games demonstrate that there is a break because the people exploiting the break don't buy tickets that they know will only pay out the face value of the ticket, i.e. there is no point buying a two dollar ticket that only pays back two dollars as that is wasting your own time. Therefore plundered games are going to have a higher than expected proportion of higher value payouts.

While there were far too few $2 break-even winners redeemed, there were far too many $4, $6, $10, and $20 winners. In fact, the majority of scratch games with baited hooks in Washington and Virginia displayed this same irregularity. It’s as if people had a knack for buying only tickets that paid out more than they cost.

The final thought that I have is that although the numbers on many of these tickets are the hook to get the player to buy them there is no reason why they couldn't also be covered with latex so that the tickets couldn't be pre-inspected for winners. There would be more to scratch off, but I have a suspicion that that is part of the game for many scratch card devotees. Perhaps these games haven't been fixed for two reasons, firstly, security protocols are hard to get right, and secondly, perhaps given the organised crime/money laundering angle, a large enough group of people have a vested interest in being able to pick a winner?

Permalink | Leave a comment  »

Until the police and government deploy a proper cure for kettling we will have to make do with defences. It requires a lot of police to seal an area, especially given the size of crowds that we have seen at recent protests. This means that there are a limited number of locations where kettles can be imposed. In an area as geographically complicated as a major city the best defence against the kettle is avoiding it in the first place and there is now an app for that. Whilst there are questions about whether a technological solution is appropriate, in the short term Sukey is going to help protestors know which way direction to head in to avoid the kettles.

The objectives laid out in the Sukey executive summary are as follows:

To keep peaceful protesters informed with live protest information that will assist them in avoiding injury, in keeping clear of trouble spots and in avoiding unnecessary detention. The application suite gives maximum information to those participating in a demonstration so that they can make informed decisions, as well as to those following externally who may be concerned about friends and family. It should make full use of the crowd in gathering information which is then analysed and handed back to the crowd.

From the security perspective it looks as though the developers have at least sought advice and thought about defending both themselves and the crowds supplying data. Without details though and a thorough code review it is hard to be certain. Whilst generally the advice has been that open systems can be more secure, the developers of Sukey are taking a hybrid approach. Source code will be released after each protest at which point the current codebase can be worked on by third parties and the developers will fork and work on the next version. This will maintain the longer term openness of the project whilst attempting to minimise the equivalent of a zero-day exploit that could be used by the police during a protest.

So, given that any protestors who are kettled are likely to be identified anyway, what are the defenses against Sukey? I can't imagine that the police will be shutting down mobile phone networks during protests or jamming wifi for that matter. One potential weaknesses is in the source of input data. Amongst the crowds providing data will doubtless be police acting as saboteurs or provocateurs so input data could be spoofed. Perhaps there will be a sufficient density of non police sourced data that police-originated spoofing will be lost in the genuine data. An alternative weakness may lie in the reliance on web services and non-distributed nature of the system. If there is a single, or sufficiently critical, point of failure then the police could target that on protest day. My last, and admittedly most far-fetched initial thought is of infiltration, if the police are able to take control of the system on protest day, rather than just breaking or shutting it down, then they could direct protestors towards kettles rather than away. Which would be bad.

To be honest I think it is sad that protestors have to come up with a solution like this to defend themselves against those whose sworn duty is to protect them and maintain safety. That said it is a really cool piece of code and an exemplar of what smart-phones (iPhone), crowd-sourcing (the protestors and interested by standers), and mash-ups (swiftly, Google Maps) can achieve.

Permalink | Leave a comment  »

Although it hasn't yet reached my account, Facebook have announced that they will soon be enabling HTTPS for all communications with the site and not just when you send your password. This is a bit of a privacy win and should enable us to better protect our personal data. Given that most of the data that we share on Facebook is private, in the sense that we share it with our friends and not the world at large, and because Facebook is one of those online venues where people organise themselves and the lack of HTTPS has lead to some unfortunate security lapses. For example, with the collusion of an ISP, the Tunisian government were able to disrupt protests by inserting malicious Javascript into users pages after authentication and subsequently deleting accounts and censoring critical pages. Even if you are not planning protests that might overthrow a government, the idea that a third party can interfere with your private communications should give us sufficient pause to want to make use of this facility. This is especially true if you are logging in from public terminals or over wifi.

Over the last few months there have been a number of reminders of how easy such session hijacking is to achieve. FireSheep, a FireFox extension, showed us how easy it was to hijack a FaceBook session, whereas idiocy.py demonstrated how, in 129 lines of code, you can automatically highjack somebody elses Twitter account and post your own tweets as them.

Which brings me almost round full circle to say that HTTPS Everywhere is a FireFox extension that I have been using for a few months to make FireFox default to HTTPS when available. This is a tool that just works and is a necessary step along the path to the secure by default future internet.

Permalink | Leave a comment  »

The Interactive Institute has a range of energy consumption interfaces, devices and services designed to feedback to folk about the amount of energy that they are consuming and possibly also to influence their behaviour with respect to their energy consumption. These include:

• The Energy Coach - a service to help you take better control of energy usage
• The Energy AWARE Clock - a feedback device that visualises the spikes of energy usage in your household on a clockface.
•  The Energy Plant - an LCD that visualises household electricty consumptions as a growing plant

Many of the ideas in isolation are not entirely novel although they do have a shiny factor that isn't to be found in similar offerings elsewhere. For example, OPower have a similar system that they describe as their smart grid front-end. This is designed to influence customer behaviour through a combination of feedback via a hardware peripheral, good usage analytics and visualisation, and social influence, e.g. see how much energy you are consuming compared with the aggregated consumption of your neighbours.

One of the interesting things that the Interactive Institute is doing is combining serious games with energy consumption monitors. The important thing I find with this approach is having a game that is worth playing in the first place. Once you have done that I can imagine a game in which data from the sensors in your, and possibly your neighbours houses, affect the game world. Increased energy consumption might negatively affect the variety or amount of game items available. Other things, such as running a higher consumption device at a peak usage time might affect how exciting or dangerous the game world is.

Permalink | Leave a comment  »

I have posted before about gamification and the use of persuasive techniques to improve the efficiency of drivers. For example, the Ford Fusion prototype dashboard and the use of simple lights and meters to encourage drivers to accelerate smoothly without aggression. Here is another take on the same idea that doesn't require buying a new car just an iPhone. The glass of water app displays a glass of water and the aim is to not spill any of the water as you drive. I am assuming that the app is correlated to the movement of the iPhone so that if you drive smoothly then you won't spill the water, and hence will improve your driving efficiency.

This seems like a great way to improve fuel consumption. Link it to an online leaderboard, possibly with prizes for the best drivers, or best improvement, and you can make a broader multiplayer game out of it. Link the leaderboard to each individual drivers social network and you might actually begin to get real improvements in average drivers fuel consumption. Of course there is also a corresponding race-to-the-bottom game that could conceivably develop as well and the rules should take this into account. If the GPS could also be used to log journeys then, suitably anonymised, it would be interesting to visualise whether there are particular roads, areas, or times that lead to increased fuel-consumption or bad driving. I also wonder how much penetration would require before we could use a system like this to monito traffic flow. Whilst many autonomous-traffic management systems rely on transponders attached to individual cars or cameras watching all vehicles, perhaps there is a lower bound to the number of vehicles we track that can still give meaningful statistics about traffic conditions?

I do wonder about how traffic police in the UK would see this though. In one sense it is only an add-on version of what could be built into the car dashboard, and is not that different to a tom-tom, especially if there were an audible cue that could be used so that the driver wasn't watching their glass rather than the road. That said, an iPhone has a screen and could be used to display video and hence should not be within the drivers line-of-sight as far as I am aware.

Now we just need an android version, and cheap mass produced widget that sits on your dashboard and does the same thing for the non-smart phoners amongst us.

Permalink | Leave a comment  »

In the Guardian on Saturday, Ben Goldacre's column was called "how to read a paper" and suggested three checks that you can do when presented with scientific claims. These are:

1. Check the numbers - If there is sufficient data in the article then you should redo the mathematics yourself, especially where statistics and chance are concerned because the subtleties in relating these areas of mathematics to the real world mean that these are the areas that most people get wrong most often.
2. Check the publications - The claims made should be supported by published, peer-reviewed research. If this is not the case then serious questions must be asked of the claims such as, is the claimant trying to sell me something? A lot of science is communicated to the general public not directly from the scientists but from the press offices of Universities or other research establishments either as a way to increase their esteem, to attract a better quality of researchers, or to provide buzz for a new spin-put venture. As a result, quite often the claims made via press release are quite divorced from the claims made in the underlying research. The reader must therefore go back to the underlying research publications to get a clear understanding of the claim and it's veracity. At this point I must make a plea for all science reporting to include citations to the academic literature where possible. That said, all university press releases should also include reference to underlying research as well.
3. Check the credentials of the person who is making the claim. Are they someone who is in a position to know about their claim and therefore can assert and subsequently defend their claim?

I would also add my own fourth check:

• Check the wider field - If there is an established concensus and the claims seek to overturn this concensus then there is a burden of proof associated with the new claims that has to be satisfied

One problem with this approach is that checking claim one requires mathematical ability, and checking claims two and four requires the ability to read and understand academic writing. Reading academic papers is a skill that is not easy to pick up and generally takes most new Ph.D students their first year to really start getting the hang of. Partly this is due to the "academic style" that most papers are written in, and partly because scientific knowledge as gained from academic publications is more akin to a reef of information with each part supporting many other parts. To be able to read and completely understand one paper in a cutting edge area of science may necessitate the reading and understanding of tens or even hundreds of earlier papers that the current paper bullds upon. That said, science is not easy and most people are not scientists. This is not because they couldn't be, they just don't, as a rule, have the necessary background to verify scientific claims for themselves. Rather, the general public must trust the messenger. This is why trust is such an important aspect of science communication and why public engagement with science and scientists is so important. If the public are to take on trust what scientists say, so as to avoid that whole training in science so that they can do it themselves thing, then scientists must do what they can to build that trust. This can include research blogging or science blogging coming off campus once in a while and talking about what they do in normal everyday language with people who are at least sufficiently interested in finding out more to have turned up to a science centre or event.

Permalink | Leave a comment  »