Posted on

iSPIRT’s Official Response to Non-Personal Data Governance Framework

A Committee of Experts under the Chairmanship of Shri. Kris Gopalakrishnan has been constituted vide OM No. 24(4)2019- CLES on 13.09.2019 to deliberate on Non-Personal Data Governance Framework. Based on the public feedback/suggestions, the Expert Committee has revised its earlier report and a revised draft report (V2) has been prepared for the second round of public feedback/suggestions. iSPIRT had provided a past response to the previous report and in this blog post contains a response to the revised report. 

At the iSPIRT Foundation, our view on data laws stems from the following fundamental beliefs: 

  1. Merits of a data democracy (that is, the user must be in charge)
  2. Competitive effects must be well understood, for creation of a level playing field amongst all Indian companies, and some ring-fencing must exist to protect against global data monopolies
  3. Careful design enables both high compliance and high convenience

It is with these perspectives that we have analyzed the revised Non-Personal Data report in our response.

Key Sources of Ambiguity in the NPD Report 

The key sources of ambiguity in the report are: 

  1. Purpose of techo-legal framework for Non Personal Data: The non personal data framework is meant to provide the right legal and technology foundations for world class artificial intelligence to be created out of India for the betterment of financial, health, and other socio-economically important services. The current version of the report sidesteps this completely by constraining the applicability to only “public good” purposes rather than taking a holistic approach to “business & public good purposes” 
  2. Data Business entities need a harmonised definition (given the interplay with data fiduciaries as proposed in the MeitY Personal Data Protection Bill) and clear incentives for participation. The current report relies excessively on regulation & processes for data businesses to achieve the outcome. 
  3. Institutional structure for Data Trustees: The report restricts Data Trustees to government agencies and non-profit organisations; however, in a domain consisting of fast evolving technology by excluding the private sector in offering the base infrastructure creates a severe limitation on the ecosystem of modellers that can be created. 
  4. Technology Architecture: The illustrated technology architecture is unclear around the public infrastructure (through the form of open standards, public platforms, and others) that need to be created & adopted to bring to life the non-personal data ecosystem in an accelerated manner. 

Conclusion

While we’re aligned with the vision of the committee, it’s critical that the above ambiguities are resolved in order to create a strong non-personal data ecosystem created in India. Till these ambiguities are resolved, the recommendations of the Report should not be operationalized.

For any press or further queries, please drop us an email at [email protected]

Posted on

The future of ‘civic’ technologies after COVID-19

In 1973, the British economist Ernst Schumacher wrote his manifesto “Small is Beautiful”, and changed the world. Schumacher’s prescription — to use technologies that were less resource-intensive, capable of generating employment, and “appropriate” to local circumstances — appealed to a Western audience that worried about feverish consumption by the ‘boomer’ generation. Silicon Valley soon seized the moment, presenting modern-day, personal computing as an alternative to the tyranny of IBM’s Big Machine. Meanwhile, in India too, the government asked citizens to embrace technologies suited to the country’s socio-economic life. Both had ulterior motives: the miniaturisation of computing was inevitable given revolutions in semiconductor technology during the sixties and seventies, and entrepreneurs in Silicon Valley expertly harvested the anti-IBM mood to offer themselves as messiahs. The government in New Delhi too was struggling to mass-produce machines, and starved of funds, so asking Indians to “make do” with appropriate technology was as much a political message as it was a nod to environmentalism.

And thus, India turned its attention to mechanising bullock carts, producing fuel from bio-waste, trapping solar energy for micro-applications, and encouraging the use of hand pumps. These were, in many respects, India’s first “civic”, or socially relevant technologies.

The “appropriate technology” movement in India had two unfortunate consequences. The first has been a celebration of jugaad, or frugal innovation. Over decades, Indian universities, businesses and inventors have pursued low-cost technologies that are clearly not scaleable but valued culturally by peers and social networks. (Sample the press coverage every year of IIT students who build ‘sustainable’ but limited-use technologies, that generate fuel from plastic or trap solar energy for irrigation pumps.) Second, the “small is beautiful” philosophy also coloured our view of “civic technologies” as those that only mobilise the citizenry, out into farms or factory floors. Whether they took the form of a hand pump, solar stove or bullock cart, these technologies did little to augment the productivity of an individual. However, they preserved the larger status quo and did not disrupt social or industrial relations as technological revolutions have historically done. 

Nevertheless, there has always been a latent demand in India for technologies that don’t just mobilise individuals but also act as “playgrounds”, creating and connecting livelihoods. When management guru Peter Drucker visited post-Emergency India in 1979, Prime Minister Morarji Desai sold him hard on “appropriate technology”. India, Drucker wrote, had switched overnight from championing big steel plants to small bullock carts. Steel created no new jobs outside the factory, and small technologies did not improve livelihoods. Instead, he argued, India ought to look at the automotive industry as an “efficient multiplier” of livelihoods: beyond the manufacturing plant, automobiles would create new sectors altogether in road building and maintenance, traffic control, dealerships, service stations and repair. Drucker also pointed to the transistor as another such technology. Above all, transistors and automobiles connected Indians to one another through information and travel. Drucker noted during his visit that the motor scooter and radio transistor were in great demand in even far-flung corners, a claim that is borne by statistics. These, then were the civic technologies that mattered, ones that created playgrounds in which many could forge their livelihoods. 

The lionisation of jugaad is an attitudinal problem, and may not change immediately. But the task of creating a new generation of civic technologies that act as playgrounds can be addressed more readily.  In fact, it is precisely during crises such as the ongoing COVID-19 pandemic that India acutely requires such platforms.


Consider the post-lockdown task of economic reconstruction in India, which requires targeted policy interventions. Currently, the Indian government is blinkered to address only two categories of actors who need economic assistance: large corporations with their bottom lines at risk, and at the micro-level, individuals whose stand to lose livelihoods. India’s banks will bail out Big Business, while government agencies will train their digital public goods — Aadhaar, UPI, eKYC etc — to offer financial assistance to individuals. This formulaic approach misses out the vast category of SMEs who employ millions, account for nearly 40% of India’s exports, pull in informal businesses into the supply chain and provide critical products to the big industries.

