Shireen Gupta

Third party data collection — whatever the motivation — has the potential to blur the lines between data privacy and complete identification.

In March 2020, it was revealed that the Zoom iOS app was sending user data to Facebook unbeknownst to the user. The transaction conspired in a manner where Zoom had implemented the ‘login from Facebook’ button on its iOS app, subsequently involving the Facebook Software Development Kit (SDK) in its iOS platform. The implementation of this feature allowed Facebook to access and extract users’ data from Zoom’s platform. Zoom apologised for this incident, claiming that it did not know of such implications while developing the app, further stating that it had rectified its mistake and fixed the app to remove the Facebook SDK.

Even in isolation, this incident seems like an immense problem. But when more about the same theme is explored and unearthed, we come across something called third party data collection; and the Zoom-Facebook debacle was only the tip of the iceberg.

The Personal Data Protection Bill is being challenged on several grounds, including that it creates a surveillance state and does practically nothing to actually protect the data of users. The bill fails to address any tenet or resolve any problem arising from third party data collection. Now is as good a time as any to discuss third party data mining and suggest redressal mechanisms for the same, considering how the bill is to go through another round of consultation before being restructured.

At the outset, it must be established that third party data aggregation and third party data collection are not the same. Third party data aggregation is when a firm or an individual seeks out the services of a third party to put their data into perspective and create a generalised model for efficient ad placement or other purposes, whatever they may be. In aggregation, data remains fairly anonymous and is used in a generalised manner, as opposed to an individualised one.

On the other hand, third party data collection happens when an app, that is not a part of the Facebook or Alphabet family, uses Facebook’s SDK and Google’s AdSense to refine its system and create a better ad target; therefore, giving these third parties access to user data from their own platform. Usually, several smaller developers implement such third party features due to them being technologically sophisticated.

The data that is collected by these third parties can be broken down into two categories:

1. From each app using their systems, the collectors consistently collect the unique ad ID and the phone model name and number of the user;
2. Subjectively, the collectors collect data that is uniquely collected by the primary app for its functioning.

To illustrate this better, we can think of an example: Let’s assume you have three apps on your phone, all of them using Facebook’s SDK. App A is a weather app that collects your location information, app B is a contacts app that collects contact information, and app C is a political-centric app that collects your political beliefs. All of these apps will send Facebook your unique ad ID and your device name and number. Meanwhile, app A will reflect your location information, app B will reflect your contact information and app C will reflect your political belief information. Now, Facebook has these three unique data points with the same unique ad ID and device name and number. Data, as can be inferred, is no longer anonymous. Facebook has a comprehensive picture of you and you didn’t even have the Facebook app on your phone!

Due to how hidden the risks of this collection are, it is not surprising how no explicit laws are designed around holding such collectors and such data collections accountable. While it has been argued that the data collected from such apps are only used to create a better user interface or to portray targeted ads to the users, the risk of completely forgoing privacy in such a collection is glaring and requires immediate remedial action.

Designing policies and laws around such activities, especially concerning liability can be tricky. To begin with, it is, at times, conceded that these third party collectors don’t intentionally try to collect the complete data of any given individual; it is by virtue of app developers and them using the systems of third party collectors that such data is passed on to the latter. However, a check at every crucial step of this collection can be placed to better regulate data and protect the privacy of users. Providing recommendations for prevention and liability in the case of nonobservance is almost always a slippery slope when it comes to data collection, but keeping certain objective goals in mind, a few recommendations for the bill are discussed and noted below.

Recommendations for prevention

1. A subcommittee within the data protection authority (DPA) should be constituted, which should consist of data scientists/mathematicians/computer scientists or general experts in the field. The reason for such a constitution is that liability in these cases of collections is never a straight path and can be decided only on a case-by-case basis. The envisaged subcommittee could deal with serious breaches on a subjective basis and assign liability according to the damages incurred in each such case.
2. Along the lines of the current PDP, a data controller should be mandatory for every company that processes user data. While the current bill calls for such a controller to be provided by the government, the proposed controller could belong to the company itself. The controller is to make sure that the company does regular risk assessments and complies with the norms and laws of the country. He/she is to also make sure that an audit of data is conducted every financial year by the venture, with the audit report being mandatorily submitted to the data protection authority (DPA) discussed earlier. In essence, this controller is to be the liaison between the third party collector and the DPA.
3. For better dissemination of information and transparency between primary developers and third party collectors, the latter must be completely upfront about what kind of data they will be collecting, how the collected data will be processed and what ends the collected and processed data will fulfill. The transparency is to be communicated through the terms and conditions of the products and services provided by third party collectors. In a case where the collection isn’t transparent, the primary developer can file a suit against the third party.
4. To keep the public in the loop about such transactions, the third party collector must make a rolling list of apps that use their systems public domain.
5. Mandatorily, sensitive information such as religious beliefs, bank account details, political beliefs etc. must be blocked from reaching the third party collector. The burden of such blockage must lie with the primary developer.
6. Primary developers are also to be upfront with their users about what kind of data would be collected by the third party and who the third party in question was. Further, primary apps should give their users the freedom to opt out of sending information they don’t want the third party to have.

Objective liabilities

1. At the outset, liability shall lie with third party collectors if they are not transparent with primary developers and don’t abide by the prescribed guidelines.
2. Further, liability shall lie with primary developers if they are not transparent with their users and fail to provide them with an opt out system.

As can be seen from the course of this article, third party collection — whatever the motivation of such collectors might be — has the potential to blur the lines between data privacy and complete identification. The motivation of such companies is rarely known, however, breaches on such collectors is not unheard of, therefore, governments should work towards preventive measures to assure the safety of users while also creating clear liability claims as and when necessary.

Source; Observer Research Foundation