The Aarogya Setu App is “aimed at augmenting the initiatives of the Government of India, particularly the Department of Health, in proactively reaching out to and informing the users of the app regarding risks, best practices and relevant advisories pertaining to the containment of COVID-19.”
The Aarogya Setu app is intended to run on Android and iPhones. Currently the model is a voluntary one, where users download and install the app. The effectiveness of the app depends on its widespread adoption. The current environment of fear of contracting the dreaded COVID-19 and the urging by various agencies will surely encourage many users to install the app. And government action may persuade others in other ways.
There is talk that the app will be made quasi-mandatory, in that it will be used as an internal e-pass without which a citizen or resident cannot travel within the country. Consider the scenarios of a migrant labourer try to travel back to his home village, or a worker being allowed into a factory or a construction site. I argue here that using this app as an e-pass may not be a very good idea for multiple reasons.
BEYOND PRIVACY CONCERNS
There are the obvious questions regarding privacy and confidentiality. I am not even going to discuss these. To counter these concerns, quite some effort seems to have been made in the design, development and refinement of the app (on the advice of experts) regarding purpose limitations of storage and use of the data collected by the app. (See the article in Live Mint by Ravi Matthan). Let us accept these at face value. While no formal verification has been carried out and there are no guarantees being given, let us at the outset grant that the app has been designed in good faith and let us for the moment assume that there are no coding errors and bugs and vulnerabilities in the implementation (unfortunately this is almost impossible to ensure, especially in the absence of formal specifications and trustworthy computation bases). Let us also readily grant the overarching interest of the nation (state, society at large) in the unusual circumstances created by the contagiousness of COVID-19 to have access to the information regarding the peregrination history of each citizen, since the safety of life of the citizens trumps any privacy concerns. (Note: I do not believe that privacy should necessarily be sacrificed).
Let us instead examine reasons why the app may NOT be a reliable tool for monitoring, tracking and tracing the spread of the infection, and why there may be problems with making it quasi-mandatory, especially with any plan to use it as an internal certification mechanism. The takeaway: the app and the ecosystem envisaged for its use do not even need to be hacked for it to be rendered significantly less effective than it is touted to be.
COVERAGE AND EXCLUSION
The first issues are coverage and exclusion. In 2020 only an estimated 32% of phones in the country are smart phones. Most users continue to use feature phones. So in fact the most vulnerable sections of the populace such as migrant workers are not likely to be adequately covered by this app. Further, multiple individuals often share a mobile phone. If they belong to the same family and use a smartphone, the app is still a viable solution since it would be prudent to track, test and isolate each member of a family sharing the phone. However, this is less feasible with migrant labour living in slums and labour camps. That requires a much more effective public mechanism for countering the spread of COVID-19 than we currently have in place.
The geographic spread of smartphones is quite unequal — with significant rural-urban and inter-state differences.
Thus areas where there may be a local spread may not even be tracked using the app. Jharkhand is still largely on 2G, so the use of smartphones is much more limited there and in similar regions. As an alternative: if the envisaged use of the app is to track backwards in time the trajectories of users coming to a hotspot, then it might be easier to map the cellphones that come into the coverage of the nearest cell tower (an accuracy of c. 200-250m is possible). Even this is a humongous amount of data.
Another consideration is that the current lockdown has made it hard to obtain parts and services for cellphones. So if a handset malfunctions or a battery needs replacement, instruments are likely to be non-functional for longer periods, disempowering and hobbling the owners in many more ways.
BLUETOOTH MAY LACK BITE
The technology chosen imposes limitations on the app. The lack of precision in using communication-cell-based tracking is perhaps what led to the choice of using location tracking and Bluetooth technology in the Aarogya Setu app.
Location tracking allows tracking at a gross level, and finer tracking, especially indoor, uses Bluetooth. The app requires two devices to come into Bluetooth range to exchange information. (We will not discuss here what information should be exchanged, whether it should be encrypted, etc.) This idea is effective only if both devices are running the app and have location tracking and Bluetooth communication switched on. Now Bluetooth (even low energy versions) is energy hungry, which is why most most smartphone users do not always turn it on. In usage settings where phone users may not find it easy to keep their phones charged (again consider the large number of working individuals whose professions require them to be in transit or far away from home or office), this is not a very viable prospect.
The app will prove to be useful only when there is an overwhelming buy-in from every person to using it. This is not as easy to achieve as may be thought by panjandrums. If the costs and disincentives that come with having one's trajectory tracked outweigh any benefits of using the app, then the phone user may adopt the expedient of turning off the app (or even the phone), thus circumventing tracking.
Since humans are fallible and forgetful, they may not carry their device with them or may have a valid reason not to do so (e.g., the phone is charging) when they go out on a short excursion from their residence/workplace. Therefore, many interactions which carry risk of contagion may indeed be missed if we were to rely on the app. While policy makers may be tempted to think it possible to mandate the use of this app, it will be very hard to enforce such a fiat. What action will the authorities contemplate if a user turns off (accidentally or deliberately) bluetooth connectivity on their device? These actions are likely to be unduly punitive and arbitrary.
Bluetooth is also not a fool-proof technology — the pairing of devices explicitly still encounters failures fairly often, and automatic pairing is fraught with the likelihood of failed communication. Note that it would be very risky to entertain unauthenticated communication between devices. From our past experiments using Bluetooth and Wifi for automatic pairing of devices in mHealth apps over the years, we (at IITD, as well as our collaborators abroad) encountered failures of secure pairing, as well as communication and authentication failures much more often than desired, thus making the design of robust Bluetooth based protocols difficult. Again, all this means that possible contagions may not be correctly recorded by the app.
Indeed, various users of the app have already noted that it is quite buggy, and have commented on its limitations in their reviews, particularly with respect to the use of Bluetooth, as well as its energy inefficiency. They have noted its lack of features and the very sketchy nature of the information it provides its users. Some have mentioned that the risk assessment done by the app fails to flag high risk even when someone indicates all typical COVID-19 symptoms. Registration and logging in are recurrent problems. The developers have been responding gamely and promise assistance and technical support, but this is not a scalable arrangement that inspires much confidence for a nationwide roll-out.
LACK OF A MODEL OF THE DISEASE
Even if all these technological limitations can be addressed to build a reliable and robust system, there is a more fundamental problem with conception of the app. What constitutes an interaction that merits tracing and tracking? How long do two individuals have to be in proximity of each other? What distance apart should they be, what is the strength and degree of interaction? Are there mitigating circumstances (wearing PPEs, separation by a wall or window) to discount an interaction? In the absence of a precise enough over-approximation of the model of COVID-19 spread, the app may generate far too many false interactions, the parties of each of which may have to be traced down and tested. The problem of false positives may overwhelm the testing and tracing abilities of the healthcare system without commensurate benefits. Unfortunately, the disease and the mechanisms of its spread are not well understood to come up with a useful, precise-enough model which can be reasonably implemented.
BUG-FINDING IS NOT EASY
There also are the standard formalist objections to the deployment of such an app for such a critical purpose. Since there is no model of what is a significant interaction, it is not clear what is being recorded and how it is being used. There are no formal specifications, and worse, the source code is not yet available for inspection and verification. Reliability is critical, and the app does not even begin to address these issues. It is therefore not mature enough to be deployed for critical uses that far exceed its intended purpose. Doing so may have unfortunate consequences for various vulnerable users and also run the risk of overwhelming the capabilities of the public health tracking system with false positives. To do so in our environment of social distrust is fraught with very real dangers.
No comments:
Post a Comment