To be sure, the data to identify SMEs (Income Tax Returns/ GSTN/ PAN) exists, as do the digital infrastructure to effect payments and micro-loans. The funds would come not only from government coffers but also through philanthropic efforts that have gained steam in the wake of the pandemic. However, the “playground” needs to be created — a single digital platform that can provide loans, grants or subsidies to SMEs based on specific needs, whether for salaries, utilities or other loan payments. A front-end application would provide any government official information about schemes applied for, and funds disbursed to a given SME.

Civic technologies in India have long been understood to mean small-scale technologies. This is a legacy of history and politics, which policymakers have to reckon with. The civic value of technology does not lie in the extent to which it is localised, but its ability to reach the most vulnerable sections of a stratified society like India’s. The Indian government, no matter how expansive its administrative machinery is, cannot do this on its own. It has to create “playgrounds” — involving banks, cooperative societies, regulators, software developers, startups, data fiduciaries and underwriting modellers — if it intends to make digital technologies meaningful and socially relevant.  

Please Note: A version of this was first published on Business Standard on 17 April 2020

About the author: Arun Mohan Sukumar is a PhD candidate at the Fletcher School, Tufts University, and a volunteer with the non-profit think-tank, iSPIRT. He is currently based in San Francisco. His book, Midnight’s Machines: A Political History of Technology in India, was published by Penguin Random House in 2019

Posted on

A Great Leap Forward to Transform Fintech: Data Empowerment

India is one of the first nations in the world to kick off Open APIs for consented financial data sharing. And nobody’s heard about it! 

Dear Kickass Financial Product Managers and (current & future) Fintech Entrepreneurs,

Amidst the usual flurry of sensational headlines, you may have missed a quiet announcement a few weeks ago that marked a monumental shift: RBI became the first central bank globally to publish a common technology framework – including detailed APIs – for consent driven data sharing across the entire financial sector (banking, insurance, securities, and investment).

This is a gamechanger for the industry.

Out of context, yet another circular with a good deal of jargon is an easy thing to gloss over. But it turns out this effort is actually a global first: although the UK, EU, Bank of International Settlements (BIS), Canada, and others have begun thoughtful public conversations around Open Banking (e.g. through that famous BIS report making the case, initiatives like PSD2, conferences, and various committees), India is one of the first nations in the world to actually make it a market reality by publishing detailed technical API standards — standards that are quickly being adopted by major banks and others across the financial sector in the country without a mandatory requirement from RBI. It’s not just the supposedly cutting edge banks of Switzerland, the UK, or the US driving fintech innovation: the top leadership of our very own SBI, ICICI, IDFC First, Bajaj Finserv, Kotak, Axis, and other household names have recognised that this is the way forward for the industry, and are breaking through new global frontiers by actually operationalising the powerful interoperable technology framework. Not only are they adopting the APIs, some are also starting to think through the new lending and advisory use cases and products made possible by the infrastructure. We think many new fintech startups should also be considering doing the same.

Why do the APIs Matter?

The world is focusing heavily on data protection and privacy – and rightly so. Securing data with appropriate access controls and preventing unauthorised third-party sharing is critical to protecting individual privacy. But to a typical MSME, portability and control of their data is just as critical as data security to empower them with access to a stream of new and tailored financial products and services. For instance, if an MSME owner could share trusted proof of their business’ regular historic GST payments or receivables invoices digitally with ease, a bank could now offer regular small ticket working capital loans based on demonstrated ability to repay (known as Flow-based lending) rather than just loans backed on collateral. Data sharing can become a tool for individual empowerment and prosperity by enabling many such innovative new solutions.

Operationalising a seamless and secure means to share data across different types of financial institutions – banks, NBFCs, mutual funds, insurance companies, or brokers – requires a common technology framework for data sharing. The published APIs create interoperable public infrastructure (a standard ‘rails’) to be used for consented data sharing across all types of financial institutions. This means that once a bank plugs into the network as an information provider, entities with new use cases can plug in as users of that data without individually integrating with each bank. Naturally, the system is designed such that data sharing occurs only with the data owner’s consent — to ensure that data is used primarily to empower the individual or small business. The MeiTY Consent Framework provides a machine-readable standard for obtaining consent to share data. This consent standard is based on an open standard, revocable, granular (referring to a specific set of data), auditable, and secure. Programmable consent of this form is the natural next innovation of the long terms and conditions legalese that apps typically rely on. RBI has also announced a new type of NBFC – the Account Aggregator – to serve as a consent dashboard for users, and seven new AAs already have in principle licenses. 

The Data Empowerment and Protection Architecture (DEPA) – in one image

In many other nations, market players have either not been able to come together to agree on a common technical standard for APIs, or have not been able to kick off its adoption across multiple competing banks at scale and speed. In countries like the US, data sharing was enabled only through proprietary rails – private companies took the initiative to design their own infrastructure for data sharing which end up restricting players like yourselves from innovating to design new products and services which could benefit people on top of the infra. 

What other kinds of innovative products and services could you build? 

Think of the impact that access to the Google Maps APIs allowed: without them, we would never have seen startups like Uber or Airbnb come to life. Building these consented data sharing APIs as a public good allows an explosion of fintech innovation, in areas such as:

  • New types of tailored flow-based lending products that provide regular, sachet sized loans to different target groups based on GST or other invoices (as described above). 
  • New personal financial management apps which could help consumers make decisions on different financial institutions and products (savings, credit, insurance, etc.) based on historic data and future projections. This could also branch out into improved wealth management or Robo advisory. 
  • Applications that allow individuals to share evidence of financial status (for instance, for a credit card or visa application) without sharing a complete detailed bank statement history of every transaction

…and many others, such as that germ of an idea that’s possibly started taking shape in your mind as you were reading.

In summary

This ecosystem is where UPI was in mid-2016: with firm, interdepartmental, and long term regulatory backing, and at the cusp of operationally taking off. UPI taught us that those who make a bet on the future, build and test early (PhonePe and Google were both at the first ever UPI hackathon!), and are agile enough to thrive in an evolving landscape end up reaping significant rewards. And just as with UPI, our financial sector regulators are to be lauded for thinking proactively and years ahead by building the right public infrastructure for data sharing. RBI’s planning for this began back in 2015! They have now passed the innovation baton onto you — and we, for one, have ambitious expectations.

With warmest regards,

iSPIRT Foundation

I’m Pinging A Few Whatsapp Groups Now, What Else Should I Send Them To Read? 

For any further questions or queries, please reach out to [email protected] and [email protected]

Posted on

iSPIRT Foundation’s Official Response to Union Budget 2019

