On May 11, 2020 the Ministry of Electronics and Information Technology (MeitY) released the Aarogya Setu Data Access and Knowledge Sharing Protocol, 2020 (“The Protocol”). It revealed the Government of India’s National Executive Committee (“NEC”) has constituted an Empowered Group on Technology and Data Management, which is looking at among other things the development and implementation of the Aarogya Setu. The Protocol is meant to allay concerns of informational privacy and mass surveillance which are attached with the Aarogya Setu programme. However, according to our clause by clause analysis it falls considerably short of principles of legality, necessity and proportionality.
We would like to thank IFF’s off-counsel Vrinda Bhandari; and lawyers Abhinav Sekhri and Gautam Bhatia in helping us unpack the Protocol.
Multiple petitions have been filed before the Kerala High Court against the mandatory imposition of Aarogya Setu. These petitions include one which is filed by Jackson Mathew, in which IFF is offering legal support. A day before hearings on May 11, 2020 the MeitY released the Aarogya Setu Data Access and Knowledge Sharing Protocol, 2020 (“The Protocol”). As highlighted in our update yesterday, about the hearings at the Kerala High Court, highlighted that the Counsel from MeitY insisted that Aarogya Setu was the best app in the world and emphasized that a protocol had also been issued to address privacy concerns. This argument was meant to suggest that the Protocol ring fences the Aarogya Setu app sufficient legal backing and also offers enough safeguards to people’s privacy.
Our analysis also comes in the wake of the Aarogya Setu app being made mandatory to access many essential services and facilities. For instance, in a late night tweet, the Ministry of Railways announced that as passenger trains restart, it will be mandatory for passengers to download the app. Similarly, the Ministry of Civil Aviation has proposed a standard operating procedure (SOP) to restart commercial travel. The proposed SOP reportedly will require all flight passengers to have a “Green Status” on the Aarogya Setu app.
However, as our analysis states (a PDF of which is provided at the end of this document) very clearly states that the Protocol fails to satisfy the legality threshold.
Compatibility with Legality
The Protocol is not a statute, and nor does it offer any legislative foundation for the Aarogya Setu Mobile Application. Therefore, the primary issue of Aarogya Setu lacking legal basis is still alive and unaddressed. For clarity fundamental rights under the Constitution cannot be restricted by the Government even for legitimate purposes without express legislative authorisation. The Protocol is not - and does not purport to provide - any such authorisation. A troubling aspect in this regard, is that Government authorities have said that there are no plans to create an underlying legislation to hold the usage of the app accountable, since the “priority at present is to deal with the epidemic itself.”
Underlying Basis and Rationale of the Order is Questionable
There is also no reference in this Order or any other government notification about the actual membership composition of Empowered Group 9 on Technology and Data Management. In addition, there is no reference in the Protocol or any other government notification about the means through which Empowered Group 9 has sought external inputs on the drafting of the Protocol.
The Protocol is drafted in a manner, which justifies the centralised collection of data through the new Aarogya Setu platform. It does this without any discussion about the choice of design, and why existing alternatives which exist through avenues like telecom operators, or for that matter anonymised mobility reports reports developed in an open source format by researchers and organisations like Facebook/Google, are not enough. There is no discussion on why existing data at the Government’s disposal collected through hospitals, the Indian Council of Medical Research, the Integrated Disease Surveillance Programme, on ground surveillance teams, etc. does not suffice in fulfilling the objective referenced by the Protocol.
The Protocol also fails to acknowledge the fact that when data is collected in a primary fashion from individual users, it is of course a more intrusive collection process. Therefore it comes with inherent risks to informational privacy. Instead the Protocol stresses on the need for efficient data collection and sharing. Unfortunately, there is little to no discussion on ensuring that the most privacy-respecting practices are adopted, which are least intrusive in nature.
In addition the Protocol arbitrarily states that there is an urgent need for data pertaining to individuals “to formulate appropriate health responses for addressing the Covid-19 pandemic”. What is convenient for authorities is that “Appropriate health responses” is expansively defined. In fact such an expansive definition is curious since a think tank which supported the Government of India in drafting the Protocol has stated in an explainer blog post that the purpose of the Protocol is “exposure notification and contact tracing”. If that were indeed the case, then such a broad definition for Appropriate health responses is incompatible with the principle of proportionality.
In contrast, all other apps across the world’s democracies (across the economic and geographical spectrum) are only deploying apps to support/expedite their country’s on-ground contact tracing efforts. In India the app’s expansiveness is being positioned as it speaks to India’s innovation. This would be a disingenuous characterisation. Most other countries are taking their time to ensure that the application of such technologies when ultimately scaled are in fact consistent with their civil liberties obligations.
Therefore, the Protocol is not engaging in data collection through the prism of deploying the least restrictive measure that is hemmed in by clear purpose-based requirements, and is, therefore, falling foul of the proportionality principle.
Concerns About Implementation and Possible Mission Creep
We also believe that the chain of command evokes concerns of possible mission creep. What is especially concerning is that India’s public health institutions have minimal leadership even as these technologies are being built to respond to a public health crisis.
Don’t Just Use Buzzwords Like “Necessary and Proportionate”. Meaningfully Incorporate Them
The use of such phraseology is meant to demonstrate that the Protocol incorporates purpose and use limitations on data collected by the App. However, they are far from restrictive. For example, “Appropriate health responses” is a broad term that covers a wide gamut of government operations. In other words, “purpose limitation” and the principles of necessity and proportionality with respect to data collection acts as a meaningful constraint only if the purpose is spelt out with clarity and specificity to start with. If the purpose itself is excessively broad, vague, and evolving, then “necessity” and “proportionality” have no meaning at all, since data collection needs to be necessary and proportionate with regard to the purpose for which it is being collected. The Protocol, therefore, attempts to do an end run around core data principles by leaving the purpose so vague and ill-defined, that excessive data collection can potentially always be justified as necessary and proportionate.
Further, the Protocol’s reference to the principle for processing data in a “fair, transparent and non-discriminatory manner” rings hollow. Specifically, it does not require the NIC to publicly share its data processing practises. In fact, one way for processing to be transparent is by publishing the app’s underlying source code. Instead, India has not published the Aarogya Setu app’s source code and even now, a recent statement of the Secretary, MeitY indicates a reticence to publish the source code before the public.
Excessive Collection, Processing and Storage of Personal Data
According to the Protocol, the default setting is that contact and location data remain on the device and not uploaded on to the server. This default setting is, however, immediately overridden by the next sentence which states that such data may be uploaded to the server to formulate / implement appropriate health responses. Given the breadth of this purpose, there is, in effect, no clarity or certainty on when contact and location data may be uploaded on the server. Moreover, the breadth of this exemption allows for the seamless creation of a centralised system.
In general the storage policies are high deficient and cannot be aligned with people’s right to privacy, or the proportionality principle:
- Data retention for six months, without any process of review while allowing for potential extension of this time-limit, is not the least intrusive measure that could be adopted. This is because it allows for retaining of people’s personal data for durations beyond the duration of the Protocol itself. Consider the following example. Imagine someone’s contact/location/self assessment data is exported on daya 45. Then that data could be retained for a period of 45 days beyond the purported last date of the Protocol which is fixed at 6 months where this data retention takes place in a legal vacuum.
- The Protocol also fails to clarify what are the extraordinary circumstances in which the Government may unilaterally retain contact, location and self assessment data for a period longer than 180 days.
- There is no policy for destroying contact, location and self assessment data based on a user request, contrary to the Protocol for demographic data. The total failure to consider user-request based destruction of such data amounts to retaining personal data without consent and is a clear breach of the right to privacy.
Researchers Can Get Access to Our Data. Wait? What?
The Protocol allows for sharing response data for research purposes with certain specified institutions / entities registered in India where the data has undergone “Hard Anonymisation”. This demonstrates the incentives for why the Government of India has taken a centralised approach. It is less about taking the least intrusive measure towards responding to the public health crisis, but more towards maximising the utility of data. In some ways it also shows an appetite on the Government of India to commercialise or discover commercial applications the Aarogya Setu app, rather than go the path of other democratic societies which are more focused on decentralised models which may effectively alert people to get tested and treated for the coronavirus itself. That such opportunities would be non-existent in a decentralised model of data storage only further supports the argument that the adoption of a centralised model for the Aarogya Setu App is not driven by purposes related to containing the spread of Covid-19. Additionally, it shows why the data retention limits of the Aarogya Setu programme do not apply to anonymised and aggregated datasets. Therefore, there is a greater need for public scrutiny on this front.
The Sunset Clause Misses the Point
The Sunset Clause (Para 10) fails to adequately address temporal restrictions on the gathering of data by the Aarogya Setu Mobile Application. In fact, the sunset clause potentially allows for gathering such data on even more relaxed terms and conditions. Moreover, the Sunset Clause allows for its extension without any independent institutional review.
Most importantly, the Sunset Clause is insufficient since there is no reference to the actual destruction of servers and systems created as an output of the Aarogya Setu programme. Without such a reference, a sunset clause is meaningless and evokes concerns of the creation of a permanent infrastructure of Government surveillance.
For more, please go through our detailed analysis in which we deconstruct the various shortcomings of the Protocol. At the end we also analyse certain disclosures made by the Government in a press briefing made on the same day, which evoke concerns of interlinking of Government databases and risks of permanent systems of surveillance.