Data Sharing and Access Protocol

Our Analysis of ‘The Aarogya Setu Data Access and Knowledge Sharing Protocol, 2020’

Our Analysis of ‘The Aarogya Setu Data Access and Knowledge Sharing Protocol, 2020’

The Ministry of Electronics and Information Technology (MeitY) released ‘The Aarogya Setu Data Access and Knowledge Sharing Protocol, 2020’ on May 11, 2020. We at SFLC.IN, welcome this step of the Government and express gratitude for considering concerns raised by digital right organisations, individuals, lawyers, public policy professionals and technologists.

In this Protocol, the Government has clarified that the Ministry of Electronics and Information Technology (MeitY) is the agency responsible for the implementation of this Protocol. The National Informatics Center will be the body responsible for collection, processing and managing response data collected by the Aarogya Setu application.

We appreciate that the Protocol has an option for the user to request deletion of its data, and permanent deletion of all data once the Protocol lapses. The Protocol has also followed principles of data proportionality, necessity and limitation. Principles of data sharing have been included, and obligations of entities with whom response data is shared have been chalked out as well. Through this Statement, we would like to throw light on our concerns with the Protocol-

1. Sunset Clause of the Protocol: The Protocol has a sunset clause of 6 month from the date of its notification or earlier as deemed fit by the Empowered Group on Technology. After completion of 6 months, it will be reviewed by the Empowered Group. It is nowhere mentioned that the Sunset clause is also applicable on ‘Aarogya Setu’ indicating that ‘Aarogya Setu’ might outlive the Protocol.

It is also unclear in the absence of the Protocol, how will ‘Aarogya Setu’ be deemed as legally valid considering that it derives its statutory validity through the National Disaster Management Act, 2005.

2. Clarity on Data Retention: Aarogya Setu’s privacy policy specifies that the personal information of users who have been tested positive for COVID-19 will be collected and stored in Government servers for a period of 60 days after such users have been declared cured of COVID-19. However, the Protocol states that the contact, location and self assessment data of an individual will not be retained beyond 180 days. There is no clarity or harmonisation between the privacy policy and the Protocol.

Moreover, the Protocol goes on to state that in case a specific recommendation is made in the review in this regard, the 180 days period may be modified. However, it is not clear on what grounds deviation from 180 days period will be allowed, and if users or data subjects will be asked for consent to retain their data beyond 180 days.

3. “Appropriate Health Responses” too broad a phrase: The Protocol states that the National Informatics Center (NIC) “shall collect only such response data as is necessary and proportionate to formulate or implement appropriate health responses.” The phrase “appropriate health response” is too broad and has not been specified anywhere in the Protocol. This again, goes against the principle of data proportionality and purpose limitation.

4. Deletion of Demographic Data on User’s Request:The Protocol allows a user to delete its demographic data before the 180 day stipulated period. This is a commendable step which was long demanded. However, the Protocol fails to specify the procedure through which a user can make such request.

Also, the deletion of data is only restricted to demographic data. The Protocol is silent on what will happen to contact data, self-assessment data, and location data. Why have the users not been given an option to delete contact data, self-assessment data and location data, if such data will anyway be deleted within 180 days?

5. Maintenance of List of Agencies with whom data will be shared: The Protocol states that “NIC shall, to the extent reasonable, document the sharing of any data and maintain a list of the agencies with whom such data has been shared. Such documentation shall include the time at which such data sharing was initiated, the persons or agencies who are being provided access to such data, the categories of data that are being shared and the purpose for which such data is being shared.”

The phrasing of this provision is interesting as it gives leeway to National Informatics Centre (NIC) to exclude certain agencies from the list and massively undermines the transparency principle.

6. Sharing of Response Data with Third Parties: The Ministry or Department of Government of India or State/Union Territory Government/ local government, NDMA, SDMA or public health institution of the Government of India/State Governments/ local governments will be held responsible for adherence to this Protocol by any other entity with whom such information has been shared.

However, it is not clear that in case of a breach, will the third party be held liable? The Protocol is silent on liability of such third parties in case of a breach or unauthorised use of response data.

7. Closed Source App: Time and again it has been demanded that the App should be made open source in consonance with Government’s Policy on Adoption of Open Source Software. However, the Protocol has not addressed it. Making the source code available enhances transparency and improves security as the source code is open to community audit.

8. Sharing of de- identified data: The Protocol allows sharing of response data in de- identified form with Ministries or Departments of the Government of India or the State/ Union Territory Governments, local governments, NDMA, SDMAs etc. It states that “de-identified form means data which has been stripped of personally identifiable data to prevent the individual from being personally identified through such data and assigned a randomly generated ID”.

It fails to specify if the randomly generated ID will be static or dynamic. In case of a static ID, the de-identified information can be linked back to the personal information. The government should instead use a dynamic ID to minimise risks. 

 

We also did a technical analysis of Aarogya Setu which can be found here. We also wrote to Minister of Railways, Minister of Civil Aviation, and Managing Director, Noida Metro Rail Corporation to consider the installation of Aarogya Setu on voluntary basis in consonance with the Ministry of Home Affairs guidelines dated 17.05.2020.

 

 

 

 

Related Posts