A rant on Aadhaar

I’m going to preface this by stating that this is an intensely personal opinion, coloured by my experiences working on identity projects over the years.

Over the weekend I addressed a seminar of faculty and students at an engineering college, urging more civic participation in policy making. The speaker following me was a UIDAI official, who described the inevitability of Aadhaar in language that, to me, sounded like we were headed for a police/surveillance state. I tried raising my concerns, but he brushed me aside. “The problems are not serious. The technology will improve.”

I haven’t been able to rest easy since. I tweeted yesterday:

This needed clarification, so I followed up:

I’m going to explain my concerns with Aadhaar, but given how thoroughly misinformed most people are, I’m going to start with context. Be warned, this context is coloured by my experiences.

The good

First, I know many of the people behind Aadhaar. I’ve spoken to them over many years on Aadhaar and on various other things. I’ve known some of them for way longer than Aadhaar existed. I do not doubt their sincerity or integrity in their stated mission, nor do I doubt their technical competence. Unlike many of Aadhaar’s detractors, I do not believe these people intend to create a surveillance apparatus. They are as privacy conscious as any of us, if not more, and it’s come through in multiple conversations. They have been kind enough to host me for an in-person technical deep-dive and ask-anything session, speaking frankly about their intentions and fears. However, they are actors in a mere sub-plot in a larger narrative, a narrative that they are not the authors of. I have no doubt they are aware of this, and the problems of the larger narrative bother them as much as they bother us, even if they are not free to admit this in public.

The background

Second—and this is the long part—my own work experiences. In 2006 I joined a firm named Comat (now defunct), hoping to learn something about writing software for Indian users, users I could actually meet and observe the difference my code made to their lives. That year Comat bagged two major government contracts. One, to computerise the Public Distribution System (PDS aka ration cards) for the Food and Civil Supplies department in Karnataka, and two, to deploy a network of 800 computer “telecentres” across Karnataka (known as “common service centres” today), a rural analogue to the already-running Bangalore One urban centres. I spent a few months working on the first project before finding myself appointed the technical head of the second.

My boss at the time was a friend who had recruited me. Within our circle of friends, he was the conspiracy theorist. Some of it rubbed off. One of his theories was on the Indian civil services. He pointed out they were a derivative of the British Raj-era civil services, where the collector was a white man, legally superior to the natives. Post independence, everyone had equal rights, so the civil servant’s position of authority was somewhat diminished. They couldn’t simply expect compliance anymore. This meant a freshly minted IAS officer had to quickly learn to be the ultimate bad-ass if they hoped to survive a rural stint. It helped that the e-governance secretary we reported to was a foul-mouthed man who commanded fear and compliance by humiliating anyone who stood in his way. People I know who worked for him fled the first chance they got (including my boss). This picture is the only time ever I saw him supplicant, in the presence of his political masters on our launch day:

Originally posted on Flickr

But my boss had more to his theory. The post-independence imbalance of power meant that anywhere a petty official had discretionary authority, there was corruption, and superiors who knew of this corruption weren’t sufficiently empowered to check it. You couldn’t haul up anyone without a paper trail. The corrupt had rights, after all. (This article from The Economist is an excellent briefing.) For example, in Karnataka, agricultural land records are maintained by the state. A farmer who wants to obtain a copy of their land title, to take to the bank to obtain a crop loan, has to get it from the local village accountant, whose seal and signature makes the paper an official record. When the Bhoomi project computerised the land records system, the record was printed from a computer database, but the accountant’s authority position remained: he or she still had to sign the paper. As the signature still demanded a fee, computerisation didn’t actually solve the corruption problem. The Secretary’s solution was to require all village accountants to sign blank paper before they were printed on. Any accountant who didn’t comply would receive a phone call bearing the choicest expletives.

Scaling up

You can see that this doesn’t scale. The Secretary couldn’t possibly do this all the time. There was no legal authority to punish without due process. The Revenue Department’s next project, Rural Digital Services, which aimed to offer many more services over a computer interface, came up with an ingenious solution. All service requests would be processed strictly in First In First Out order. If an official dithered on processing a file, they couldn’t move on to the next. (The technical implementation of this FIFO queue caused us many months of nightmares, but that is another story.)

Everything about the design of e-governance projects was top-down like this. Petty officials were corrupt, and a scary boss wouldn’t always be available, so systems had to be designed to remove their wiggle room. One instance of this hit me particularly hard:

For the ration card project, I invented a paper and transparency-based crypto system using Visual Cryptography. Naor and Shamir’s 2-share method (as in the Wikipedia illustration) has exactly two pieces. I invented a multiplexing system that allowed for 60 keys and 5000 ration cards, those numbers being the number of months we had a contract for (five years), and the maximum catchment size of each ration shop. Every month the shop would receive a new transparency “key” and by placing it on the beneficiary’s ration card, they’d see a unique code that had to be noted in a register. By verifying this register, we’d know if the shopkeeper had actually seen the ration card when they claimed to have disbursed rations. No computers were required at the ration shop. Needless to say, I was pleased as punch. (The idea of using visual crypto wasn’t mine, but the invention and implementation was.)

The pleasure lasted until I had some uncomfortable questions. My crypto model meant that a ration card was tied down to a single shop. What if a family relocated? What if a family didn’t like a shopkeeper and wanted to pick up their rations elsewhere? I had built a lock explicitly designed to prevent this. To change shops, a family had to get a new card, with all the associated costs and hassles. Horrified, I went to my CEO, who pointed out that (a) the government’s Call for Proposals did not require portability, and (b) as the winning bid we were now committed to building what we promised.

My scheme went to trial in a few taluks. Then the government fell and the new government changed all the bureaucrats and the new chap decided ration cards should be chip-based smartcards (like your chip-based debit card is today). It didn’t matter that the state was unable to guarantee electricity to make those smartcard machines work. A few years later, Aadhaar-based biometric fingerprint scanners became the new thing, but we’re getting ahead of ourselves. Aadhaar didn’t exist yet.

My only contribution to the food and civil supplies project was this crypto system. I moved on to the telecentre project where our first service was letting rural citizens receive authoritative copies of their own land records from the government’s Bhoomi database.

(Edit: Needless to say, rolling your own crypto is a terrible idea. Don’t do it. I could see flaws in my scheme even before we went to trial. The big lesson here is that it was approved before being tested, and perhaps thankfully didn’t exist long enough to have its flaws exposed publicly.)

Telecentres

This section is a long tangent, but it’s a relevant insight, so bear with me.

Operators employed by us in these telecentres would open their web browser, navigate to the government website, take a print-out of the land record, and collect cash (₹15) from the customer for this service. To prevent them from taking two print-outs while only reporting one (petty corruption, yay!), the print happened through a purpose-built ActiveX control, which meant we could only use Internet Explorer 6 on Windows XP. Because a printer can still jam and fail, “waste paper” had to be kept aside and submitted to the government for a refund. Because this meant the possibility of fake waste paper, specially watermarked paper was obtained via a separate contract.

The supply chain of this “special” A4 paper was yet another nightmare. At one time the supplier even declared they’d go bankrupt if they kept supplying, meaning we were expected to pay under the table for what was contractually the government’s obligation to supply—and what was functionally plain A4 paper. (For good measure, the printout became a legal certificate only when a hologram was affixed, which meant another contractual supplier. At least the village accountants signed blank paper in advance.)

Every day we submitted cash collections and waste paper to the government, and every month they paid us commissions based on the month’s transaction volume. But how much did we actually sell? Our data source was semi-literate villagers who could easily pocket cash if they under-reported. The government’s data source was the ActiveX widget they supplied, which they held us to account with. Using their data as the authoritative source made sense, so we asked for it and they agreed. Except, nowhere in the contract was there a provision for them to supply us with the data. That had simply been missed—as operators of the telecentres, we were supposed to know our own business, after all.

The arrangement we finally arrived at was that a sysadmin in the data centre would post a database dump every day in a public web folder named “BESCOMLogs”. It contained files from other such agreements that we were not supposed to download. (BESCOM is the Bangalore Electric Supply Company, an entirely unrelated entity. I never learnt why we used a folder named for them.) We took our dump file, imported it into SQL Server, and ran our reports on it. The medical report leak BuzzFeed reported this week was an accident of negligence. Our public dump was fully intentional, operating for years on the basis of everyone involved hushing up. It contained full data of every rural land record database query made anywhere in the state. We had to do this to close the gap in an otherwise legit operation. Of course I was appalled, but the sysadmins in the data centre called the shots on what they’d do for us and how they’d do it.

