Is Location tracking in AarogyaSetu for Surveillance?
Privacy concerns around AarogyaSetu, India’s COVID contract tracing app, have been around since the launch of the app 3 weeks ago. This got a boost last week, with Rahul Gandhi, the principal opposition leader stating that “AarogyaSetu is a surveillance app”. The govt was quick to deny. A fierce debate is now underway both in mainstream media, social media and general public.
The “image” of the govt is pretty poor wrt privacy and surveillance tactics, so it’s not hard to see public concerns about “misusing” the app. But first let us try and understand what the Setu app does (and guess how) and then examine if the approach adopted by the Setu team makes sense and was the best approach given the emergency requirements driven by the pandemic around us. Subsequently, we will examine if Setu can indeed by misused for surveillance and which parts of Setu infrastructure allows for surveillance type activity.
There is little public information on the architecture of the Setu app, its data collection strategy, encryption approach etc so I have had to piece together this “interpretation” from known public sources and my training as a computer science engineer. The Setu team has publicly said that they use Bluetooth and location data as the foundation technologies for enabling contact tracing. Lets start from here and “work out” what design / architecture would be needed for building such an app.
Key Design Objective
The key objective of the app is to keep a record of the people any user has been in contact with, over the past 21/28 days (incubation period of corona virus) so that for every +ve case identified by a test, one can identify (trace) all contacts who have been in the proximity of the individual (using that individual’s proximity records) and the health workers can call them to inform them of their likely exposure, isolate themselves (quarantine) and if needed, get tested for virus themselves. By providing the potential list of suspects in the contact pool, Setu makes the job of contact tracing significantly easier, structured and faster. This helps the administration manage the disease spread better.
The mechanism to record proximity records, i.e. — database of all other users that an individual user has been in close contact with over the past 21/28 days, is primarily bluetrace protocol — exchange of Bluetooth signal strength with other devices in Bluetooth zone of influence (typically < 10m; threshold would be set to lower range else there could be. Too many encounter records). If two users come into the bluetooth zone of each other, and they both have the Setu app, then the apps can exchange a record logging the contact between the two users and the strength of the Bluetooth signal so that the distance calculation can be done at the server to save battery life. If any user tests +ve for COVID at any time, using their proximity database recorded by the app, the govt can alert the contacts about their own risk, request for isolation, testing etc as per protocol.
The Approach in Australia / Singapore
In the Singapore / Aus version of the app (excellently explained by Prof. Sanjay Jha, University of New South Wales here), the app works on a tempID generated foreach user, encrypted by a key with the issuing authority (usually the health ministry under governments as home ministries have poor privacy reputations ) and linked to the contact info stored at the govt server. A contact with another user is recorded as an “Encounter record” with TempID of both parties, date/time stamp (for 21/28 day lookup), BT signal strength (for distance calculation), Phone model of both parties (different from number, IMEI or similar identifiers).
When someone tests positive, the +ve user uploads his locally stored “encounter records” to the govt server and the message is decrypted, parsed, processed for time and distance and ID resolved at the state end by competent people. They then alert the impacted contact pool of users at risk and advise on next steps.
As we can see from the diagram above, this minimal architecture of “Encounter storage” and “Encounter Message” is sufficient for the govt to identify potential high-risk contacts of an infected user and initiate contact trace / reach out to them. No location is needed or stored since the users can be reached via phone numbers.
The Curious Case of Location in AarogyaSetu
The AarogyaSetu app differs from the Singapore/Australian app in two keyways:
i. It records the GPS location of the user in addition to Bluetooth signal strength at the time of “encounter” with another user.
ii. All “Encounter data” is “uploaded and accessed” by the govt when a user turns COVID +ve. It’s not clear if this is automatic or on user-doing the upload after detecting +ve or encounters are continuously uploaded even for unconfirmed cases.
From published reports, Setu adds location data to the “Encounter message” and stores that in addition to the BT signal, date and time stamp etc. Why? The answer to this lies in Setu’s attempt to become a super app for COVID — in addition to facilitating contract trace for authorities, it wants to become an “alert” mechanism for users to check how many infected people are around them.
To support the query of how much infected / at risk people are around a user (in a radius defined by the user), it is important to store GPS location of the user and the locations of both parties at the time of “encounter”. The Setu team has said that all data of the encounter stays on the local device till someone tests +ve but since the govt is using Setu density to map locations / containment zones, it is not clear if this is the case.
The Setu app maintains heartbeat with the server at 2 sec intervals and exchanges some data. I was able to trace the TCP requests but did not reverse engineer the data packets (they are encrypted anyway).
I installed the AarogyaSetu app and tried to look at the TCP traffic generated by it to see if the encounter records are being sent to the server on its own (as opposed to upload when someone tests positive). Here is what I learnt from my explorations on my iPhone app.
- Pings server every 2 seconds with a Hello
- Server replies back with Hello
- The certificate, server key is exchanged
- Client key exchange, encrypted message is exchanged (most likely Bluetooth)
Setu also informs users of potentially risky contacts at any place based on the self-assessment done by users. It encourages you to take a survey (as per WHO standards) and advises you of the next steps based on your matching of symptoms, travel history etc. Since it uses this information to advise other users of likely risk to them, this information must also be stored on the server every time someone takes a test, along with the GPS location. This information is then used to inform other users on the # of people using the app in your proximity, the # of people not feeling well (as per self-assessment) and the # of +ve cases (after testing, I suppose). This can create privacy issues.
Surveillance Risk from AarogyaSetu
a. Sharing “Where Am I” — the location element of the “encounter records” can inform the govt of a user’s movements and either malicious user or some other agency with access to the server data can trace the same (unless the law prohibits).
b. Sharing “Who Am I meeting” — the location element and the continuous upload of “encounter message” can be used to track who is meeting whom by malicious agents with access to the data.
c. Spread fear and mistrust — Say a user’s location reports a +ve case within 500 m of his/her location. This may spread unnecessary panic and fear in the user and change behavior towards others. A false positive will further exacerbate this ill-will.
One glaring example of this is the dashboard setup by MP government that shows all patients quarantined by Name, location etc. See screenshots below.
d. Uploading “encounter records” on false +ve — if a user is flagged as false +ve on the server, and the server flags the app to upload the data without user permission, it could create panic for the contacts of the said user.
e. Though the govt has said that encounter records will be deleted in 30 days / 60 days (after treatment of a +ve case), there is very little confidence in this assurance. As privacy activists have pointed out, it needs a strong law to ensure compliance.
The credibility of the govt is being doubted given its past poor record on surveillance and attempts to create mass social media tracking apparatus. In the absence of any oversight body, eg a privacy commissioner, what prevents state actors from accessing the records — clearly the development team and the agency won’t be able to prevent the Home Minister from getting the data, should he desire to do so.
AarogyaSetu as an ePass
There is talk about using the app as an ePass. This will require constant update on location of users and self-assessment plus tracking by every point of visit. One can imagine that a surveillance infrastructure can be easily built using the underlying identity data, location data, encounter records, self-assessment etc.
Prof. Sanjiva Prasad at IID has written a detailed blog piece on challenges of using Setu as an ePass. You can read this here — https://www.facebook.com/notes/sanjiva-prasad/a-bridge-too-far/10158141447539509/. His colleagues at IITD, have written a paper rejecting the idea of Setu app as an ePass system. One can read that here — http://www.cse.iitd.ac.in/~suban/reports/apps.pdf?fbclid=IwAR1IM-CNzh292p6jXmTRtEwRYk27QpI0RWwPMG4Qb_fNEsqDRSFCM0HS2_I.
Summary — AarogyaSetu can very much be used as a surveillance tool in spite of the design being dictated by privacy concerns and in spite of having some of the top minds of the nation behind it. The control at the govt end has poor reputation in respecting citizen privacy and past surveillance related tactics makes Setu a powerful weapon in misguided hands.
It would be good for Setu designers to drop the location tracking and create powerful audit tools to see who is accessing the data on the servers and why. The upload of “encounter records” should be changed to after user approves and executes the upload on positive testing.