The budget has some relief for startups, but not an outsized role in the $5 Trillion plan
 
In her first budget presented today by the newly-appointed Finance Minister Nirmala Sitharaman started her speech with strong words stating that “We do not look down on legitimate profit-making. Gone are the days of policy paralysis and license-quota-control regime”. Given the resounding mandate of the people, this government has the political capital to execute a bold budget and this is what the country was expecting. While the vision is bold, the recommendations made by the government were a mixed bag – some solid announcements, but also notable for its omissions.

Startups may, at last, see the end of the dreaded “Angel Tax” that has plagued them since 2012. The creation of an e-verification process and “special administrators” whose permission would be required before an Assessing Officer can begin inquiries against start-ups who have already received orders should extend relief to those who were excluded from the February 2019 circular by DPIIT. This can also solve for section 68 – wrt unexplained cash credits – which was the more onerous section by ensuring verification of investors. Extending the exemption of section 56(2)(viib) to Cat II AIFs also brings parity and greater participation between AIFs. The tax deduction for investments into startups saw relaxations in the holding period (5 to 3 years), reduction in the minimum threshold (50% to 25%) and extending the time period.

In this budget, the government recommitted to its ideal of a less-cash economy. By allowing digital payments to the government, they are essentially legitimizing the use of digital payment methods. Further, by disincentivizing cash withdrawals by applying TDS and mandating digital payment acceptance without charges for firms over turnover Rs 50 Crores, they will further “nudge” users into preferring paying digitally. The approach just provides for a reduction in cost and discourage cash expense. This is hardly a definite fiscal measure for incentivizing digital payment. Most importantly, the government is eating its own dogfood, and starting to make digital payments through a dedicated payments platform to its own MSME suppliers and contractors, not only boosting digital payments but providing a critical lifeline to MSMEs by reducing their working capital requirements. In fact, the government has announced a significant boost to improve the availability of credit to the economy.  This includes providing Rs 70,000 Crore to the banking system, as well as a partial credit guarantee for the purchase of Rs 1 Lakh crore of pooled assets from the NBFC system. These measures should improve the availability of credit to the private sector, and boost growth!  The govt has also announced an amendment to enable all NBFCs to lend against invoices through TReDs. These are steps in the right direction and will free up much-needed working capital for the industrial sector.

It is encouraging to see the government adopt technology to improve convenience and simplification for tax-payers. Currently, there are nearly 40 crore citizens in India with a PAN in contrast to 120 crore Indians with Aadhaar. “Interchangeability of PAN and Aadhaar” was announced by Nirmala Sitaraman which has the potential to increase the tax filing base to all Aadhar holders. The details about implementation are specified as follows. Income Tax Department shall allot PAN to every person who will be filing tax with Aadhaar and currently do not have a PAN. The demographic verification will be carried out using data from the Unique Identification Authority of India (UIDAI). Additionally, citizens who have both PAN and Aadhaar can choose to use either of the options to file their returns. While the move of interoperability clearly seems to increase ease of filing taxes, whether it would also increase the number of tax-payers in informal sectors is still a question that needs examination. Further, understanding the implications of increased data linkage includes the discussion of data security.

What was missing was an indication of “Startup India 2.0” – the new phase of Startup India. The Rs 20,000 Cr Startup Seed Fund wasn’t announced, nor were fresh incentives for investments into VC Funds or startups, rationalisation of ESOP taxation, amongst others. Lowering the LTCG ( Long term capital gain) rate on startups shares, which was alluded to in the Economic Survey, also doesn’t find mention in the Budget. Additionally, there have been no measures to help our startups list in Indian exchanges. Overall, this budget has also not delivered on promoting Rupee Capital Formation which would help local startups wean off volatile foreign capital.

Despite the Economic Survey’s focus on Data as a public good, no significant announcement was made to leverage the Data assets of the country. In the speech about soft power, while Yoga and Artisans rightfully got their place, new-age digital platforms like Aadhaar, BHIM-UPI and India Stack, which are truly world-class, did not see a mention. Recognizing these Digital Public Goods as elements of soft power that can be exported to other countries would also give a massive boost to India’s start-ups in markets abroad.

Reach out to Sanjay Jain ([email protected] ) in case you would like to know more details.

Special thanks to our volunteers Saranya Gopinath, Rakshitha Ram, Siddarth Pai, Tanuj Bhojwani, Sudhir Singh, Sanjay Jain, Nakul Saxena, Sharad Sharma, Karthik KS.
Posted on

Data Empowerment and Protection Architecture Explained – Video

More commonly known as the ‘Consent Layer of the India Stack’, Data Empowerment and Protection Architecture (DEPA) is a new approach, a paradigm shift in personal data management and processing that transforms the currently prevalent organization-centric system to a human-centric system. By giving people the power to decide how their data can be used, DEPA enables the collection and use of personal data in ways that empower people to access better financial, healthcare, and other socio-economically important services in a safe, secure, and privacy-preserving manner.

It gives every Indian control over their data, democratizes access and enables the portability of trusted data between service providers. This architecture will help Indians in accessing better financial services, healthcare services, and other socio-economically important services.The rollout of DEPA for financial data and telecom data is already taking place through Account Aggregators that are licensed by RBI. It covers all asset data, liabilities data, and telecom data.

We, at iSPIRT, organised a learning session on the 18th of May, to give relevant and interested stakeholders a detailed primer on DEPA. We had 60-odd very animated and engaging people in the audience. The purpose of the session was to understand the technological, institutional, market and regulatory architecture of DEPA, it impacts on existing data consuming businesses and how people could contribute to this new data sharing infrastructure that’s being built in India.

The session was anchored by Siddarth Shetty, Data Empowerment And Protection Architecture Lead & Fellow, iSPIRT Foundation (Email – sid@ispirt.in). Please feel free to reach out to him for any queries regarding DEPA.

For other queries, please write to [email protected].

Posted on

#5 What is the Federated PHR Component of the Health Stack?

PHR – Personal Health Record – is a mechanism to access a longitudinal view of a patient’s health history and be able to use it for different purposes. It is a component of the health stack:


It relies on two building blocks – (a) registries, to know the source of the data; and (b) health identifier, to know whom the data belongs to. Separating out the building blocks with each serving singular functions helps design a more scalable and sustainable system. We follow certain principles for both of these building blocks:

