In this piece on UID, Pratyush & I discuss on some Hygiene issues that would make or break the UID system. And we will definitely refer to the Technical Scope of the recent tenders as well. 🙂 In our last post, we had someone from the UID team telling us about the sarcasm in the post against philosophy of two-bid tendering system. Not really, it is not sarcasm. But an effort to look through the direction, the technical inconsistencies and ‘hygienically worrying lack of attention’ to the details. For example, check page 18 of this document which mentions the eGovernance platform and we refer –
The eGovernance Platform will consist mainly of 3 layers:
1. Back Office layer
2. Infrastructure layer
3. Operations layer
4. Persistent store (database) layer
Hey didn’t you just say 3 layers? Thats what we are talking about! That’s just one of the ‘hygiene reason’ enough to be dissatisfied about. In case of UID there seems plenty of super-high-level talk where we believe that the ‘competition in prices’ would be as skewed as interpretation of the Technical Scope.
: “In December 2009, UIDAI had invited bids from companies to become its project management consultant. Seven companies that includes Booz & Allen, Price Waterhouse Coopers, Deloitte, KPMG, Capgemini, PA Consulting and Ernst & Young responded to the tender. Only three made it to the final list — Ernst & Young, PA Consulting and Capgemini — as the other four companies were disqualified on technical grounds!” via
While the size of the contract awarded is not known (so much for transparency), Ernst & Young quoted Rs 7.05 crore to emerge the lowest bidder; Capgemini came next with Rs 8.6 crore, and PA Consulting quoted Rs 51 crore. Observe the range of skewness in this bidding from 7.05 crores to 51 crores in just three qualified bids! Funny competition we say.
Hygiene factors are defined clearly in Herzberg Two factor Hygiene – Motivation theory. In short these are design factors that dissatisfy a user (as opposed to satisfying him which Herzberg observed is independent). For example, in an office scenario this might be the cleanliness of bathrooms or availability of stationery or time taken to process payments etc. which might potentially rub people the wrong way and cause them to leave a job unfinished. Half-ass, in other words.
In the UID project we believe there are plenty such factors and we will try to note a few. A lot of it is ‘techie stuff’ – an easy escape statement for most wannabes & noobs out there – but hey this project is about technical stuff and so is the post on it. We will generally avoid demographic inequality or behavior of the census officials as a factor in the analysis.
Hygiene factors –
Issue no. 1: Non transferability – Numbers should be non transferable. This seems like a no-brainer. But like cellphone numbers, thinking 40 -50 years ahead, with two generations born (and some dead), there will be the issue of newer random numbers being generated and some numbers getting “free”. How does UID think of handling those situations? No mention anywhere at all. Microsoft faces a similar issue for its device keys with 4×4 numbers already (they have a lot of products). There has to be a very well thought out story on the “life-cycle” of such identifiers and associated numbers.
This is why the association of cellphone numbers (or as a rumor said – cellphone being the UID) should be thought through very carefully. There are several issues
with having cellphone numbers as identifiers – although they still are the best way to have an “unique ID”. They have entity based identification listed in their document, which is a good idea. However UIDAI’s document dismisses outright the re-usability of numbers and quantum of numbers e.g. on page 9 of this document
it says “That is 80 billion — is plenty of space”, which we believe is highly underestimating the task at hand (as we were reserving only 1 for entities).
Issue no. 2: Non identifiability of groups
– No one should be able to say “My name is Khan – and my UID starts with xxx—-“. On a serious note, no ethnic or religious identifiability / regional identifiability should be possible – hence total randomness should be followed for number allocation. As we had briefly mentioned in our last post, this is a sure-shot game killer. There should be absolutely no way to identify “groups” of people based on their UIDs. This leaves the door very open to racial / regional profiling in a diverse country like ours. Hence number allocations should be almost totally random. Which is why we cannot follow a state based system like the US has for SSN
. Imagine MNS activists looking at some ‘Northie UID’ and beat him up!
Issue no. 3: Easy rememberability or atleast retrievability for user
– Apart from giving the user a card (with biometric inputs), they should explore alternate methods of rememberability of UIDs and retrievability. India still has a sizeable illiterate
population and the physical manifestation of the UID (see we didn’t call it a card) has to incorporate these attributes for the user. Is biometric the only way out here? we do not think so – for the checks with biometric capabilities is costly – although one might argue scales coming into the game and making them viable.
Issue no. 4 Levels of access – (This one is a shocker) – In one of the documents shared by the UID team in the tenders, they refer to Government, private agencies and users in the same breath in terms of access to data. We hope this was an oversight and an exception. The levels of access should be crisply defined and according to the privileges of the different types of users or agencies. The read and write permissions will vary widely across the spectrum of government agencies, semi-public, private agencies (like Banks vs educational institutions). We will talk about updatability later.
Issue no. 5 Resident’s address – From pages 10-12 and again at page 20, the document talks about address as an essential parameter. However, as most of India becomes younger and is urbanized, the flux of people on-the-move is going to only increase and in such a situation, the efficacy of a ‘single address’ is questionable. Therefore, permanent address (oh that funny Indian requirement – someone had once told me) is what should be the permanent entry in the DB table and there should be provision to update only the temporary addresses table. Following from the point above (Issue no.4), secondary access bodies should be able to pull and update temporary addresses (along with proof of verification) only. The fact that this doesn’t appear in the document again is slightly surprising (IMHO).
Issue no. 6 Secondary identification
– As with all forms of primary identification, there should be secondary identification mechanisms. Let me give an example. If someone has your ICICI bank card, can he withdraw money from your account? The answer is NO – as he would need to know the PIN at the ATM. In case he is doing it online, he would need to know the grid behind your card as well as your online password. We strongly believe that for all “data pulling agencies” (for example verification-by-tax-authorities on the basis of UID) tomorrow such a secondary validation process should be compulsory. This is a huge issue
in the US already and we shouldn’t ignore it for UID. But yeah, no mention at all.
Well, so much for Technical Analysis on UID. We do not want to digress beyond this point 🙂 Do you?