On April 17, MediaNama conducted a discussion on Aarogya Setu from a privacy standpoint, and whether the app would even accomplish its stated objectives. On the panel were Professors Subhashis Banerjee (IIT Delhi) and Bhaskaran Raman (IIT Bombay), who were among the co-authors of the paper Apps for COVID: to do or not to do; and security researcher Riddhi Shree, who has studied the studied the technical features of the app. The discussion was moderated by MediaNama’s Aditi Agrawal. This post focuses on what could be fixed and improved to make Bluetooth-based contact tracing work in India.

Some suggestions from and based on the discussion:

How to improve Aarogya Setu

  • Make a case for contact tracing: At present, there is no white paper detailing how or if apps could be effective in contact tracing. The government needs to make a case of contact tracing, especially since, as Prof. Raman said, “Contact tracing is of use only when there is no community transmission.” A resolution in the European Parliament, passed on April 17, has similarly demanded a proof of concept for contact tracing apps.
  • Encounter graphs vs proximity alerts: “It is certainly possible to improve the effectiveness of contact tracing by doing a graph analysis instead of simple point-to-point contact tracing,” Prof. Banerjee said. Since surfaces are a major vector for the disease, he argued that it’s impossible for the app to be effective with just proximity alerts from Bluetooth signals by people next to each other. “Encounter graphs can either be centralised or distributed. Distributed computing may not be easy to scale. If you suck in data to a centralised server, which isn’t happening unless you test positive, that will have serious privacy implications.”
  • Minimise permission requirements: Riddhi Shree pointed out that the app was not clear on the permissions it was asking. “The permissions are different in different versions of Android”, she said, explaining how number of permissions taken increased with more updated versions of Android. A minimum set of permissions should be sought, and remain consistent in the app. Moreover, she pointed out, that Bluetooth was automatically switched on in Android, even before the user consented to share location and Bluetooth data with the app.
  • Establish responsibility for data governance: “There seems to be no particular government authority identified as a controller of data, which will have regulatory control,” Prof. Raman said. Establishing accountability for data collected would help. For example — and this is not the best example — in case of Aadhaar, the UIDAI is the regulator.
  • Limit usage of the app to contact tracing: Addition of more services to Aarogya Setu, especially those which involve KYC, such as UPI and e-Passes, makes pseudonomisation of device ID completely irrelevant. Scope creep should be avoided, and the app should be limited to contact tracing.
  • Have a dynamic pseudo ID: Aarogya Setu uses a static pseudo ID which is exchanged between two devices, while Singapore’s Trace Together app uses dynamic IDs, which is better for privacy protection. Dynamic device IDs are scalable in the Indian context with the appropriate algorithms, Prof. Banerjee explained.
  • Get rid of location data and make Bluetooth ID dynamic: “From a privacy point of view, the Bluetooth ID can be dynamically changed, instead of remaining static, as that can make de-anonymising users easier,” Prof. Banerjee said. “Secondly, get rid of the location data. Then, be more transparent about the server end, about how long the data will be kept. On making contact tracing more useful, that will require serious experimental research.”
  • Allow users to de-register and delete collected data: At present, users are not allowed to de-register/delete their accounts, and it’s not clear how data stored on government servers is treated post app uninstallation.
  • Transparency on data use: “Data that is generated by Aarogya Setu should not leave the app. The government isn’t giving data on how data is being used; it’s just promoting its installation,” Shree said.
  • Open source the app: Prof. Banerjee argues that making the code auditable is essential: “Making the source code open should be mandatory. When you are making a public application it has to be eyeballed by many people. Basic ethics and propriety demands that to have happened. There is a backend that is more opaque.” 
  • Integrate with real-life health services to boost trust: “Door-to-door services should happen so that better quality data is fed into the system. Now after this, contact tracing can be more valid. That way, there could be more trust in the system. Consent should be taken by health officials before sharing the anonymised data, like in Singapore’s TraceTogether app,” Shree argued.
  • If useful, use before community transmission for next outbreak: Prof. Raman said, “If there is even limited evidence of Bluetooth contact tracing being marginally useful, it might be worth using it before the community transmission stage for future diseases. The design and the implementation should be made open.”

***Update (April 21 10 am): Article was edited for clarity.