1. Registries are master databases with information about different entities in the healthcare ecosystem, for example, of hospitals, doctors, care beneficiaries, etc. There should be checks and balances built to ensure correctness of data (such as digital signatures, audit trails, etc.), and this information should be made accessible for different use cases (through open APIs, and consent). Opening access to this information will have a positive effect of increased demand, thus improving quality and leading to convergence towards singular sources.

2. Health identifier is a mechanism to integrate a patient’s health records. This identifier should incorporate the following features:

  • The identifier need not be unique. This means that a patient should have the ability to create multiple health identifiers for different health records – think of different digital folders for mental health cases and cancer cases (a common practice in the physical world).
  • The power to unify health records should lie with the patient. In the physical world, this would translate to the patient having the right to either keep two folders or merge them into one. The same should be allowed digitally.
  • Patients should be allowed to use any identifier to verify themselves. However, since we are creating an electronic system of health records, it is important that these be digitally verifiable – such as mobile number, email ID or Aadhaar.

3. Electronic consent, as specified by MeitY, is a mechanism to give consent electronically in a manner that follows the ORGANS Principles – Open, Revocable, Granular, Auditable, Notifiable, Secure.

_____________________________________________________________________

With these building blocks in place, we come to features of the PHR architecture:

1. Federated – instead of having a centralised repository of all health records, we propose a federated framework where data resides at the source of generation. This has many benefits – (i) ease of operations, as data is not stored with a single entity (ii) lower costs, as no additional repository is being built (iii) better security, as data is stored at different nodes; and (iv) patient empowerment, as data is being shared directly with the patient.

2. Schema level standardisation – we believe that only standardising the schema without enforcing codification standards (which require a significant behavioural shift) should be sufficient for a number of use cases. Since this standardisation is at an IT systems level, it only requires a one-time mapping and does not require any change in clinical workflows.

3. Health data access fiduciaries – these would be entities that would route the consent and data requests between information users and information providers. In doing so, they would play the role of privacy protection, consent management and user education.

4. Health data vault – this is an option for the patient to store his/ her records in a personal storage space. While most hospitals that capture data continue to store it for a long period of time,  an individual might still choose to store this information separately (for long-term access, trust-deficit between patient and provider, etc.). In such a case, the patient can request a copy of the record to be pushed to his/her health data vault.

_____________________________________________________________________

Proposed architecture:

Workflow:

Patient goes to a healthcare provider. At the time of issuance:

Option 1: patient shares mobile number/ email id/ aadhaar no.
1. Provider authenticates user using one of the digital identifiers
2. (a) Provider sends a link to patient for downloading the report. Patient can later link these records with his/ her HDAF; or
2. (b) Patient can sign up with HDAF and search for provider to link records

Option 2: patient shares HDAF ID
1. Provider links patient records to the HDAF

Post linkage, patient can approve requests from data consumers through the HDAF for different use cases.

_____________________________________________________________________

We believe that building PHR as a public good will enable interesting use cases to come to life, that would together improve the healthcare ecosystem. While we will continue our quest for these, we would love to receive feedback on our thinking! If you work in this space and have comments, or would like to understand how this could help your product, please drop me a line at [email protected].

Posted on

iSPIRT Final Comments on India’s Personal Data Protection Bill

Below represents iSPIRT’s comments and recommendations on the draft Personal Data Protection Bill.  iSPIRT’s overall data privacy and data empowerment philosophy is covered here.  

Table of Contents

Major Comments
1. Include Consent Dashboards
2. Financial Understanding and Informed Consent for all Indians
3. Data Fiduciary Trust Scores Similar to App Store Ratings
4. Comments & Complaints on Data Fiduciaries are Public, Aggregatable Data
5. Warn of Potential Credit and Reputation Hazards
6. A Right to View and Edit Inferred Personal Data
7. Sharing and Processing of Health Data

Suggestions and Questions

  • Fund Data Rights Education
  • Limit Impact Assessment Requirement
  • Passwords should be treated differently than other Sensitive Personal Data.
  • Does the Bill intend to ban automatic person-tagging in photos and image search of people?
  • Notifications about updates to personal data should be handled by a Consent Dashboard, not every data fiduciary.
  • Need for an Authority appeal process when data principal rights conflict
  • Do not outlaw private fraud detection
  • Limit record keeping use and disclosure to the Authority and the company itself.
  • Fillings may be performed digitally
  • Request for Definition Clarifications
  • Author Comments
  • Links
  • Appendix – Sample User Interface Screens

Major Comments

1. Include Consent Dashboards

We support the idea of a Consent Dashboard as suggested in the Data Protection Committee Report (page 38) and recommend it to be incorporated in the Bill in Section 26 – Right to Data Portability and Section 30 (2) Transparency.  

We envision all of a user’s personal and inferred data that is known by data fiduciaries (i.e. companies) being exposed on a consent dashboard, provided by a third party consent collector or account aggregator (to use the RBI’s parlance). Below is an example user interface:

This mandate would enable users to have one place – their consent collector-provided dashboard – to discover, view and edit all data about them. It would also allow users to see any pending, approved and denied data requests.

Furthermore, in the event of data breaches, especially when a user’s password and identifier (mobile, email, etc) have been compromised, the breach and recommended action steps could be made clear on the consent dashboard.

Given the scope of this suggestion, we recommend an iterative or domain specific approach, wherein financial data is first listed in a dashboard limited to financial data and for its scope to grow with time.

2. Financial Understanding and Informed Consent for all Indians

We applaud the Bill’s Right to Confirmation and Access (Chapter IV, Section 24):

The data fiduciary shall provide the information as required under this section to the data principal in a clear and concise manner that is easily comprehensible to a reasonable person.

That said, we’ve found in practice that it’s difficult to appreciate the implications of digital policies on users until real user interfaces are presented to end users and then tested for their usability and understanding. Hence, we’ve put together a set of sample interfaces (see Appendix) that incorporate many of the proposed bill’s provisions and our recommendations. That said, much more work is needed before we can confidently assert that most Indians understand these interfaces and what they are truly consenting to share.

The concepts behind this bill are complicated and yet important. Most people do not understand concepts such as “revocable data access rights” and other rather jargon-filled phrases often present in the discussion of data privacy rights. Hence, we believe the best practices from interface design must be employed to help all Indians – even those who are illiterate and may only speak one of our many non-dominant languages – understand how to control their data.