Our operation was a fragile coalition of five or six service providers, each responsible for an aspect of the operation and trying their best to pass the buck. Compliance was achieved by threatening to call for a meeting with the Secretary, which guaranteed turning the defiant party into a quivering, humiliated slob.

This is the tragedy of the waterfall approach to government software projects, where a watertight contract with a glaring omission like this results in a band-aid solution schemed up by someone insufficiently competent for the task, and no one dares speak up because it will derail everything. You want open source in government? Few are ideologically opposed, but they’d rather have you not poking around in their operations. Because these band-aids are everywhere.

Solving at scale

UIDAI skirted around the waterfall design pattern of government tenders by having a core team of volunteers. The rules only apply when money is involved. UIDAI has shown considerable tact with avoiding various government project pitfalls. I have to grudgingly admit respect for this cleverness, especially when it comes across as circumvention of due process. But we’re getting ahead of ourselves again.

While I was setting up telecentre operations, my colleagues in the food project were issuing new ration cards. As rations are subsidised by the state (ie, the taxpayer), and the state is obliged to do this under our socialist constitution, the state would very much like to keep a lid on the bill by preventing pilferage and fraud. That means everyone in the supply chain is a suspect, and so are the beneficiaries. Schemes like my crypto setup (one of many mechanisms) kept a tab on the supply chain. What about beneficiaries? How do you prevent someone from holding two ration cards and receiving twice the rations?

We turned to—you guessed it—biometrics! If we took the fingerprints of every beneficiary in the state and cross-checked them with everyone already enrolled, we’d catch the people trying to enrol again. In the process we also discovered all the pitfalls of fingerprint biometrics. Some people, especially tobacco workers, have fingers too worn out to take prints. Matching algorithms aren’t perfect and have too many false positives or false negatives, so a second factor was necessary. We settled on iris scans.

To scan an iris, you need a decent camera that connects to a computer. 2006-era webcams required good light. LED lights of the era were too feeble. Other types of lights couldn’t run off batteries for the scale at which we needed to use them. We were constrained to scanning faces only in daylight, which meant our enrolment operations—which had contractual timelines—could only operate during daylight and depended on good weather and a decent turnout at the enrolment centre. Speed mattered. We built out a fairly robust enrolment operation.

(Edit: Fact check. We actually turned to facial recognition, not iris scans. Those came later, in 2008.)

Fingerprint scanners don’t take photographs of your finger. They reduce the details of your finger’s pattern into a series of numbers called the minutiae. Each manufacturer’s algorithm is different, so minutiae can’t be compared across manufacturers. If you pick one supplier, you’re committing to them for the lifetime of your database. As the lowest cost winning bidder, we went with the lowest cost supplier, and they didn’t make those fancy machines that scan four fingers at a time. You can see we were setting ourselves up for some pain.

Was the exercise worth it? Did we catch any fraud? You bet. I saw the photographs. The same fellow showing up in different villages in different disguises, once with a beard, once without, once with a monkey cap, caught by matching biometrics. The reports we submitted justified the expense of this “de-duplication”.

But we didn’t propose biometrics when disbursing rations. We didn’t trust the electric supply, internet access, or the shop’s ability to keep a computer system running. That was going to be plain old transparency and paper using my crypto scheme. In 2006, mobile internet was still GPRS, not even the EDGE networks we know as 2G today. It was too expensive and too unreliable to take seriously. Except, the government changed and with them the plans changed.

Aadhaar

I left Comat at the end of 2008, burnt-out and jaded. Sometime in the intervening years, the company’s co-founder and President (later CEO) met Nandan Nilekani on a flight and told him what we were up to. I first heard of UIDAI and their plans in 2009. “But…” I said, thinking back to all the things we had tripped over. “Smarter people than you are working on this,” I was told (it really was as blunt as that). My concerns weren’t a matter.

Comat’s work became a case study for UIDAI. We were one of the largest biometric databases at that point. (As Karnataka places cooking gas subsidies under the ration card programme, unlike many other states, we had a bigger net.) UIDAI worked around many of the technical and operational issues we stumbled on:

• The UID (later “Aadhaar”) is general purpose, not linked to any particular department or use case.
• UIDAI is funded by the savings from eliminating fraud across departments. It didn’t require an additional budget and was therefore easy for the government to approve. Notice that this has been a consistent message across years.
• To avoid the waterfall trap of a government contract, it was built by volunteers, with contractors coming in only after the foundation had been laid.
• Both fingerprint and iris scans are used. All ten fingers are scanned. Backup options are included (in theory) when biometrics don’t work.
• To avoid vendor lock-in, UIDAI put together a consortium of vendors agreeing to a common standard, using the sheer size of the database as leverage to get vendors to open up. This also means getting to that large size is crucial, explaining their hunger for enrolment.
• The government departments funding this will only realise their savings if 100% of their enrolments are via Aadhaar. Any beneficiary who is enrolled twice, once via Aadhaar and once without, will remain undetected as a dupe. This explains their drive to make Aadhaar mandatory. This isn’t a government conspiracy or a surveillance state, it’s plain economics.
• Also to avoid vendor lock-in, biometric matching software from multiple vendors is run on the entire database for every new enrolment, with vendors paid for performance.
• Most of this software is licensed rather than custom-built, with the size of the database used as negotiating leverage. Many people are upset that a government-funded project is using proprietary software. I’m rather thankful it’s not custom-built software, having seen the horrors of that in other government projects.

That said, notice the most glaring thing about Aadhaar’s design: it’s entirely top-down, funded by savings from eliminating fraud, and inherently designed to protect the benevolent state from bad actors such as minor officials and you.

Can a general purpose id framework be used in any situation that requires id verification? Sure, yes, and UIDAI has been unabashed about Aadhaar being universal, usable for anything. It may have been conceived and funded for state subsidies, but that doesn’t stop it from being used everywhere else. Thanks to initiatives like IndiaStack, Aadhaar is consistently hyped up as the panacea that will solve identity problems—even when it fails to. Here are two examples of how UIDAI fails the citizen, based on two different ways in which it is used.

1. Scroll’s Identity Project documents multiple instances of beneficiaries being denied benefits when the state attempts to use Aadhaar as it was designed, with biometric authentication, owing to (a) technical glitches, or (b) biometric exceptions (unscannable fingers, etc), where the state fails to provide backup options, something UIDAI itself recognises as being necessary. The id is after all meant to be universal, even when biometrics are unreliable.
2. The “Aadhaar card” is at best a receipt acknowledging a user’s enrolment. It is easily faked—far more easily than a plastic-backed PAN card or driving license—and should not be trusted as an identity card without corresponding digital verification (based on biometrics or demographic data), and yet the Aadhaar card is widely accepted as id proof thanks to the government’s own push. The lack of verification allows petty officials to scam the system, as has been happening in the ongoing demonetization exercise. UIDAI should have frowned on the practice of using paper cards as id, but instead merely preaches being careful.

Notice that both of these are implementation errors, where a well designed API that should work if used correctly is simply not being used as per spec. My probing has left me satisfied that the architects have indeed thought through it very carefully. But what is Aadhaar if everyone has a slightly different understanding of how it should be used? This chameleon-like nature, where the same entity appears differently to different actors depending on how they encounter it, is the source of much angst around Aadhaar.

On the one hand, your Aadhaar number is supposed to be confidential, because your only protection against a state actor claiming to have granted you a benefit is that they don’t have your number. You only share it with the entity you’re actually transacting with.

On the other hand, if you share a photocopy of the card every time you transact, even if you hand-write the purpose on it as UIDAI recommends, what reasonable hope do you have of that paper not finding its way to a rogue actor’s database? Would you share a photocopy of your credit card and pray it’s not misused?

We haven’t yet addressed the elephant in the room.

Citizen databases have been misused by repressive regimes everywhere. Want to target Muslims in a neighbourhood? Easy, look up the election commission’s voter list for Muslim-sounding names. You get the full address to their house. Aadhaar is a single, giant database of everyone in the country, a supremely alluring target for abuse. (No need to stretch your imagination: the Holocaust also used citizen databases.) To protect from abuse, UIDAI has to be beyond the reach of abuse vectors, and the UIDAI Act successfully achieves this, making UIDAI answerable to no one, not even to courts. Their position, now enshrined in the act, is that no one can retrieve any data from UIDAI under any circumstances. In effect, they are beyond the rule of law. I do not doubt the sincerity of the reasoning to be unaccountable, but it also means the institutional systems of checks and balances that democracies evolve over decades (or centuries if you count inheritance) no longer apply to UIDAI. It has no watchdog. Whether it is a benevolent provider or a tyrant, who can do anything about it? This precarious position is reflected in the aggression with which Aadhaar’s proponents defend it. [I haven’t even finished writing this article and colleagues are receiving ominous email about my position on Aadhaar and what it means for business relationships.]

