Technology to swear by, on, or at

As we flew back from Mobile World Congress 2016, our minds full of visions of connected cars and dreams of smart cities, we came across a newspaper article about alcohol sensor tags.

We learned that the UK government will be spending £400,000 (in London, first) on strapping tags onto convicted (and possibly violent) drunks. These ankle bracelets detect alcohol in perspiration, and then phone home when they detect the wearer has been drinking. The hoped-for result: no relapses as long as the tag is working, and less harm to property and people.

The SCRAM system has been in use around the US for quite a few years. A recent 18-month pilot study in parts of London showed that 9 in 10 subjects complied with the terms of their shackling. That kind of effectiveness is hard to argue against. Nonetheless, I like to think of this application of sensor technology as ‘swearables’. You, the user of the device, are powerless in its grasp. You cannot exercise your right as a consumer and switch providers or gripe on Amazon, or even phone up and complain. You can only grumble and curse. Hence, the thing is a swearable.

The annoyances can go beyond the mere inconvenience of having to abide by a court order. If the system goes wrong (or appears to go wrong) then it is likely you are going to be on the hook. Imagine that! Anyone who has had to deal with an internet service provider is likely to have experienced a) some problem with the service and b) some level of dissatisfaction with telephone support. Our phones freeze up. Over-the-air updates make them unusable. Software and devices conspire to glitch and force us to work around them and reset or replace them. Now imagine a situation where, instead of getting on your high horse and complaining to the support line, the person on the other end is the one giving you a hard time. You are the one who has to justify and defend the problem. You are yourself accused of violating conditions of use and are sentenced to a jail term or a stiff fine. This happens and has happened with SCRAM in the US; there are plenty of anecdotes from wearers who claim their phone lines weren’t working or that the device falsely flagged a drinking event.

Given that systems fail and bugs arise, sometimes through user or operator error, how can we know how well the bracelets work, and how sensibly we are using them? As far as my cursory research has uncovered, it is not possible for a concerned citizen to do a code review of the SCRAM system, or even query internal documentation like test plans and test results. Of course – this is a private product with IP owned by a technology company. However, it has applications in the public sphere, and serious implications to people’s liberty. To quote Judge Dennis Powers in his report on the effectiveness of SCRAM,  

…the SCRAM tether did not meet the requisite standards of ‘‘reliability’’ or ‘‘general acceptance’’ in the relevant scientific community imposed by the Michigan Supreme Court.

Here he was talking about the analytical gap between the data reported by the bracelet (alcohol detected!) and the interpretation (this was the result of an alcoholic drink, and not an environmental factor). The doubt, therefore, is not about whether the bracelet could detect alcohol trans-dermally, but in how we can reliably interpret the meaning of its data report. Well, quite! Oftentimes the risk is not in the tech itself but in its application. Judge Powers, for example, uses the SCRAM bracelet “as a deterrent” but does not assume it is always reliable. This seems sensible to me. Generally, it is crucial that we have a realistic and accurate understanding not just of how the tools work, but of their limitations, and how we can and should use them.  

How can we achieve this common understanding? At Matchbox we are often asked to quote for work building on or updating legacy systems. One of the standard questions we ask is “can we see the source code, please?”. Now, while it is not possible to see the flaws in a system by a quick scan of the lines of source, there are many ways of measuring whether the thing built does what the design goals state, and to identify where it can go wrong. We have a team of skilled developers, testers and admins who thrive on identifying and fixing flaws, and we know we can reduce the risk of disaster by looking inside the machine before we start to adapt it. And yet, it sometimes happens that we cannot preview the source, and then we have to accept the risk to the project.  

For us, as Matchbox the ISV / integrator, this is one thing. But for the broader ‘us’, citizens of the West, the risk of blindly accepting technologies we cannot vet is much higher, much more important. The makers of SCRAM stand by their technology and their processes. Various US and UK authorities have signed off on the same. For the rest of us, we should fight to make sure everyone has an equally clear understanding of how tech works and how best to apply it. Hopefully, the more we know, the less we’ll have to swear.