For example, multi-language interfaces with audio assistance and help videos could be created to aid understanding and create informed consent.  Toll-free voice hotlines could be available for users to ask questions. Importantly, we recognize that the interfaces of informed consent and privacy control need rigorous study and will need to evolve in the years ahead.

In particular, we recommend user interface research in the following areas:

  • Interfaces for low-education and traditionally marginalized communities
  • Voice-only and augmented interfaces
  • Smart and “candy-bar” phone interfaces
  • Both self-serving and assisted interfaces (such that a user can consensually and legally delegate consent, as tax-payers do to accountants).

After user interface research has been completed and one can confidently assert that certain interface patterns can be understood by most Indian adults, we can imagine that templated designs representing best practices are recommended for the industry, much like the design guidelines for credit card products published by US Consumer Financial Protection Bureau or nutritional labelling.

3. Data Fiduciary Trust Scores Similar to App Store Ratings

We support the government’s effort to improve the trust environment and believe users should have appropriate, easy and fast ways to give informed consent & ensure bad actors can’t do well. Conversely, we believe that the best actors should benefit from a seamless UI and rise to the top.

The courts and data auditors can’t be the only way to highlight good, mediocre and bad players. From experience, we know that there will be a continuum of good to bad experiences provided by data fiduciaries, with only the worst and often most egregious actions being illegal.

People should be able to see the experiences of other users – both good and bad – to make more meaningful and informed choices. For example, a lender that also cross-sells other products to loan recipients and shares their mobile numbers may not be engaging in an illegal activity but users may find it simply annoying.

Hence, we recommend that data fiduciary trust scores are informed with user-created negatives reviews (aka complaints) and positive reviews.

In addition to Data Auditors (as the Bill envisions), user created, public ratings will create additional data points and business incentives for data fiduciaries to remain in full compliance with this law, without a company’s data protection assessment being the sole domain of its paid data auditors.

We would note that crowd sourced rating systems are an ever-evolving tech problem in their own right (and subject to gaming, spam, etc) and hence, trust rating and score maintenance may be best provided by multiple market actors and tech platforms.

4. Comments & Complaints on Data Fiduciaries are Public, Aggregatable Data

…so 3rd party actors and civil society can act on behalf of users.

A privacy framework will not change the power dynamics of our society overnight. Desperate people in need of money will often sign over almost anything, especially abstract rights. Additionally, individual citizens will rarely to be able to see larger patterns in the behaviour of lenders or other data fiduciaries and are ill-equipped to fight for small rewards on behalf of their community.  Hence, we believe that user ratings and complaint data about data fiduciaries must be made available in machine-readable forms to not only to the State but to third-parties, civic society and researchers so that they may identify patterns of good and bad behaviour, acting as additional data rights watchdogs on behalf all of us.

5. Warn of Potential Credit and Reputation Hazards

We are concerned about the rise of digital and mobile loans in other countries in recent years. Kenya – a country with high mobile payment penetration and hence like India one that has become data rich before becoming economically rich – has seen more than 10% of the adult population on credit blacklists in 2017; three percent of all digital loans were reportedly used for gambling. These new loan products were largely made possible by digital money systems and the ability of lenders to create automated risk profiles based on personal data; they clearly have the potential to cause societal harm and must be considered carefully.

Potential remedies to widespread and multiple loans are being proposed (e.g. real-time credit reporting services), but the fact that a user’s reputation and credit score will be affected by an action (such as taking out a loan), most also be known and understood by users. E.g. Users need to know that an offered loan will be reported to other banks and if they don’t pay they will be reported and unable to get other loans.

Furthermore, shared usage-based patterns – such as whether a customer pays their bills on time or buys certain types of products – must be available for review by end users.

6. A Right to View and Edit Inferred Personal Data

The Machine Learning and AI community have made incredible strides in computers’ ability to predict or infer almost anything. For example, in 2017, a babajob.com researcher showed the company could predict whether a job seeker earned more or less than Rs 12000 / month with more than 80% accuracy, using just their photo.  She did this using 3000 job seeker photos, 10 lines of code and Google’s TensorFlow for Poets sample code.  Note the project was never deployed or made publicly available.

As these techniques become ever more commonplace in the years to come, it’s reasonable to assume that public facing camera and sensor systems will be able to accurately infer most of the personal data of their subjects – e.g. their gender, emotional state, health, caste, religion, income – and then connect this data to other personally identifiable data such as a photo of their credit card and purchase history. Doing so will improve training data so that systems become even more accurate. In time, these systems – especially ones with large databases of labelled photos – like the governments’, popular social networks’ or a mall’s point of sale + video surveillance system – truly will be able to precisely identify individuals and their most marketable traits from any video feed.

Europe’s GDPR has enshrined the right for people to view data inferred about them, but in conjunction with the idea of a third party consent dashboard or Account Aggregator (in the RBI’s case), we believe we can do better.

In particular, any entity that collects or infers data about an individual that’s associated with an identifier such as an email address, mobile, credit card, or Aadhaar number should make that data viewable and editable to end users via their consent dashboard.  For example, if a payment gateway provider analyses your purchase history and infers you are diabetic and sells this information as a categorization parameter to medical advertisers, that payment gateway must notify you that it believes you are diabetic and enable you to view and remove this data. Google, for example, lists these inferences as Interests and allows users to edit them:

Using the Consent Dashboard mentioned in Major Comment 1, we believe users should have one place where they can discover, view and correct all personal and inferred data relevant to them.

Finally, more clarity is needed regarding how data gathered or inferred from secondary sources should be regulated and what consent may be required. For example, many mobile apps ask for a user’s consent to read their SMS Inbox and then read their bank confirmation SMSs to create a credit score. From our view, the inferred credit score should be viewable by the end user before it’s shared, given its personal data that deeply affects the user’s ability to gain usage of a service (in this case, often a loan at a given interest rate).

7. Sharing and Processing of Health Data

The Bill requires capturing the purpose for data sharing:

Chapter II, point 5:

“Purpose limitation.— (1) Personal data shall be processed only for purposes that are clear, specific and lawful. (2) Personal data shall be processed only for purposes specified or for any other incidental purpose that the data principal would reasonably expect the personal data to be used for, having regard to the specified purposes, and the context and circumstances in which the personal data was collected.”

In the healthcare domain, collecting the purpose for which the data is being shared might itself be quite revealing. For example, if data is being shared for a potential cancer biopsy or HIV testing, the purpose might be enough to make inferences and private determinations about the patient and say deny insurance coverage. On the other hand, stating high-level, blanket purposes might not be enough for future audits. A regulation must be in place to ensure the confidentiality of the stated purpose.  