(Edit: it’s a rich irony that UIDAI went this far to not facilitate the surveillance state, and yet Aadhaar is widely regarded as being meant for surveillance. This merits a separate discussion.)

Why would you trust your property (including your money) to a system explicitly designed with the belief that you are the one likely to commit fraud? Where in Aadhaar’s design is any mechanism to prevent the state from making a claim on you, without your authorisation? The Public Distribution System may choose to deny you rations if your biometrics don’t validate. A bank may choose to accept a photocopy for currency exchange to avoid the hassle of biometric verification. Both are their choice, not yours. You are only as safe as the state’s enthusiasm for ensuring your safety. As Aadhaar is not limited to being used by state actors, this imbalance of power extends to any private entity that you choose to use Aadhaar with (or are forced to).

Institutions of democracy such as the right to private property work the other way around, treating the state as a potential bad actor that must be constrained for your protection. The state can’t take away your land except under exceptional circumstances. A private corporation is a legal person with the full set of human rights as a human. Or take the ongoing demonetization fracas: the RBI Act doesn’t allow it ever dishonour bank notes it issued, despite the government’s claims to the contrary. You can return old notes to the RBI at any time in the future and they will be perfectly valid.

It can be a little hard to imagine how a good identity system should work, so here’s another example. A European friend roams the world with two passports, both issued by the same country, and both simultaneously valid. He explains the advantages:

1. He can travel with one passport while the other is stuck in an embassy waiting for a visa.
2. Many countries get suspicious if you’ve been to particular other countries. Middle Eastern countries won’t let you in if you’ve been to Israel. The US adds extra scrutiny if you’ve been to a place like Iran. By keeping separate passports, he can keep his travels private from nosy immigration officials.

Will Aadhaar let you get a new identity if your old one is compromised? Believe it or not, the architects considered this situation and included the ability to get a new Aadhaar number for reasons such as witness protection programs. I’ll give them credit for that. It’s unclear how you can qualify for this program though.

Will Aadhaar give you a second identity so you can keep your activities separate? After all, Google has no problem letting you login with multiple accounts simultaneously. But Aadhaar? Not. A. Chance. This expectation is considered fraud under Aadhaar. The entire humongous biometric system is explicitly designed to prevent you from doing this.

Can you de-register from Aadhaar? Nope, because that too is indistinguishable from fraud should you ever try to re-enrol. You can only deactivate your account, but your data is never removed.

What can you do if your biometrics are compromised? You may be composed of flesh and blood, but Aadhaar is an electronic system that only receives bits over the wire. A fingerprint scanner turns fingers into bits—bits that can be copied and replayed any number of times, for the rest of your life, and there’s absolutely nothing you can do to stop it. Will Aadhaar or biology give you new fingerprints?

An identity system that protects you from unscrupulous state agents, like the European passport example, requires a fundamentally different approach to thinking about identity. Aadhaar sits beyond the scrutiny of law. What stick do you have to chase it with, to bring it to a negotiating table and rearchitect it?

Will the government stop forcing Aadhaar on you? No. Its fundamental appeal is in being mandatory.

Does Aadhaar have possible operational issues that they will never admit to, like in my personal example? You bet. Will those be serious vulnerabilities if discovered? Yes! Security by obscurity doesn’t work forever. Will they try really hard to prevent you from looking under the hood to see how it works in practice? Is that any surprise?

Can Aadhaar be destroyed? Unlikely. Institutions have a tendency to fight for their survival, and UIDAI has proven remarkably adept at it.

But institutions also evolve. The horribly insecure edifice of the credit card, where anybody who has your number can take your money, has evolved a remarkable array of coping mechanisms, from fraud detection to liability protection, and is today the backbone of the global payments ecosystem. There is no reason to believe Aadhaar will not evolve virtual personas, biometric-free authentication and a number of other coping mechanisms.

If history has taught us anything, it is that the victims of a flawed scheme are almost always the poor, the marginalised and the vulnerable. This is true of Aadhaar as well. Your best hope is to resist it for as long as possible and let it evolve based on the experiences of other victims. This is a pessimistic outlook, but it’s the only way to cope with an entity already beyond the scrutiny of law.