The Bill has a provision for processing sensitive personal data for prompt action:

Chapter IV, point 21:

“Processing of certain categories of sensitive personal data for prompt action. — Passwords, financial data, health data, official identifiers, genetic data, and biometric data may be processed where such processing is strictly necessary— (a) to respond to any medical emergency involving a threat to the life or a severe threat to the health of the data principal; (b) to undertake any measure to provide medical treatment or health services to any individual during an epidemic, outbreak of disease or any other threat to public health; or (c) to undertake any measure to ensure safety of, or provide assistance or services to, any individual during any disaster or any breakdown of public order.”

While this is indeed a necessity, we believe that a middle ground could be achieved by providing an option for users to appoint consent nominees, in a similar manner to granting power of attorney. In cases of emergency, consent nominees such as family members could grant consent on behalf of the user. Processing without consent could happen only in cases where a consent nominee is unavailable or has not been appointed. This creates an additional layer of protection against misuse of health data of the user.

Suggestions and Questions

Fund Data Rights Education

We believe a larger, public education program may be necessary to educate the public on their data rights.

Limit Impact Assessment Requirement

Section 33 – Data Protection Impact Assessment —

  • Where the data fiduciary intends to undertake any processing involving new technologies or large scale profiling or use of sensitive personal data such as genetic data or biometric data, or any other processing which carries a risk of significant harm to data principals, such processing shall not be commenced unless the data fiduciary has undertaken a data protection impact assessment in accordance with the provisions of this section. …
  • On receipt of the assessment, if the Authority has reason to believe that the processing is likely to cause harm to the data principals, the Authority may direct the data fiduciary to cease such processing or direct that such processing shall be subject to such conditions as may be issued by the Authority.

We believe that the public must be protected from egregious data profiling but this provision does not strike an appropriate balance with respect to innovation. It mandates that companies and other researchers must ask government permission to innovate around large scale data processing before any work, public deployments or evidence of harm takes place. We believe this provision will be a large hinderance to experimentation and cause significant AI research to simply leave India. A more appropriate balance might be to ask data fiduciaries to privately create such an impact assessment but only submit to the Authority for approval once small scale testing has been completed (with potential harms better understood) and large scale deployments are imminent.

Passwords should be treated differently than other sensitive personal data.

Chapter IV – Section 18. Sensitive Personal Data. Passwords are different than other types of Sensitive Personal Data, given that they are a data security artifact, rather than a piece of data that is pertinent to a person’s being. We believe that data protection should be over-ridden in extraordinary circumstances without forcing companies to provide a backdoor to reveal passwords. We fully acknowledge that it is useful and sometimes necessary to provide backdoors to personal data – e.g. one’s medical history in the event of a medical emergency – but to require such a backdoor for passwords would likely introduce large potential security breaches throughout the entire personal data ecosystem.  

Does the Bill intend to ban automatic person-tagging in photos and image search of people?

Chapter I.3.8 – Biometric Data – The Bill defines Biometric Data to be:

“facial images, fingerprints, iris scans, or any other similar personal data resulting from measurements or technical processing operations carried out on physical, physiological, or behavioural characteristics of a data principal, which allow or confirm the unique identification of that natural person;”

The Bill includes Biometric Data in its definition of Sensitive Personal Data (section 3.35) which may only be processed with explicit consent:

Section 18. Processing of sensitive personal data based on explicit consent. — (1) Sensitive personal data may be processed on the basis of explicit consent

From our reading, we can see a variety of features available today around image search and person tagging being disallowed based on these provisions. E.g. Google’s image search contains many facial images which have been processed to enable identification of natural persons. Facebook’s “friend auto-suggestion” feature on photos employs similar techniques. Does the Bill intend for these features and others like them to be banned in India? It can certainly be argued that non-public people have a right to explicitly consent before they are publicly identified in a photo but we feel the Bill’s authors should clarify this position. Furthermore, does the purpose of unique identification processing matter with respect to its legality?  For example, we can imagine mobile phone-based, machine learning algorithms automatically identifying a user’s friends to make a photo easier to share with those friends; would such an algorithm require explicit consent from those friends before it may suggest them to the user?

Notifications about updates to personal data should be handled by a Consent Dashboard, not every data fiduciary.

Chapter IV – Section 25.4 – Right to correction, etc

Where the data fiduciary corrects, completes, or updates personal data in accordance with sub-section (1), the data fiduciary shall also take reasonable steps to notify all relevant entities or individuals to whom such personal data may have been disclosed regarding the relevant correction, completion or updating, particularly where such action would have an impact on the rights and interests of the data principal or on decisions made regarding them.

We believe the mandate on a data fiduciary to notify all relevant entities of a personal data change is too great a burden and is better performed by a consent dashboard, who maintains which other entities have a valid, up-to-date consent request to a user’s data. Hence, upon a data change, the data fiduciary would update the consent dashboard of the change and then the consent dashboard would then notify all other relevant entities.

It may be useful to keep the user in this loop – so that this sharing is done with their knowledge and approval.

Need for an Authority appeal process when data principal rights conflict

Section 28.5 – General conditions for the exercise of rights in this Chapter. —  

The data fiduciary is not obliged to comply with any request made under this Chapter where such compliance would harm the rights of any other data principal under this Act.

This portion of the law enables a data fiduciary to deny a user’s data change request if it believes doing so would harm another data principal. We believe it should not be up to the sole discretion of the data fiduciary to determine which data principal rights are more important and hence would like to see an appeal process to the Data Protection Authority made available if a request is refused for this reason.

Do not outlaw private fraud detection

Section 43.1 Prevention, detection, investigation and prosecution of contraventions of law

(1) Processing of personal data in the interests of prevention, detection, investigation and prosecution of any offence or any other contravention of law shall not be permitted unless it is authorised by a law made by Parliament and State Legislature and is necessary for, and proportionate to, such interests being achieved.

We worry the above clause would effectively outlaw fraud detection research, development and services by private companies in India. For instance, if a payment processor wishes to implement a fraud detection mechanism, they should be able to do so, without leaving that task to the State.  These innovations have a long track record of protecting users and businesses and reducing transaction costs. We recommend a clarification of this section and/or its restrictions to be applied to the State.

Limit record keeping use and disclosure to the Authority and the company itself.

Section 34.1.a. Record – Keeping –

The data fiduciary shall maintain accurate and up-to-date records of the following

(a) important operations in the data life-cycle including collection, transfers, and erasure of personal data to demonstrate compliance as required under section 11;

We expect sensitive meta-data and identifiers will need to be maintained for the purposes of Record Keeping; we suggest that this Record Keeping information be allowed but its sharing limited only to this use and shared only with the company, its Record Keeping contractors (if any) and the Authority.

Fillings may be performed digitally

Section 27.4 – Right to be Forgotten

The right under sub-section (1) shall be exercised by filing an application in such form and manner as may be prescribed.

The Bill contains many references to filing an application;  we’d suggest a definition that is broad and includes digital filings.

This also applies to sections which include “in writing” – which must include digital communications which can be stored (for instance, email).

Request for Definition Clarifications

What is “publicly available personal data”?

  • Section 17.2.g – We believe greater clarity is needed around the term “publicly available personal data.“ There questionably obtained databases for sale that list the mobile numbers and addresses of millions of Indians – would there thus be included as a publicly available personal data?
  • We’d recommend that DPA defines rules around what is publicly available personal data so that it is taken out of the ambit of the bill.  
  • The same can be said for data where there is no reasonable expectation of privacy (with the exception that systematic data collection on one subject cannot be considered to be such a situation)

Clarity of “Privacy by Design”

Section 29 – Privacy by Design

Privacy by Design is an established set of principles (see here and in GDPR) and we would like to see the Bill reference those patterns explicitly or use a different name if it wishes to employ another definition.

Define “prevent continuing disclosure”

Section 27.1 – Right to be Forgotten

The data principal shall have the right to restrict or prevent continuing disclosure of personal data by a data fiduciary…

We request further clarification on the meaning of  “prevent continuing disclosure” and an example use case of harm.

Define “standard contractual clauses” for Cross-Border Transfers

Section 41.3.5 – Conditions for Cross-Border Transfer of Personal Data

(5) The Authority may only approve standard contractual clauses or intra-group schemes under clause (a) of sub-section (1) where such clauses or schemes effectively protect the rights of data principals under this Act, including in relation with further transfers from the transferees of personal data under this subsection to any other person or entity.

We would like to standard contractual clauses clearly defined.

Define “trade secret”

Section 26.2 C – Right to be Forgotten

compliance with the request in sub-section (1) would reveal a trade secret of any data fiduciary or would not be technically feasible.

We request further clarification on the meaning of  “trade secret” and an example of the same.

Author Comments

Compiled by iSPIRT Volunteers:

  • Sean Blagsvedt – sean _@_ blagsvedt.com
  • Siddharth Shetty – siddharth _@_ siddharthshetty.com
  • Anukriti Chaudhari – anukriti.chaudhari _@_ gmail.com
  • Sanjay Jain – snjyjn _@_ gmail.com

Links

Comments and feedback are appreciated. Please mail us at [email protected].

Appendix – Sample User Interface Screens

Link: https://docs.google.com/presentation/d/1Eyszb3Xyy5deaaKf-jjnu0ahbNDxl7HOicImNVjSpFY/edit?usp=sharing

******

Posted on

Why the SC ruling on ‘Private Players’ use of Aadhaar doesn’t say what you think it does

On behalf of iSPIRT, Sanjay Jain recently published an opinion piece regarding the recent supreme court judgement on the validity of Aadhaar. In there, we stated that section 57 had been struck down, but that should still allow some usage of Aadhaar by the private sector. iSPIRT received feedback that this reading may have been incorrect and that private sector usage would not be allowed, even on a voluntary basis. So, we dug deeper, and analyzed the judgement once again, this time trying to disprove Sanjay’s earlier statement. So, here is an update:

Section 57 of the Aadhaar act has NOT been struck down!

Given the length of the judgement, our first reading – much like everyone else’s was driven by the judge’s statement and confirmed by quickly parsing the lengthy judgement. But in this careful reanalysis, we reread the majority judgement at leisure and drilled down into the language of the operative parts around Section 57. Where ambiguities still remain, we relied on the discussions leading up to the operative conclusions. Further, to recheck our conclusions, we look at some of the other operative clauses not related to Section 57. We tested our inference against everything else that has been said and we looked for inconsistencies in our reasoning.

Having done this, we are confident in our assertion that the judges did not mean to completely blockade the use of Aadhaar by private parties, but merely enforce better guardrails for the protection of user privacy. Let’s begin!

Revisiting Section 57

Here is the original text of section 57 of the Aadhaar Act

Nothing contained in this Act shall prevent the use of Aadhaar number for establishing the identity of an individual for any purpose a purpose backed by law, whether by the State or any body corporate or person, pursuant to any law, for the time being in force, or any contract to this effect:

Provided that the use of Aadhaar number under this section shall be subject to the procedure and obligations under section 8 and Chapter VI.

Now, let us simply read through the operating part of the order with reference to Section 57, ie. on page 560. This is a part of paragraph 447 (4) (h). The judges broke this into 3 sections, and mandated changes:

  1. ‘for any purpose’ to be read down to a purpose backed by law.
  2. ‘any contract’ is not permissible.
  3. ‘any body corporate or person’ – this part is struck down.

Applying these changes to the section, we get:

Nothing contained in this Act shall prevent the use of Aadhaar number for establishing the identity of an individual for any purpose a purpose backed by law, whether by the State or any body corporate or person, pursuant to any law, for the time being in force, or any contract to this effect:

Provided that the use of Aadhaar number under this section shall be subject to the procedure and obligations under section 8 and Chapter VI.

Cleaning this up, we get:

Nothing contained in this Act shall prevent the use of Aadhaar number for establishing the identity of an individual pursuant to any law, for the time being in force:

Provided that the use of Aadhaar number under this section shall be subject to the procedure and obligations under section 8 and Chapter VI.

It is our opinion that this judgement does not completely invalidate the use of Aadhaar by private players, but rather, specifically strikes down the use for “any purpose [..] by any body corporate or person [..] (under force of) any contract”. That is, it requires the use of Aadhaar be purpose-limited, legally-backed (to give user rights & protections over their data) and privacy-protecting.

As an exercise, we took the most conservative interpretation – “all private use is struck down in any form whatsoever” – and reread the entire judgement to look for clues that support this conservative view.

Instead, we found that such an extreme view is inconsistent with multiple other statements made by the judges. As an example, earlier discussions of Section 57 in the order (paragraphs 355 to 367). The conclusion there – paragraph 367 states:

The respondents may be right in their explanation that it is only an enabling provision which entitles Aadhaar number holder to take the help of Aadhaar for the purpose of establishing his/her identity. If such a person voluntary wants to offer Aadhaar card as a proof of his/her identity, there may not be a problem.

Some pointed out that this is simply a discussion and not an operative clause of the judgement. But even in the operative clauses where the linking of Aadhaar numbers with bank accounts and telecom companies is discussed, no reference was made to Section 57 and the use of Aadhaar by private banks and telcos.

The court could have simply struck down the linking specifically because most banks and telcos are private companies. Instead, they applied their mind to the orders which directed the linking as mandatory. This further points to the idea that the court does not rule out the use of Aadhaar by private players, it simply provides stricter specifications on when and how to use it.

What private players should do today

In our previous post, we had advised private companies to relook at their use of Aadhaar, and ensure that they provide choice to all users, so that they can use an appropriate identity, and also build in better exception handling procedures for all kinds of failures (including biometric failures).

Now, in addition to our previous advice, we would like to expand the advice to ask that each company look at how their specific use case draws from the respective acts, rules, regulations and procedural guidelines to ensure that these meet the tests used by this judgement. That is, they contain adequate justification and sufficient protections for the privacy of their users.

For instance, banks have been using Aadhaar eKyc to open a bank account, Aadhaar authentication to allow operation of the bank accounts, and using the Aadhaar number as a payment address to receive DBT benefits. Each of these will have to be looked at how they derive from the RBI Act and the regulations that enable these use cases.

These reviews will benefit from the following paragraphs in the judgement.

The judgement confirmed that the data collected by Aadhaar is minimal and is required to establish one’s identity.

Paragraph 193 (and repeated in other paras):

Demographic information, both mandatory and optional, and photographs does not raise a reasonable expectation of privacy under Article 21 unless under special circumstances such as juveniles in conflict of law or a rape victim’s identity. Today, all global ID cards contain photographs for identification alongwith address, date of birth, gender etc. The demographic information is readily provided by individuals globally for disclosing identity while relating with others and while seeking benefits whether provided by government or by private entities, be it registration for citizenship, elections, passports, marriage or enrolment in educational institutions …

The judgement has a lot to say in terms of what the privacy tests should be, but we would like to highlight two of those paragraphs here.

Paragraph 260:

Before we proceed to analyse the respective submissions, it has also to be kept in mind that all matters pertaining to an individual do not qualify as being an inherent part of right to privacy. Only those matters over which there would be a reasonable expectation of privacy are protected by Article 21…

Paragraph 289:

‘Reasonable Expectation’ involves two aspects. First, the individual or individuals claiming a right to privacy must establish that their claim involves a concern about some harm likely to be inflicted upon them on account of the alleged act. This concern ‘should be real and not imaginary or speculative’. Secondly, ‘the concern should not be flimsy or trivial’. It should be a reasonable concern…

Hence, the privacy risk in these use cases must be evaluated in terms of the data in the use case itself, as well as in relation to biometrics, and the Aadhaar number in the context of the user’s expectations, and real risks. Businesses must evaluate their products, and services – particularly those which use Aadhaar for privacy risks. It is helpful that the UIDAI has provided multiple means of mitigating risks, in the form of Registered Devices, Virtual Ids, Tokenization, QR Codes on eAadhaar, etc. which must be used for this purpose.

What private players should do tomorrow

In the future, the data protection bill will require a data protection impact assessment before deploying large scale systems. It is useful for businesses to bring in privacy and data protection assessments early in their development processes since it will help them better protect their users, and reduce potential liability.

This is a useful model, and we would hope that, in light of the Supreme Court judgement, the Government will introduce a similar privacy impact review, and provide a mechanism to regulate the use of Aadhaar for those use cases, where there are adequate controls to protect the privacy of the users and to prevent privacy harms. Use cases, and an audit/enforcement mechanism matter more than whether the entity is the state, a public sector organization, or a private sector organization.

Note: This is in continuation of Sanjay Jain’s previous op-ed in the Economic Times which is available here and same version on the iSPIRT blog here.

The writer is currently Partner, Bharat Innovation Fund, and Chief Innovation Officer at the Centre for Innovation, Incubation and Entrepreneurship, IIM Ahmedabad. As a volunteer at iSPIRT, he helped define many of the APIs of the India Stack.  He was the Chief Product Manager of UIDAI till 2012

(Disclaimer: This is not legal advice)

Posted on

How To Empower 1.3 Billion Citizens With Their Data

2018 has been a significant year in our relationship with Data. Globally, the Cambridge Analytica incident made people realise that democracy itself can be vulnerable to data.  Closer to home, we got a first glimpse at the draft bill for Privacy by the Justice Sri Krishna Committee.

The writing on the wall is obvious. We cannot continue the way we have. This is a problem at every level – Individuals need to be more careful with whom they share their data and data controllers need to show more transparency and responsibility in handling user data. But one cannot expect that we will just organically shift to a more responsible, transparent, privacy-protecting regime without the intervention of the state. The draft bill, if it becomes law, will be a great win as it finally prescribes meaningful penalties for transgressions by controllers.

But we must not forget that the flip side of the coin is that data can also help empower people. India has much more socio-economic diversity than other countries where a data protection law has been enacted. Our concerns are more than just limiting the exploitation of user data by data controllers. We must look at data as an opportunity and ask how can we help users generate wealth out of their own data. Thus we propose, that we should design an India-specific Data Protection & Empowerment Architecture (DEPA). Empowerment & Protection are neither opposite nor orthogonal but co-dependent activities. We must think of them together else we will miss the forest for the trees.

In my talk linked below which took place at IDFC Dialogues Goa, I expand more on these ideas. I also talk about the exciting new technology tools that actually help us realise a future where Data can empower.

I hope you take away something of value from the talk. The larger message though, is that it is still early days for the internet. We can participate in shaping its culture, maybe even lead the way, instead of being passive observers. The Indian approach is finding deep resonance globally, and many countries, developing as well as developed, are looking to us for inspiration on how to deal with their own data problem. But it is going to take a lot more collaboration and co-creation before we get there. I hope you will join us on this mission to create a Data Democracy.