Welcome everyone, and thank you so much for joining. So I think today, for everybody who was here yesterday, if you recall, we kind of went over the technical aspects of computer science where we discussed techniques which help in enhancing literacy. And we went over topics such as encryption digital signatures, a couple of data minimization techniques. We also discussed their capabilities and constraints for speech. And we had a short discussion on the corresponding hardware that facilitates the kind of solution that we're trying to propose with this paper. So Malika, that's just for the next slide. Thank you. So today's conversation will be revolving more around the regulatory context. We're going to see how regulations evolving and shaping to accommodate this context. We'll move on to the failure of consent and privacy self-management and why we, through this paper, find the need to operationalize technically a standard for data protection. So then we'll be moving on to discussing the proposed solution of trusted executables along with the data I want some of the use cases which we discussed in the paper as well. So those would be the electronic health record system, direct benefit transfer and contact tracing apps. I think Srinivas has already put in the housekeeping rules. But if there are any questions, we'll kind of pause after every slide so you can just ask them. Or we can obviously have the steady stream of inputs coming in from the chat box. Next slide, please. I think just to jump in, I think it's no secret that we as a society have been digitizing in the past few decades. And we've been digitizing in all aspects of our lives. More importantly, states across the globe have either started to or enhanced public service delivery via digital channels. So we are now in the third generation of data protection regulations. And as you will see in the graph, a lot of the regulation enhancements and regulations for data protection that have taken place have happened in the last decade. So that's what you've seen the last bars this week. Next slide, please. So here I think what we're trying to say is that earlier we had a more consensus approach where the idea was really to take consent from the data principle of the data given individuals like you and I, and just kind of harvest it as the entity collecting the data profit. What countries across the globe are now moving towards more of an accountability led approach, where in the accountability not just lies with the data entity that's collecting or processing data, but also with the regulator to kind of be on the map and kind of see how the data entity that's collecting data doing it and whether they're doing it in a lawful manner and there is kind of an accountability check for both the data entity and the regulator for keeping the data entity in check. Anubhuti, it seems like you're not audible enough. Can you be a bit louder or come to the mic closer? Is this better? I think so, but I'll check back in a minute, but please speak a bit louder. Thank you. I'll do that. Thank you. So when we talk about accountability led approaches where we no longer kind of just have the constant model in place, we take the constant from the individual collect their data and do what you want with it. Now there are kind of rights for the data subject themselves. There is focus on the entities for taking into account the taking having cognizance of how and why they're collecting the data. So I think, as you see on the slide, the first three, which are related to write for the data principles or the data subjects themselves, there are grounds of processing where the collecting data entity would have to kind of establish the purpose for why they're collecting data. Then there has to be specified purpose. There has to be just one moment. I hope the volume is now better. So as we were saying, then the second about specified purpose where you kind of have principles as we went over yesterday with regards to the OECD principles for data processing. There has to be collection limitation for the data you're collecting. There has to be purpose limitation that has to be specified purposes and safeguard as to what an entity would do or have a general idea of what they're going to do with the personal data that they're collecting. The personal data that is collected, it has to be processed fairly throughout the life cycle from the point of collection of the data to processing of the data to sharing of the data and finally, if at all, deletion or archiving of the data. There's also larger focus on organizational data practices. So it is no longer in silos where entities are just collecting personal data. There is kind of cognizance in the larger community wherein we understand that there are certain practices, certain standards of collecting data and processing it as well. And finally, just there is heightened accountability to the regulator for kind of the manner in which they collect data and for the regulators themselves to monitor and supervise efficiently what it is that the data entities under them are doing. So as we discussed earlier about the consent model, despite having more to a more accountability based data protection regime across many such laws that have come into place, there still seems to be this reliance on consent that constantly comes up. And it's been established widely that asking for consent, asking a data subject at the spot whether they would agree to do away with the data for a particular service. It's been established within literature that it is largely meaningless and it only provides the false choice. So we kind of provided the research that is already available on this. But as we know, there's a lot of cognitive and behavioral biases that are operating at the level of the user when asked if they would be willing to share their data. Then even for the data entity that's asking for personal information, there appears to be an information asymmetry with the data principle of the data subject about what's going to happen with their data. And it's a widely understood kind of fact wherein data and data collecting entities themselves don't know how much further they are going to be able to process their data. So they might say today that we're only going to use it for X, Y, Z purposes, but tomorrow there might just be a new use case for such data or a new technique which could yield more input from the same collected data. So there's just a lot of information asymmetry which does not provide fair ground for a data subject to understand whether or not they should be parting away with their data. And finally, we constantly talk of this binary that is that the problem with consent. So it's either an accept or deny and when you deny, essentially what you're saying is that if you don't give me permission to access your data, you cannot really have the service that I'm attempting to provide. So these are kind of the three major problems with consent itself. And privacy self-management does become very difficult through means of just providing or modifying your consent. Next slide please. So I think with this, I'll just hand off the Malvika, but just to round it off, we're going to move away from this approach of taking consent for doing away or giving your personal data to entities. And while there are noted problems with consent, there is a paradox with how data principles or data subjects perceive their own personal information and how they decide to control who they're going to share it with. And this is Malvika here. Just a quick sound check. Let us know in the chat if you can't hear me. But I suppose what we're doing here is really stepping into the stage of the presentation where we are motivating the operationalization of the privacy guarantees that we are increasingly starting to see in the law. So as Anubhuti just mentioned, obviously there's widespread recognition that this idea that you can self-manage your privacy or your data through personal data stores and so on, is only really relevant to a very small proportion of the population, if at all. And the wider discourse actually in the early 2000s later as well has really focused on the fact that maybe people don't care about their data in that they state that they value their information. But when you're asking for the information, they pretty much say I agree. I say they and I mean we. I think if you step away from that finding in kind of, you know, behavioral economics and so on. This paradox is really contextualized against this reality that we have where you might, your stated preference might still be that you want to have some kind of control over how your information is shared. But given the operational architectures within which we are all currently living our lives, there's really not much we can do if we want to access a service and this becomes even more of a problem I think and even more of a concern when we start thinking about the state providing services. And I think Arjun actually has a really interesting comment in the chat that I just addressed right here. This idea that you know people trade their information as an asset in return for services in the early days of the Internet. This was very much the case you had a small set of users often writing the terms of engagement as well. The thing is as it's become almost a platform the Internet itself. In order to live our lives we need to be able to access services through this platform and that the power dynamic really shifts from, you know, a set of people operating at the edges of a system who have a lot of agency into say something like you have a public distribution system for food where unless you are able to prove that the information held about you in a database is accurate, you cannot get food right and so that collision between the virtual world in the real world I think shows that this idea of trading information is really becoming quite obsolete in a modern data driven sort of society where we need to recreate what does agency responsibility and all of that look like online. That's where India has, you know, come into this entire debate that early slide that I know what he showed you about, you know, since the 70s we've been having laws, but we call them the first second and third generation of data protection laws. It's really since 2010 that even countries and jurisdictions like Europe, you know, where they had 30 40 year old draws everybody's rewriting their laws right now.  And what we've recognized in our society is that far away from data just being property that you can trade in return in a barter system data has become and that's sorry to be a lawyer here and put a lot of words on the slide. And I think the core of what we all now know as the put a swami judgment in 2017 really said each of us have an interest in preventing how information about us is collected represented and how it's disclosed, you know, the how it is disclosed to national security apparatus might be different from how you want it to be disclosed to your Russian shop to how you wanted to be disclosed to your neighbors or your telecom providers. So we have an interest in having some control over that. But I think the dissonance comes from the fact that just because a lot of the databases themselves and the digital architectures are not things that we can control. We have this interest that we would like to assert, but we are in some sense removed from the ability to control these vast, you know, huge architectures. Now this doesn't have to be to sinister and I'm sure Prashanta and so go then she will tell us more why, you know, it's actually great that we have these kinds of architectures in place to enable our lives. I think the, the short point here is, how do we get to a point where we have a responsible system as a whole, because that notion of trading information has, has personal information has fallen away. And I think another great thing that's happened in India in the last three years and very, very quick top level is that as a result of this interest, or almost like a fundamental rights human rights interest that has been recognized in your personal information in relation to yourself. Government has had to move to put in place a bill, which actually gives you certain rights so it kind of demarcates where you can trade in your data, and what type of your data, especially if you're a child, for instance, are you simply not allowed to go out there and, you know, kind of trade in, especially if that is going to expose you to certain risks and harms. And I think the last thing we'll say on this just to tie it all together is that on the one hand we know that consent is failing as the internet gets wider and data driven services even off the internet get more and more central to living your life in society. But equally, there's a need in the law to say, okay, if a one to one transaction doesn't work, let's put in place some accountability mechanisms, where the people holding your data, you can interact with an expectation of trust. Right. And that, do you can think of them almost as a fiduciary or somebody who you are in a relationship of trust with like a lawyer or a doctor or, you know, even a religious leader, where you can make yourself vulnerable, because you know that you're going to get some support from them and they have a much higher sort of knowledge base than you. And those responsibilities and expectations should operate irrespective of trust. So this is as far as the legal landscape has evolved and we've kind of told you in like six minutes what's happened over the last 60 years. So happy to pick this up more. But I suppose where that takes us is we have this law at the highest level it's saying, you know, we should have a responsible data architecture. What it means next is that that law itself, if and when it's passed by parliament, hopefully, potentially in the next year, it will need to be made, it will need to be operationalized through something that we call subordinate legislation. I'm sure many of you know this already, but the law is just a set of principles for what you want to do. And this is a kind of very granular image from a policy brief we put out, but it tells you that there are about 7080 areas in which we'll have to operationalize the law. We'll have to say, what do we mean by data quality? What do you mean by data audits? What do you mean by, for instance, transparency measures, right? And all of these things will evolve. What is anonymization? And this is something we discussed yesterday. But as that's happening, one thing that's been clear is that if you don't have a technical operational standard as well, along as a legal operational standard, you end up in a situation where you have lots of wonderful motherhood and apple pie legal statements around interests, human rights, respect. But in practice, there isn't really very much enforcement of those guarantees. And I think that's the reason why the ITLE team and us really have been having this conversation for more than a year now. And resulted in this paper that I will hand over to Shubhashisha and Prashanta talk to us more about. But we really see the motivation, all of this is the motivation for the reason why we need a technical operating standard for any data protection regulation. This standard we're going to talk to you about or this architecture is not about substantive legal protections, right? That we'll have to come to as a society. Do we want to give notice to everybody or not? Should everybody receive a breach notification or not? Those are value decisions we'll come to as a society. But once that happens, and it might happen in the next year. So this is really path breaking times to be living in. What happens to, what can we do next to ensure that it's made operational? The detailing is made with some kind of a connection between computer science and law, because often the disconnect or the inability to talk across disciplines creates all these weird rules which make no sense in practice. And secondly, how can we actually tell that it's being enforced? Because again, it comes down to how much can the regulate to have as oversight over data processing entities. And how can data processing entities have a conversation with the regulator that is tech mediated, and you don't have to perhaps, you know, download something in paper and sign it in triplicate or, you know, such arcane things as we are used to in our culture. And that's the role of this. So on that note, if there are any questions, otherwise I'm just going to hand over now to Shubhishesh and to Prashant to come in and do the deep dive of the architecture and the operationalization itself based on our conversation yesterday. Malavika, before we move on to the next set of conversation, maybe let's just take a break and let people have any questions or discussion with you and Anubhuti. Is that good? Sure. Yeah. Anyone who has any points to be raised, please go ahead, raise your hands. I'll unmute your mic and you can speak. Okay. On this question of urgent's point, essentially that you tried to explain itself, right, this trade of data and, and especially this dichotomy of consent being died, but, but you're still being forced onto it and this new models of that are emerging like data trust personal data stores. Frankly, India has adopted it, but there is no definition for these right like inside the government you see, for example, the RPI doing a contract aggregators which is being shown showcased as a regulatory sandbox or data stewardship model, but we really do not have these definitions inside the government. While you are advocating for some of these systems through your paper, a lack of legislative clarity itself is something which is confusing around these systems, right. So what would be, what do you think needs to be done on that front, even in terms of say consent? Yeah, I mean, one good thing is if we have a horizontal law, like, you know, one legislation and very quick sidebar is that when you have conflicting laws, there's a general rule that the legislation or statute, the constitution is supreme, then any standalone statute which is cross sectoral is supreme, and then specific regulations that might come under that statute or from a regulator comes next. So there's almost like a trumping in the constitution trumps a bad statute, the statute trumps a bad regulation and so on. So if we get this PDP bill, then it will trump in some sense or they will have to renegotiate all these other existing sort of one ops that we have and that's a project also that we're looking at is that, you know, can these other, you know, the digital payments localization directive, for instance, from the RBI is that consonant with this regulation. So that's just to answer the point about how everything isn't really coherent. I think the larger question just about, you know, if there is a person and they want to use these data stores that account aggregators or digilockers, that's all very well. And that's great. But the point is in our kind of society and across the world as well, the actual usage of these has been low because it requires very high bandwidth. For instance, if you're a daily wage laborer who's currently battling life because of the lockdown and loss of livelihood, you're not going to be sitting around fiddling on a, you know, screen about your digilocker. Right. I mean, it's not no offense, it's a great system, but it needs that level of bandwidth. So as a consequence, can we move to a situation where people who want to do privacy self management can. But even for those who don't, we have a responsible architecture overall, where a regulator is able to say when data is collected, how it can be used and how it should not be used. The question around value, I'll just quickly tackle these two and then hand over because they don't want to go on for too much longer on value of data is a very difficult question. The trading argument was never really based on the fact that you could put a rupee value or a dollar value on information or your personal information. And the reason for that at a very high level is that personal data can't be treated like property, because it doesn't satisfy the conditions of property legally speaking, this goes back to our conversation around logic and so on yesterday. But essentially there are some conditions on the basis of which something fits or does not fit property. Two of the main ways data is not property is that it's not alienable for property, take your house or even a pen that you want to sell anyone, you should be able to cut it off and pass it on to someone, and then you have no connection with it. The thing with personal data is no matter who you pass it on to any change to that data has to reflect you. And if it's miss, you know, if it's misused or misrepresented, then you have negative effects as well. So the alien ability fails that condition. And then I think there are several other conditions based on even intangible property like copyright and so on. It's not an artistic work. It's not a literary work. It's literally a representation of you with an extension of yourself. And that's why it's not property because when it's your own personhood, then it becomes something that is outside the dilemma property. I hope that wasn't too philosophical, but it's actually quite a practical reason why. There are some certain, you know, conditions in which you could trade trade your information potentially. It's not to say that, you know, when we're talking about data, we need to get granular as well. All personal data has to have, you need to have go down a level. So obviously you don't want genetic information or certain types of information that is contextually private to be revealed against the person's wishes. In some cases, there may be somebody who wants to trade particular types of information about themselves, like for instance, you want to get on a, you know, matrimonial site in India, we have a lot of those. And we're actually putting our data into a closed market in order for others to see it in price accordingly to use some not appropriate language, I suppose. In those cases, we can put in place a contract and I like to use the analogy. And this is the last time I use an analogy because they never work for data. But it's kind of like labor. We say bonded labor is not all right. But that doesn't mean you can't get into employment contracts, contracts, right. And it's labor is an extension of yourself in some sense. So you can buy and sell people. That's just not okay. But we arrived at that point as a society and I think we are kind of witnessing the creation of those kinds of frameworks for data as well. There's one question before we move on. I think Abhishek has it. I'm unmuting him. Yeah. Hey guys, this is Abhishek. So I basically work with the Ministry of Housing and Urban Affairs at the Smart Series mission and I'm also a data scientist. So on the point that you were making that the government is actually, you can say not working towards them. So I would like to point out that a government is working towards them, but it's kind of very vague right now. So for example, at the ministry level, we are actually working on city data policy, which is sort of backed by government of India's open data policy, which only talks about non-sensitive data. We are trying to include sensitive data and then trying to figure out a way to maybe deal with personalized data and how to anonymize data, which is fit for consumption by even private entity, something like that. So those sort of like initiatives are going on even, for example, like Metis also working on the similar initiatives, which they are trying to standardize these things through BIS. They are sort of in a closed system right now and the community does not know about them. I think that's the biggest problem that government has right now, that they don't sort of open up everything that is very closed in the ecosystem. But there are some initiatives and I think on the private side, like you might have heard about this streamer based system and they have come up with a new framework which are called data unions, which gives you sort of like a framework to sell your personalized data in real time, which is totally anonymized and that's sort of something very amazing. So yeah, that's it. That's the point I actually wanted to make. Thank you. I don't know if you want to respond to that, but there are a lot of updates on the front of the National Urban Innovation Stack where there are upcoming standards on data exchange systems. We will get on to that on a different session probably. I do have more hands. Malavika, should I take them? I mean, we're here to answer. I'm just conscious of time, so it depends. I think we have time. It's just 4.30. I will let them ask them to keep it brief. Arjun, you can go ahead, but let's make it brief. This is pretty much on the lines of how data plays out as asset or not asset. So I put the question in the chat as well. If I was to create content which was say a fake profile online, that would be copyrightable as far as I understand it, right? Not necessarily no. That's probably the broader sort of thought experiment that I'd like to go into it, but I don't think this is probably the best time to do it. But I would probably think on those lines because content is traded all the time. It's considered an asset. I don't see the dichotomy between the two realistically. So I'd like to get the operationalization on that understood a little bit. Sure. And actually I've been working on this kind of paper forever, which hopefully you will see the light of day this year. But just to kind of the headline there is when it becomes a profile, creation of a profile, it is not necessarily, it's not an artistic work. It's actually think of it more like misrepresentation. And this is kind of what Twitter and Facebook are going through right now. So it's that line between, you know, if you're an imposter, say if there's an option to who's walking around and kind of entering into transactions for you. That person might say, actually, you know, I did all this effort to get into disguise and I'm an artist. It still doesn't, it's not kosher in our society, but I'm happy to have a more technical conversation on that separately as well. Okay, we have someone else. Yeah, this is Suhan Srinivas. Hello. Yes, please go ahead, Suhan. Yeah, so the question has to, you know, Malavika, I just wanted to do the fact that it doesn't reflect nature of property is something that could be taken care of in terms of the rights that you define and create as a derivative of data. So for example, say property has things like easementary rights, but say, for example, the ownership doesn't necessarily change and is always tied into whoever has ownership on the underlying property, but rights of how other people can utilize it, get, you know, defined through these other types of derivative rights that we have on property. And that could be one model for looking at data. The continuing safeguard that one should perhaps could keep for the person whose data is being shared is to look at personhood as a framework because the idea of credibility and a financial value perspective may not be something that's universally acceptable to lots of people. Whereas if we were to say a personhood autonomy and choice, which are basically fundamental values or rights that are due to every human being and we keep those as the essential features that the legal system protects and everything else is then derived thereof and the way that if you want to trade or not trade are based on a system of rights and interests that you create that ensure the protection of this. We could actually come up with a framework even if it doesn't per se look like property or have the features of property. I mean, your thoughts on that. Yeah, sure. So obviously this, I would say the kind of state of the art thinking of this, I really highly rate academic Korean prints whose works out of Tilburg, excellent writing on this and basically very detailed arguments of why these kinds of Cossian property rights frameworks don't, they kind of break down. So there's been an interesting amount of work. So even things like easement because people have tried that the issue there is overall the problem is the question of do you want to monetize your data. I think what is driving the view towards propertization and I think the response to summarize a whole bunch of scholarship is that you could, if there is such a need and hello to the doggy. If there is a need to monetize data as a country or as people depending on you could do that. Likely property is not the best route because it falls down on the basis that it's very hard to hold on and alienate beyond the point. And also I agree. I agree with you. Yeah, because it's the the tradability pieces more of the American data brokerage model that came about as opposed to say the European and other models that look at the human being perspective and the autonomy personhood piece and in that it fails. But if we have to create an economic framework for it where governments necessarily want to trade, we would perhaps need to come up with new forms of instruments that you know maybe retain what is essential in what we're trying to protect as outcomes but allow some degree of negotiation either for the state or private entities that the state allow to engage with that individuals data. Yeah, and the only other thing I would say there is the other side of this piece if you take away the privatization is the effects it has upstream on competition and also kind of state versus private sector negotiations. Now there's a lot of really interesting work in economics actually and labor markets, everything, which says that the issue with sort of large data aggregator firms is that they tend off into a natural monopoly, which actually puts you in a pretty difficult equilibrium if you try to trade with them because for every additional piece of data that Google has, the value that they would derive from that is very different from what a you know startup might I mean potentially. Yes, you could have equal computing but if they're on the realms of whatever quantum computing right now, it's just simply not a you would never get to a point where there would be a level playing field. So I think the idea of that kind of harvesting also slowly I think some governments are beginning to see that it might not be the best way to protect government interests. Now I guess the other discussion and three of us maybe you should have a totally different session for this just where does that leave the individual. What's interesting is that the US has taken a very markets first approach some say not always the case based on which sector and EU clearly has human rights imperatives. In India is this really becoming a conversation about the state negotiating with the private sector about what value can be extracted from its citizens. And that's fine, but then where is the citizen in all of this is an important question to ask. I think our framework of legislation has actually sacrificed the citizen, because if you see the fact that the rights are completely being negotiated by the authority and even allowing you to know that there's a breach and your ability to prosecute being limited is I think the fact that the state has removed the focus of the citizen and not taken a human rights or even a fundamental rights framework as per our constitution in the way that it's not kept the citizen at the centre of it. Yeah, I guess you're right there Sushant. So we'll have to again agree with Malavika Vinita separate session of this. Another session. Yeah, yeah, yeah. Yeah, we're going to do them as August I guess will be the third year anniversary of right to privacy judgment. We will try to line up a set of events. But I think we can move ahead now towards for certain energies and Prashant's side of the event. Shall I stop share right now, should we just let me know or if you'd like to stay on this. Yeah, maybe I can share this slide. So is that visible? Yes. Okay, so yeah, let's come back to the architecture aspect of you know the privacy of design architecture and I'll just motivate that one proposing the architecture in the first place right and why is it necessary. So I will start off from Prashant's slide yesterday where he tried to list out some necessary conditions for privacy I've just added some implications in bold. So Prashant mentioned yesterday that absolute privacy is impossible right so which means that if an adversary has unbounded access to unbounded auxiliary information. Then there is can be no bound to inferential privacy there is no way to guarantee that what the adversary will find out if the adversary has the data in hand. So, as an example if the TRI chief says that, you know, here is my other card, do what you can with it or if the UIDI chief says that here is my transaction log authentication log metadata, do what you can with it. Those statements are fundamentally flawed because an unbounded adversary can have unbounded harm with that data and this is well known. This is a theorem by Sainty Advocate that Prashant quoted and it suggests that you cannot let so this immediately implies that you cannot let an adversary have access to the data itself. If the adversary has access to the data, unencrypted data, then the harm that the adversary can cause can never be bounded. So, and this is also, so this requires access control. So data has to be access control and this is an also encryption doesn't solve because encryption has a key management problem, you know, who has the key has a description. And if an authority that is encrypting data and authority has the key, then an insider attack problem, so almost all attacks are insider attacks, you know, sort of unthinkable in modern days that you will attack and modern data store from outside, you'll get caught in minutes. It's far easier to bribe somebody or certain somebody, you know, an insider to get an attack, you know, think of Snowden. So, in view of the insider attack problem encryption doesn't give any prediction at all. So, one requires access control and the access control will have to be enforced. It cannot be enforced by the data controller. Simply because insiders in the data controller are what you want to protect against. So what is the requirement that the data cannot be accessed without authorization with a purpose violation and this almost necessitates online regulator to affect that access control. The access control can be affected only by a independent third party which monitors it and which has got a oversight and this oversight cannot be offline. If the oversight is offline, then the data controller is unrestricted and there is no way to do a privacy protection theoretically. So it's absolutely impossible. So this necessitates an online regulator. And an online regulator moment you have an online regulator is physically separated from the data controller. You have to bring in this notion of remote execution. So these are, you know, straight implications of impossibility of absolute privacy and prediction against insider attack. Prashant also mentioned about purpose limitation. The data controllers must declare purpose operant and mechanism should exist only to allow computation that fulfill the stated purpose. Now, again, the problem with data is function click, right? And this is an obvious problem that you, you know, I think Srikant has put up a comment out there saying that there are some stated purpose and there's some unstated purpose and purpose keeps on expanding.  So purpose limitation, purpose violation can happen in two different ways. One is a direct purpose violation. Use the data directly for surveillance of putting a tab on somebody and so on so forth. There are indirect violations for deficient beings programs, you know, so you discover things about personal identifiable information that you did not intend to and that's also a purpose violation, right? Or, you know, you can also end up doing discriminatory processing unknowingly, you know, for certain communities groups individuals and so on so forth. So those are all come under the ambit of purpose violation. And so if the data controller must declare the purpose of print and there has to be a mechanism to allow computation that only fulfill the stated purpose. This almost automatically suggest pre-ordered, right? Pre-ordered of code, pre-ordered of algorithms. Now this cannot be done automatically, unfortunately, you know, nobody can do a static analysis of an AI program. So this has to be a best effort offline pre-ordered analysis that a regulator must do and the regulator capacity has to be built up if you ever want to build national scale systems. So these executables or these programs, the programs that will do the data processing, they have to be pre-ordered, signed and sealed off by a regulator and thereafter they have to have untimperability guarantees. Both the programs and the data types they work on, right? This is the only way to prevent purpose extension and purpose violation. And also the regulatory boundary must exist to edge devices. For example, you may define purpose limitation and build an electronic health record and put, you know, purpose limited processing requirement on the, on maybe or whoever is maintaining the data. But ultimately the data will have to go to a doctor's terminal. You know, your electronic health record is useless and there's a doctor can access it and a doctor can then save it on this hard disk and sell it off. So the regulatory, so the doctor's device cannot be outside a regulatory boundary and if that happens in purpose limitation cannot be implemented, right? So the regulatory boundary must access, must must extend all of these devices also. The third necessary condition that Prashant mentioned yesterday was legitimate purpose depends on dynamically changing concerns. So there are, you know, certain authorization and access pattern that happen using static rules. Like, for example, you know, there are static rules about income tax, there are certain static rules about health, where doctor diagnosis is something there is some static set of tests that must follow and so on. So there are static set of rules. But also there are dynamically changing levels of consent approvals and authentication constantly. You know, for example, if I go to a doctor, I have to give consent for the doctor to access my data. And these are dynamic things. So this architecture must support very high speed dynamic consent and approval architecture. So there has to be a static part, there has to be a dynamic part. So that's also a necessary condition. And finally, that any time the data leaves the regulatory boundary, you know, goes out and the data is, data is disseminated in some form, then appropriate data minimization is necessary. And, you know, one has to be very specific in this requirement, you know, one cannot say anonymization. As we saw yesterday, that is no meaning. Right, anonymization in computer science is understood to be a quality concept. So data minimization, depending on the use case, you know, you have to bring in anonymous credentials, you have to be very virtual identities, you have to bring in, you know, for KYC, you have to see what is the minimum disclosure that is necessary for KYC. For example, you know, I should be able to just say that I have a valid driving license without showing it and showing my disclosing my name if I'm caught on a traffic violation rule. If a policeman stops me on the road, I should be able to prove that I have a valid driving license, but without, without disclosing my name age, and so on so forth. So these are standard techniques in computer science have been there for decades, 40 years. And these have to have to come in for the various data minimization techniques. We would also like to argue that access control remote execution online regulators and purpose limitation is the key to privacy protection. So once you have this. It is also sufficient. So you don't ever allow any processing that exceeds the standard purpose, right, and you don't allow any unauthorized access whatsoever, and this is controlled online. So you require proofs that an authenticated entity is accessing and the authenticated entity even after taking the data cannot exceed purpose, right. So we would argue without giving a proof because this is too difficult to be approved that this is not only necessary but also sufficient. And I think that through the next 30 40 minutes Prashant with illustrate this with case studies as it goes on. So, you know, our paper has a very complicated message. And so why have we written the paper talk, you know, the paper does not suggest immediately a practical implementable architecture, right, so that will have to slowly come. So this is more of a concept of what is required, and not a solution that can be implemented straight away. So we have messaging for diverse groups. So we are messaging for CS researchers. You know, like such as myself or Prashant or so on so forth. And I think our message to them is that think of privacy not in terms of crypto as a contribution. This is not the way to think of privacy the way we have been traditionally thinking. Think of privacy in terms of put us on me put us on me one not so much put us on me to don't ever think that way. Warren and Brandon Salove in effect with architecture that will present is very strongly motivated by solo Daniel Salove the digital person. You know, he almost suggests this architecture without giving up the details and we have operationalized some of those ideas. So think architecturally and fill up the gaps right so wherever this architecture that will present will have implementational gaps and it's for the CS researchers to work on. Our message for CS developers also government, you know, big time for the government. All of the above and phrases like best encryption industry best practices data is safe unhackable 100% secure privacy by design these words have no meaning. They are meaningless words and they should and do it out and confidence. So anonymization. You know, each of these will have to be qualified always. Unhackable is an undecidable concept whether something is hackable or not is undecidable. Right. It's a it's recursively enumerable without being recursive and hence it's an invalid question in the first place. Nothing ever is 100% secure privacy by design.  You know, these, these are not the vocabulary that should be used in the context of privacy. So when we talk about privacy of design, as we do, we will qualify it over the next part with an architecture and what we mean. And our message for the policy and legal for primarily I think is that that we do need operational standards against which public services must be. Measure must be held up. You know, we need definite standards for evaluating things like say other public registry electronic health record system, dbt system.  Right. I think that what we are saying kicks in after you have decided that such a thing have to be whether that such a thing will have to be built or not is a larger question. But once you have decided that such a thing have to be built. There are certain operational standards for privacy that are that are required. If you don't have those operational standards, you will not be able to measure to what extent. An implementation proposal meets privacy, you know, in a legal or an or an ethical sense. And the proportion analysis will almost always be incomplete and especially the balancing part. Because, you know, unless you sort of quantify, you know, in some ways, the extent to which you can protect privacy. The utility versus privacy balancing will almost always be vague as we saw in the put this on the two judgment. I mean, it was random different judges said different things they interpreted things in a completely different way. And we argue that such a thing will continue to happen. So I'll stop here. I'll give with this introduction with this motivation of why we are proposing a particular architecture. I'll hand it over to Prashant to actually present that. Thank you. So I'll stop sharing the slides. Yes, if there are any questions on this, I'm happy to. Anyone has any questions on any of the statements made by Professor Benadji? I see one hand. Okay. Hello, Chinmay. Is that you? Can you? Yeah, that's me. Hi. So I just had a question about one statement you made, Prashant. And that was about the fact that these concepts of privacy of my design or anonymization or any of those concepts have no meaning. Are you specifically referring to these as defined by certain group? Or are you talking about this as generic principles of privacy internationally? Because I want to understand what's your context of speaking. So I think that anonymization in particular what we talked yesterday that anonymization by default have to be assumed that now hypothesis is anonymization is always breakable. There are theorems to that effect. That is almost impossible to anonymize, except in some very, very special cases, right? So whenever you say anonymization, those special cases will have to be brought in. In a generic case, there are no way data can be anonymized. You know, any statistical data that you anonymize, more often than not, can be de-anonymized with relativism. So similarly, you know, when you are talking about privacy by design, the privacy by design will have to be qualified in terms of what aspects are you talking about? Are you talking about a statistical privacy protection? Are you talking about privacy protection of personally identified information? Are you talking about purpose limitation? Are you talking about access control? Are you talking about inferential privacy? Are you talking about differential privacy? So I think that, you know, it is data. So data processing has certain algorithmic consequences, right? And those algorithmic consequences are reasonably well understood. And, you know, for example, it is well understood that if I give you the data, if I hand over the data, then I will never be able to put a bound on what you can do with the data.  Once I give it to you. So what harm will come to the data cannot be determined a priori, right? So can I come in here, please, Roshan? Yeah. The thing is that you're making a blanket statement that these designs, these principles are useless. But honestly, these are principles to be followed by people who build the systems. They are principles in the sense of principles that don't need in detail definition. So I strongly think that this is not something that I agree with. Like you yourself said, I understand anonymization. There is enough research to say that it's hard to do anonymization, but still there are differential principles. There is theory around a lot of how much anonymization can be done to an extent. So these are all principles in the sense you can interpret in ways, in different ways. And I agree with you on that, but I wouldn't blanketly state that these are useless principles. So, you know, misunderstanding. When I say that useless, I would say that just saying anonymization is useless unless you qualify it. So if you are talking about anonymization in a specific context and you show that that anonymization holds, then of course it is useless. But if you just say that my system is safe because I've anonymized data, you know, I think that you will go wrong more often than you will go right. So I am saying that any architecture that you do, it requires you to be more specific, more precise. But that's also dependent on systems, right? And that's why we are thinking that what are the principles that you have to uphold when you are building systems? Yeah, exactly. We'll come back to this again. I'm going to hold you there. We'll come back to this again because I believe Prashant is going to explain some part of it again today. Principles and how he intends to operationalize it. Hello everyone. Can you see my screen? Yes, we see a data controller. Okay, so building on the energy explanation and the motivation of why we need an operational architecture. Basically I'm presenting trying to illustrate or an electronic health record example. And again, this should not be seen as we are proposing how to do electronic health records, but just as an illustration of the architecture itself. So just without going into the notation initially, what's the workflow we are trying to illustrate here is that you have a patient who who gets an approval to get an MRI from a doctor and he gets an MRI done and that MRI goes to a database. Later on, he goes to some other doctor who features the MRI information from the database and describes medication and whatnot. And separately you have another path where you're trying to do some kind of disease analytics or epidemiology. And this is the machine learning part of it and is a statistical analysis path. And so clearly, like we discussed yesterday, there are privacy concerns here. For example, the doctor may sell your medical data from here. You may have inferential privacy losses from the analyst here. And in general, from both of these agents, you can have purpose violation either automatically or manually. The same is true for any other kind of system in between. Basically, any insider who has access to either the database or the program accessing the database can actually steal your secrets. Given that they have the right kind of access to the database, your privacy is actually just on the mercy of how well the data controller has protected the database. And we are trying to provide an architecture which protects against these kinds of privacy risks. So the key primitive we are using here is called a trusted executable or a TE, which is essentially just an abstraction of an environment or a program which basically gives you the secure remote execution kind of guarantees, which we talked about yesterday. And essentially what that means is that this program is a box is an isolated box. And whenever this program runs its confidentiality is predicted, meaning any of its intermediate or output data is not connected to entities unless the program is explicitly instructed to do so. It also protects integrity, which means that while the program is running, nobody can tamper the execution of the program. Basically, this program is approved by a regulator. So, and this is the point where the regulatory capacity comes in. So basically, the idea is that if you as a data controller want to do some processing you load these programs as candidate programs to a regulator and the regulator analyzes them analyzes the utility of those programs analyzes the privacy risk associated with those programs. And if it feels that it is appropriate. It allows you to execute these programs. These programs do live in the physical infrastructure of the data controller itself. So they don't live in the physical infrastructure of the regulator itself, but they are actively controlled by the regulator. And that is represented by this valve kind of symbol, which is meant to denote a flow control valve. And it is essentially controlling the flow of information along each of these channels. So I am denoting them by ACR, meaning it's access controlled by a regulated R. And this ER represents that the data on this channel is encrypted and this encryption is controlled by the regulator. So the regulator when it decides will give access to the keys and when it does not decide it does not give access to the keys. And these DT1, DT2, all of these things just basically represent different data types which flow across these channels. So for example, this DT1 here where the MRI features information from the database represents the age of the patient. The patient is represented by X. So DT1 of X represents age of X, sex of X and the medical history of X, which will perhaps be useful by doing some processing on the MRI. So the key idea is that we have this kind of remote authentication property and we talked about this in the context of Intel SGX yesterday. It was called remote attestation where programs can prove to a remote entity that this is running or rather the hardware can prove to a remote entity that a particular given program is running. It is running within an enclave and the hardware will protect the confidentiality and integrity during runtime. So that process of authenticating remotely is what is described here during the regulatory access control. So once the regulator is convinced that the data is going to this given trusted executable and will be processed in a certain way, then the regulator can basically open up this wall and allow this decryption of this data to happen within the TE. And that is the general approach. Now of course, the regulator's decision of whether something is legal or not depends on a lot of factors, not just what program you are running, but also on perhaps on whether you have appropriate consent from patients. And we have argued that consent is not enough, but it is nevertheless one of the contributing factors towards the regulator's decision making process. The regulator may also require that you have the necessary approvals from the doctors or in some other cases from other appropriate authorities. It needs to see that whoever is accessing the data finally, they have the proper arrangements and whatnot. And in the process of doing so, the regulator will need to talk about talk to a separate identity authority which provides this information to the regulator and again in a similar privacy controlled way. And so this is the rough overall architecture of how the data and the regulatory accessible. We want to basically zoom into the regulator itself with respect to what kind of architectures the regulator would need to implement on its own and to enable this. And that brings me to the two. So here you see that the central job of the regulator is this authorization architecture, which is your access control decision. And this is driven by a set of static rules and the static rules basically capture when you would consider it appropriate for a given processing to happen. So they may take the form that if you have a certain type, if you have certain kind of approvals, then you would allow this particular TE to receive data of this particular type and send output to this requester whose credentials I just sent. And of course, the framing of these rules has to be driven from a prior privacy risk assessment of the keys that were uploaded for approval and also the privacy risk assessment of the various data types that they are asking to process. And so this is the static rules part of the authorization architecture, but dynamically at runtime, you have this dynamic authorization architecture, which depends on first for these consent and approvals from various individuals. And secondly, authentication of not just the individuals themselves, but also the keys, whether you are actually running this particular tea or not. And this is exactly the remote authentication or remote attestation part of it and authenticating the data types, whether the data type that we're actually going to see is actually of the type that you claim it to be. And so that will basically cover the regulatory architecture. And here I have a simple workflow example, where, you know, this patient visits his doctor and the doctor wants to access the patient's data. But the static rule in the regulator's privacy policy is that unless a patient X has consulted with a doctor Y, if the patient X says that this is actually true, only then you allow Y to access this data type DT3, which I have defined earlier. I think it means to access all the medical data of the individual. So only if these conditions hold true, then allow the doctor Y to access this data type DT3 via this TE. So note that no individual directly accesses data. And this is in line with what we said earlier that given the impossibility of absolute privacy, the only recourse is that you don't allow arbitrary access and processing of data. All access and processing should be controlled and this is what this static rule is trying to achieve. And here you, there's just some steps on signing the consent statement, which is, so now note here that the patient is not consenting to something after knowing exactly what processing this data controller will do, because it is really meaningless to ask the patient to do that. What is meaningful is to ask him whether you did willingly go to this doctor or not. And the rest should be taken care of by the static rules or the responsible privacy policy that this regulator has designed. So I think this should be enough to give you an idea of what the architecture is. I think I should break forward questions here and then I will move on to some other case studies as well. In your current architecture, you have proposed the rules, right? The rules are essentially what a regulator would define. Yes. But would there be a control for an individual to change these rules? For example, the regulator could allow some decisions to be left to the individual. Right, so that is kind of part of this rule. So you can make these rules as modular as possible if you want to do that. But honestly, it brings us back to the question of how much privacy self-management one gives to the individuals themselves. So if I may answer that question, what this will then require is a grammar, right? And so this grammar of what part of the static rules will require, can be parameterized by the consent people or the individual, right? So like in this case, we have just talked about an approval, but the approval architecture can, you know, through the same mechanism of the approval architecture, the rules can even lead to special purpose, special purpose condition checks that if this happens, then allow access. If this happens, then don't allow access, right? So those can be parameterized by the approval and depends on how complicated the grammar is. So you can design a full programming language, for example, for the static rules. And yes, so you have to fire various rules under various conditions and techniques for all of those exist. Thank you. I see more people wanting to ask questions. I'm unmuting them one by one. So I just wanted to understand that like regulator seems to be so for this architecture to work, we need to trust on the regulator side. So what would happen in case that trust is broken from the regulator side and the second case in which the regulator itself is compromised? Can I get access to the entire system because like everything works around a key which is issued by the regulator itself? I may add one more question to that. What's he essentially hinting at is you are proposing a regulator with say a bureaucrat who is going to handle this, but at some level you are also proposing automated regulation, right, where you are defining those rules. What level of automated bureaucracy are we looking at? This is an addition question to what just Abhishek asked. So I think there are two components to trust on the regulator. One is that trust on just and lawful policies themselves. And second is on the operational aspect of it. Given that the policies themselves are fine and the TEs that you are approving are fine, whether the actual operational code is adhering to those privacy policies and the TEs that were approved. So I think the second point which is the operational aspect of it can be easily done by just doing the same approach recursively. So basically all the TEs that you approve and all the policies that you approve, you make them public, right? And then at that point and you sign them, anybody can check at any point whether all these regulatory operations are also happening within a TE. So can, are they actually authenticated? So anybody else can also do a remote authentication on any of the regulatory components themselves. That will give you and I think this, practically this may be an internal process at the regulator itself. But if you want or if the situation demands it could be potentially made public also in terms of what kind of programs you are approving, what privacy policies you are allowing them and so on and so forth. So I see that at some level this is the whole issue of bringing in proof, right? Through cryptography. Absolutely. Can I add on? So, you know, so for example, in this case, the regulator cannot access the data. The data is with the data controller. So the regulator can do, if the regulator is untrustworthy, what he can do is that he can mount a denial of service attack, right? Not allow any access and so on so forth. Or do random attacks that allow random accesses and so on. So one fundamental assumption is that the data controller and the regulator won't call you. But if they do call you, then the standard solution to that in computer science is to have multiple regulator and do multi-party computation. So you can say that at least two regulators or at least three regulators have to do a threshold computing. Two out of three will have to grant this access before this access is granted. This is something that you do routinely in say electronic voting and so on so forth for decryption. So at least two people must allow a decryption out of three or some majority or a threshold rule before this can happen. So that extension from one regulator to a multiple regulator is standard in computer science. It can immediately be proved in. The major part of all this is the proof that so you have to get in a proof system in this communication between the regulator and the data controller. So the data controller will have to prove purpose will have to prove authentication will have to prove authentication of these to a regulator before a consent is granted. Now question is that it is an online architecture. Yes, conceptually can this be implemented. Theoretically is practically is going to be very, very difficult. Right. So our purpose is not to suggest a practical implementation. Our purpose is to lay out the standards of what is required for privacy protection. So I would argue that if you don't do this, you know, regulatory access control, then theoretically you cannot protect privacy. You cannot if you make the don't make the regulator online and don't have access control then data will invariably sooner or later. Through insider attacks through security breaches. So and once somebody has access to the data, personally identifiable data. Privacy protection is impossible. So, you know, there is no absolute guarantee to privacy once the data is out in the public domain. So strict access control is sort of essential. And, you know, so the question is how far will you know that's a political decision that whether you want to do this. You know, so much of it or you want to do parts of it and so on so forth. But this laser standard that if you want to have full access control, then something like this architecture with a remote secure remote execution is necessary. If the regulator is untrustworthy, then you have to bring in multiple regulators and symmetric multi-party communication computation. So you have to have threshold computation that at least two or three people must agree before a competition is allowed. I have one more question from Suhan. Yeah, Professor Banerjee's explanation on multi-regulate, multiple regulators and threshold proof systems and things like that actually just clarifies the question. Thank you. Hello. Yeah. Yeah, I have another one. So I feel that this architecture revolves around the regulator instead of the individual or the data owner. What sort of access rights or sort of policies can an individual data owner make on the platform? So for example, what if I want to delete my data from the platform itself and what if, like, will the regulator play any role in that particular things as well? What if I want to modify it? What if I don't want to give any sort of access to any doctor because it's my personal data? So you know, do I need to get approval from the regulator to do that? Yes, because you don't get consent and the regulator won't give access. So that depends on the static rules. So what the static rules, the use case is defined. So every use case when it defines a static rule and the static rule is what will give the individuals the power. So individuals are just parameters in the static rule. So individual is X in the static rule. So individuals have to provide an ID. And you know, if the static rules give individuals large powers for data deletion, then the individuals will be able to do it. If the static rules don't give those powers and the individual will not be able to do it. So your privacy protection architecture is primarily designed by the authorization architecture that what every actor is authorized to do. So what we are saying is that that this will change from situation to situation application to application. But whatever it is, it has to be laid out that transparently completely out in the public. The static authorization rule is an encoding of your regulation in your laws. So what Sanjeev was talking about yesterday, they are capturing the law and logic as a set of conditions or programs. So these will have to be fixed, analyzed, assessed before an application is completely rolled out and also modified as you go on. But whatever the static rules permit, the individual will be able to do it. Whatever the static rules don't permit, the individual will not be able to do it. So individuals will appear as parameters. So static rules will say that X can delete the data if X meets this condition. X is an individual. So X puts a credential and if those credentials meet those conditions and if the rule permits, then it will be able to delete the data. That's the way it will look. So it's a grammar-based predicated situation. And who would create these access rules? That will have to be the regulator. So we are saying that regulatory capacity is crucial out there. Regulator or a set of... So these rules, they arrive with the regulator, they have to be made by the regulator and we can demand that the regulator makes it public. Science it and makes it public and the regulator cannot change these rules without announcing it in the public. Blockchain will do that, for example. I see there are some people who have questions in the chat. Do any of you want to directly ask those questions to Prashanta, to Professor Subshash Penarjee? Just please raise your hands. But okay, there is... Hi, so my question is basically what I've put in the chat. Your overall architecture places a data controller at the center. Is this assumption sort of flexible? So can these trusted executables, for example, execute on an edge or something controlled by a plant? So that there's sort of less reliance on the static rules. Are you aware of any such approaches or do you have any opinions on this? I'm sorry, Divya, I apologize. Can you reframe? No, so I think that is about edge devices, right? So, you know, for example, the example that Prashanta gave, he assumed that a trusted executable must run on the doctor's terminal, right? So this is a very serious requirement. So he's a TE doc, that's our doctor's terminal. So he is assuming that the regulatory boundary extends all the way to the doctor's terminal. So what this would mean is that the doctor cannot access the data using any laptop that he owns, right? So this has to be a laptop that is approved by the regulator and the regulator must have an ability to run a remote execution on this laptop. So this has to be an approved access device. And the data that goes out to the doctor will have to only be suitably minimized, right? So he can look at graphs, he can look at tables, but cannot store anything on his hard disk. So the regulator will have to ensure and the doctor will have to give a proof that the doctor while accessing the patient's data is not transmitting out through the network or is not accessing the hard disk to dump the data on his local disk. He's just viewing it from a terminal. So of course he can take a photograph and that can't be prevented, but that won't scale, right? So, yes, so I think that for this, so the question is that do you want it or do you not want it? It depends on to what extent you need to go to privacy, but if you don't want the data to work at all, then even S devices will have to come under regulatory control. And so the data controller in this case, you know, there are multiple data controller actually. The doctor's terminal is actually a part of a data controller. And so the question is that there can be multiple data controller, but all of them must be under regulatory supervision, regulatory oversight, right? And one regulator or a team of regulators as the situation demands. That's what the architecture is. I think Duryan has a follow-up question. Yeah, sorry, slight follow-up. So yeah, what you said about the edge devices makes sense, but in this diagram that's sort of on the screen right now, this data controller and the database is at the center of it. And so is the regulator. So this seems like a more regulator-centric architecture. Are you aware of any approaches where a user or a patient sort of retains a custodianship of their data and sort of the rules start from there? So even in this, the patient, so this is, you know, so like what Malvika started out with, that this architecture assumes that you don't want to do for privacy self-management. And the reason is that if I'm a patient, you know, even as a professor of computer science, when I am ill, like with, I'm going with a stomach upset or God forbid COVID, I don't want to worry about architectures, right? So I would like somebody to, somebody else to take care of it. So this is an accountability-based framework and not an individual-based framework. So the individual in this situation just gives a concern that I'm meeting this doctor, right? I am going to do this doctor with this complaint and then a set of regulatory rules file, right? That whether the doctor's access is legitimate given that kind of doctor he is and the kind of patient this is. You know, for example, if I'm born with a throat complaint and you are asking for a genetic profile, then one of the regulatory static rules should prevent it, right? Now, whether it is meaningful to ask a patient that you allow this test or you don't allow this test, right? I think the regulatory framework would be better formed by some ICM or guidelines rather than asking individual patients. So the privacy self-management obligation on the patient is a little low out there and we have an accountability-based framework for the regulatory. Now, that's what we are proposing. I mean, I'm just going to quickly ask a follow-up, maybe add a comment. Sorry for jumping in, but I'm also thinking that, you know, the question of whether the individual trumps, is that the question that you have this kind of system that's running in the background and can the individual at any point come in and trump a static rule? Is that the question? I think yes. And again, that's something we would need to agree that, you know, do we want to and potentially, yeah, there would always be some kind of right in relation to personal sense of personal data like health records, but I suppose. So in this case, the regulator, the only way the individual can trump is by revoking consent. That is always possible. Yeah. Okay, Anush. Yeah. I just want to understand a bit around the identity authority. I assume that it is going to be, it's going to generate virtual identities, but as in, do you see it working outside of this use? You mentioned that it is an independent authority. So is it independent in general? And if that is the case, then is it going to be as in, how do you see it working out in reality? I think it should be independent of the regulator, you know, and independent. And of course, it should use anonymous credentials. It should use virtual identities for, you know, all the data minimization principles, right? And I think that there are identity authorities that are based on those principles. You know, you have these, what are they called? These blockchains based identity management systems that do anonymous credential chom style and that do zero knowledge groups and that do virtual identities. So we have not designed an identity authority. So we assume that there is one such identity authority which is capable of doing anonymous credentials and virtual identities. Yes. Okay, but you haven't given a thought as to, you know, how this identity authority is going to be managed in the sense that is it going to be centralized or especially in a public infrastructure? In a public infrared, you know, so we have a lot of thought on it, you know, I think that the management centralized is not a problem. I think if you look at Estonia, there are identity authorities managed on a blockchain. A blockchain is multiple centralized, right? So it's only the control that is distributed, but the storage is centralized. So that seems to be the most common model. There are uncommon models like Agha. But, you know, I think that the centralization is not the issue. I think the biggest management of an identity authority is not a big problem. I think computer science knows how to solve that problem. What is unsolved and difficult about an identity authority is the generation of the identity. From where do you get your identity? Like, you know, for example, in Agha, it comes from biometric and I'll have a lot to say about against it. So that is a difficult problem that, you know, what makes your identity and that isn't as yet an unsolved problem in computer science and I'm not going to add this right out here. But once an identity is somehow established, the management of that identity is in a transparent way in a provable way. That can also be put under a similar regulatory oversight for the identity authority will have its own regulator or a set of regulators that will monitor it. It'll have its own trusted executables that dish out anonymous credentials and does authentication. So some such architecture can be done. What is difficult and I have no answers for is what is the origin of that. That's a that's a tough question to answer. Right. Thank you. Okay, I think Srikant has a question. Yeah, so I'll be divided into multiple parts. So this by understanding what I get. This is a surveillance less design. But is there a less surveillance design because I'm just being practical here in the sense that we cannot or we will not probably have an environment where surveillance less design is kind of politically approved. So is there a possibility of a less surveillance system. Yes, that's one. And the other thing is, we have seen that there have been multiple stated and unstated interest. So even in the case of your dbt example, the reason why we chose to have a centralized other mapper and the dbt interest that we have today as against the model that you proposed is that there was an unstated aim or even in some cases even understate the aim of serving micro credit to these subsidies as a guarantee and that was basically part of the problem which your approach did not kind of. So basically, if you add more requirements, then the solutioning has to be slightly different. In which case, how do we design something where the requirement which could be a policy of the government would keep on changing. Now tomorrow, another government can come and assume that this decision must serve me this goal. And how does one design when the policy context is dynamic. And then the last question is how do we kind of design this in terms of cost because the current systems by being centralized in nature and data inclusive. They do make a case that they are cost effective or the least cost solution. Whereas in the case of yours, you propose a hardware based model plus the cost of identity issuance which you've said you've not. You mentioned that the identity issuance is not something that you'll focus too much but identity issuance will be a possibly a pair especially if you're going to the virtual aim. So how do we get the cost. You know, I'll answer and I think there's some misunderstanding about the objective of it. So let me clarify by first saying that any application that you build and the scope extension of that application is a political issue as it should be right. It should never be a technical issue that whether you want to build an electronic health record is not a technical question at all. It's always a political question. Now whether you want to build a DVD system is again a political question. Whether you want to extend its function, do purpose limitation or purpose extension. This is something that will also have to be politically settled. This cannot be technically settled. So, you know, that is a far more interesting problem than what we are proposing. Now, once you have declared the purpose and this is the current purpose, right, so, so now any unintended purpose extension is what we are talking about should be prevented.  So, given that you have got a certain purpose definition, if you try to extend the function by a function creep, like without passing a law, that is the obligation of the regulator to prevent. And we are suggesting a method of preventing that right. We are actually not even suggesting a method of preventing that we are, you know, we are never saying that they should be implemented this diagram should be implemented as is. We are putting out this diagram as a method of understanding the privacy problem. Right, we completely understand that this is unimplementable because of his complexity.  So, we are not advocating immediately that you build this identity authority, you build this regulator and you build up this way. But I am, we are suggesting that you look at this diagram and use it as a yardstick of to what extent the privacy goal you have met. So, if your regulator function falls short of what we are proposing, there will be certain function, this privacy compromise. For example, if your regulator static rule is what defines the purpose. If the static rules can be changed arbitrarily by the regulator itself or by somebody else, then there's a function tree. So, we are saying that you have to build technology and and and law instruments so that this regulator makes the static rules. These are publicly viewable. These are untimable, unchangeable. Without an explicit signed action by the regulator, which is visible to everybody. So, unless you have this, there will be certain privacy compromise. So, every time you dish out a system, whether it's DBT, whether it's Aadhaar, whether it's an identity system, whether it's an electronic health record. This diagram will help you to understand that where is the compromise line. Is it in data minimization? Is it in a function creep for the regulatory action or all the static rules completely laid out? Or is something missing or are you being unable to make the static rules public? Or can the regulator change the static rules surreptitiously? You know, all of these entail privacy risk, right? So, we are saying that to have a complete guarantee for purpose limitation, this is the requirement. If you don't meet this requirement, purpose extension will happen. You cannot guarantee that there will be no purpose extension, right? Purpose violation, function creep and all that should happen. So, the way to do purpose limitation is to capture the stated purpose and the laws through a set of regulatory rules as a programming language, right? Which should be visible to everybody. Put it up on a blockchain perhaps, right? I mean, commit it as a cryptographic commitment and then the regulator cannot go back on it, right? So, this is what is required. Whether this can be implemented, probably not, right? It will be sort of very hard except in a small system. But what we are saying is that through this operationalization, the privacy landscape becomes completely clear, right? That you have to make your regulatory boundary go up to these devices. You have to have the right kind of anonymized credentials. You know, every time you have to do a data exchange, you have to evaluate the amount of number of bits of information that you are leaking. And the static rules tell you that what is the purpose extension that you are doing. You know, whether you can change the static rules, that's a political process as it should be always, right? So, you change law and then change the static rules. That's what we are saying. If I can just quickly just add on to that as well. I mean, just on the regulator's discretion itself. I mean, I think this is where the technical and the regulatory architecture need to go together because there are things in the PDP bill which will continue to be fleshed out. Which is why, you know, we need like a kind of joint approach to this. Some of the basic institutional design mechanisms which are in place, even if you have a regulator, because even they are bound by certain, and I don't mean computer science rules, but general rules. There are certain discretion fettering mechanisms, the design of the board of the regulator, the operating manual that is passed for the regulator in the first few months that it's set up. Literally, you know, it states that every change that I make in relation to, say, if such a system were to exist, if I was going to manipulate and change those rules, I would need to publish them. If I was going to make regulatory rules, there is a need for, say, public consultation, right? That's why we all have these public consultations. Those are all coming from certain discretion fettering requirements that operate across all regulators. And I think that, to one extent, it is how that regulator is set up, the choice of the person is the political question there. From there, we already have some kind of levers within the existing law and hopefully in the future regulation where you can start setting on the regulator the constraints, the consensus rules regarding when they can change, when they can change rules, when they shouldn't even within such a system. So, I mean, I don't know if that was helpful, but I think even the political questions to some extent do have fettering mechanisms through existing regulation in terms of how such a regulator could act when it changes something or chooses to or not. Okay, Suhan, you're up. This is for Professor Banerjee or Malvika. This architectural diagram is basically a logic filter to see whether a purpose limitation happens or privacy is working or not. Now, looking at it from an implementation perspective, I'm just throwing out an idea that this could perhaps be implemented in a very, very modular distributed architecture type of framework, possibly. And should therefore the role of a DPA as in like the super oversight regulator kind of be someone who just orchestrates logic filters vis-a-vis privacy to see whether it's actually working in the various domains and various sectors and matching up to certain principles and that should be the core function of the state or a DPA appointed by the state because the regulators could perhaps also be sectoral folks or other sectoral regulators or say even an industry association or a self-regulatory organization. So, any thoughts on that from you, Professor Banerjee or Malvika? I would say, depending on the situation, the regulator can be a self-regulatory if it's a small government department. It can be like in IIT, we have got an audit that prevents us from purchasing the way we want and they're pretty adversarial. They don't allow us to do anything at all. I sometimes think that they're just too antagonistic. So, within the organization regulator can work in some cases. But if you're building something like an electronic health record, I would advocate external regulators directly under the control of a DPA. If you're building an identity system, national level identity system, I would advocate the same that you have to go through a multi-regulatory system which is outside the organization. Within regulatory, within and same authority can work in smaller system, but for very large system that's probably not such a great idea. But this architecture allows for both. Now, regarding the implementation possibility, I think that this architecture can be implemented today with some small caveats. We have not done our stress testing, but I think that the SGX technology is pretty well established. So you can do this remote execution, you have commitments, enough cryptographic tools, so that such a system can be built. Now, the question is who can build it? Definitely an academic can build a small system. But whether it can be built at a national scale, then it's not just a technical question, it's also a capacity question. And I think that there will be several challenges in building such a thing and you have to do an overall scaling and so on. But this particular paper, that's not the objective. The objective is to roll out the privacy landscape and to say that what is necessary for a privacy protection, what is sufficient for a privacy protection so that you can have a benchmark of what is required for privacy. Thank you. Thanks. So at some level, what you're proposing is very technology implementation that still needs to be adapted for specific needs of an individual department. But what you are witnessing currently right now within the country is at some level, you're copy-pasting whatever Estonia has done. But you are also at the same time trying and plugging in these other interests like Srikanth was mentioning, for example, microfinances and interests. And when you look at, say, the whole issue of ROKC, we suddenly see electronic health records have been plugged into it as an interest. And contact tracing was, while it could have been the primary interest, you have a secondary interest which has been attached. So what would it take, say, to review some of these upcoming infrastructures? I'm specifically asking you about the whole India Enterprise architecture, which I believe the standards for it are out and we are already building them. So I would say that even if you have to question such a thing, right? So suppose you don't like it. You don't like Arakus et al. You don't like the note thing that you're talking about, right? I don't like the use case and utility, but suppose the use case, suppose we grant it that there's an use case and there's an utility. But you don't like the implementation because you think that there's a privacy leakage risk. Then even as an opponent, you have to ask the right questions. And the right questions are, the right questions are we are saying that do they have access control? Do they have purpose limitation? Do they have access control rules that are transparent? What is providing the access control? If you're saying that my hardware security module is providing the access control, I'll say no. The hardware security module, which is controlled by the same authority and you're putting encryption under the key. It does not produce an IoT access control. So if somebody throws out that I've got encryption, I've got a hardware security module, right? I think that this diagram will help you question that and will say that no, that's neither necessary nor sufficient. So, for example, in RSA, they are saying that there are some tokens that are getting exchanged when there's Bluetooth. The question is that do they satisfy the properties of anonymous credentials? They have not said that. When it goes up to the central server, suppose I am COVID positive, my data goes up to the central server. Do they have an access control? Who is regulating that access control? What is the guarantee that there is a purpose limitation, right? What is the purpose limitation architecture? So I would say that those are the questions to ask. And what we are trying to say is that once you take this architectural view, even if the solutions don't become obvious, the questions become obvious. These are the issues because we are arguing that this is both necessary and sufficient. So you're saying that if you don't have any of these components, there's privacy components, right? And if you have these components, then you have taken care of privacy and to a large extent, right? So we are trying to say that anytime anybody pushes out something like an RSA or this, that or the other, you need an yardstick to be able to evaluate that, right? Otherwise, you say that, you know, you are leaking privacy. They say, no, we have encryption. That argument doesn't get any better. You say that I have, you know, I am worried about data leaks. They say that no, we are undermining the data. So I am saying that this argument, as we have seen in the Adhar judgment also, these arguments are inconclusive. Chandracharya will say one thing and just as Bhushan will say something else altogether and they'll be contradictory. Right? And I think that to prevent that from happening, you need the questions to be specific, the yardstick to be defined that under what yardstick are you measuring the privacy? You know, I think Shrikanth asked a question about function creep. How do you prevent it? You prevent it through the static rules of the regulator, right? How often does it change? What are the, what guarantees do you have against it changing? Right? So, yeah. So I think that that's, that's what we are saying. In simple terms, I would put it that you're trying to bring in evidence based policy or governance that is lacking in technical systems that are being built. Yes, I would agree. Okay. I think we are almost near to the end of the session. I will open it up for anyone to like come up and talk. I'm allowing people to unmute themselves. Please come in. If you have any questions, please feel free to ask or if you have anything that you want to bring up, please go ahead. If nobody has any of these questions, maybe I should ask this. Do you want more of this? I mean, discussions are on the intersection of both the technicalities and as well as the governance side of these, the regulatory side of these systems. There are more systems that are coming up, like while Professor Benerji described an ideal scenario for data protection and how to build such a system in both technology and regulatory systems. Yes, Rahul, you can unmute yourself. You can come. Thanks. Thanks for your advice. Hi, Professor Benerji. I have a question over here, which is, and I think you sort of answered it, but I wanted to get a little specific about it because there's something I don't understand about this architecture. Rather, how you've led it out of how Prashant and everybody else has led it out over here. And I'm wondering where it fits in in the larger scheme of things. So if there is resistance or a challenge to the way things have been described over here in this particular depiction of this diagram, where do you see the resistance to this idea coming from? I see that it will be hard to implement, given where you build such regulatory capacity or where you do build such data controller capacity. So I think that the first question is that the second is that what are the technologies that you can use to build it? Moment you talk about trusted executables, how do you implement trusted executables? Do you use homomorphic encryption that will make it too slow? Or do you use SGX, which are known to have side channel attacks? So the question is that who will implement it? Using what tools will you implement it? Those are the standard questions that will come up. This is not very easy to implement for sure. Like somebody asked yesterday that programming is a knowledge proof. So programming anonymous credentials, there is no capacity available in the industry. So where do you get such programmers who can program all this? Ironman, all of that is true. So the way I see it is that this defines a set of challenges for computer science researchers such as my colleagues in the department. So if SGX has a problem, either performance or security wise, it is up to them to research and show it. So they have to make this trusted executables implementable, fast, reliably, and a whole lot of techniques will come in. They are already coming in. SGX is pretty matured and they will have to come. So programming capacity to build this, slowly build up only if people are convinced. If people are not convinced, they are not going to do it very easily. So people can program difficult things, but not in cryptography. That is because cryptography is not very common in public life and so on. But the question is, as follows, that if you don't do this, if you don't understand that access control is central to privacy protection and anonymization is not. And if you don't have an architecture for purpose limitation, then function creeps are inevitable, like Srikanth asks that question. DVD started out with one objective and there is a hidden agenda. So the hidden agenda to come in will require a function creep. The only way to prevent that is to have a regulatory code. If you don't have that, then the function creep is sort of inevitable. So this is what is required. So we have argued it is necessary. We have weakly argued that it is sufficient. And I think we all want to say that this is also sufficient. So an ideal situation will require something like this. Whether you can implement this today, I have my doubts. But I am a researcher, so I am not so much bothered about the question of whether you can implement it today. But tomorrow, perhaps, yes. Understood. Thank you. Next we have Sohan. Professor Banerjee, do you think that the Chinese Great Firewall on information and things like that also has automated systems and human beings looking at the system on a real-time basis continuously obviously has elements of this in terms of static rules, etc. that would allow certain pieces of information in or censor certain pieces of information, etc. Is that which is applied in the censorship domain, not in the previous framework, but is an architecture something like this? Would that be a real-world example at scale which may be using similar logic? I know very little about China. I have been there twice. But from what I read from the newspaper, I get a dystopian picture of the thing. I don't think that they have regulatory oversight at all. I think that they are described as systems which are pretty intrusive. I mean it's intrusive. But with logic based on this, in terms of the regulator basically enables access, has access control and static rules vis-a-vis what type of information that you can allow in and out of the country or the internet environment that exists. Intuitively, do you think it's this similar type of logic that they're... Hard to say. From a computer science perspective only. I mean I don't know from a regulatory perspective. It's hard to say. I mean I've got surveillance agencies. For example, it turns out that United States had zero protection. NSA, which is their main national security agency, could be breached by temporary contractors. Snowden, right? That's an insider attack of a great variety. It's that it happened shows that they had no access control. Any insider could access it. I think that if you have that, as Snowden has proved, beyond all reasonable doubt, privacy protection is impossible. If an insider can access things so easily. Now, when you're trying to do surveillance, such as in China, I think they're sitting on high-resolution facing it. The amount of street cameras or indoor cameras that are capturing everything is quite incredible. And there is quite a bit of surveillance that you can do. Processing, identification, re-identification, you can track individuals pretty much. Now the question is that who is allowed to do it? Is there only one data controller that can do it? So that will depend on what kind of regulatory controls they have. So that somebody can do it itself is a problem for me. That somebody can process all that phishing information and do it. I think nobody should be able to do it. But in China, from what I understand, at least one data controller is able to do it. With multiple data controllers can do it at will is something I can't answer. That would be really, really scary if that is the case. Okay, thank you. Abhishek? Yeah, so I have seen there are multiple security frameworks that are coming up right now. And India Enterprise Architecture is one of them in which it talks about how to handle security and everything. Not a coarse grain, but just an overview. So I just have a doubt, maybe any of you can answer it. How can we like converge and make it a unified sort of model when it comes to security or securing our systems, especially on the government side? Because if we have so many systems and every department or the organization within the government itself is working independently on its own architecture, it becomes very difficult to even interoperate and to be scalable and then to make sure that the system is really, really secure. I think that security is distinct from privacy. So security does not give you privacy, for example, at all. Security, I would say is a necessary condition for privacy. But privacy requires much, much more than security. Security is of two types. So one is securing against external attacks. So for example, you've got a system sitting in NIC, can I attack it from outside? I think there are standard techniques available with the government and NIC to prevent it inside. So you have got sophisticated firewalls, inclusion detection system. So 14 external attacks reasonably well is a very well understood and very well established technology. And I think that the government or various arms of the government can definitely do that. When it comes to government, the security threat and also the privacy threat is not external, it's internal. Internal can happen in two ways. One is the organization itself goes rogue. And does start doing surveillance or purpose extension or purpose validation that it is not supposed to be. That's an organizational insider threat. And second is certain compromise individuals within the organization does great access. NSA didn't want to leak the data, but Snowden wanted to leak the data. So security, the big security risks are always insider risks because never external risks. So whether the government is even thinking of insider security risks. When they talk about it, I get the impression that they don't. They don't even consider that as a problem. And at least follow the set to when they talk about security risks, they are talking about external security risks. Nobody would attack a government server from outside. It's much easier to kidnap somebody's daughter, point a gun, right. So those are far, far simpler things than attacking a Cisco fire. So you need security protections against insiders, most of it. And how do you do it? You will need access control. You need very strong access control mechanism. And I would argue that putting a hardware security module and saying I have got access control is simply not going to work. You need a regulated access control to be able to prevent insider attacks. And access control is a crucial requirement for privacy and security both, right. So access control is a security, but purpose limitation is not a security problem. It's a privacy problem and they are slightly different. So do you think a citizen centric security model would be better like considering this internal risk? And is it the right time to do it? So for example, like cryptography and so for example, just taking a case of blockchain. If I tell someone who does not technically know how this system works and how do I sign or how do I use a system or a software to digitally sign and do a transaction. It would be very difficult for those people to actually access the system. So if I shift from a regulator based system to a citizen centric based system, will it be scalable in India? Are people ready for it? I think you cannot make a regulatory centric system. That doesn't sound right. Every system that you build will have to be citizens. There is no other way to build a public system. They have to be for citizens. So when I say citizen centric, I mean giving the entire 100% right to the citizen instead of having a centralized authority around it. I would think that the system should be citizen centric in terms of you should not put any hurdles to access information or get services. So if you build digital signatures, there has to be very, very simple use cases. If you can't design such use cases, don't build such systems. So that is very, very simple. That you cannot do digitization to disenfranchise. That's the first thing. But that's an use case. It is possible to design simple use cases for complicated cryptographic notions. I think that there have been several examples where extremely difficult cryptographic constructs have very, very simple and intuitive use cases from the perspective of the user. The question is that how much obligation do you put on the user for privacy self-management? I would think that given the education level, asking a user to do the privacy self-management is probably not right. I would like a more accountability of a system. So if you are collecting my data, then irrespective of my concern, it is your responsibility to protect my data. And you cannot take a concern from me. That will harm me. I think that is a fundamental, unethical thing that you cannot take a consent that I have taken your concern that it will do this and that will result in harm in some potential way. So I would say that the data, the person, the organization that is collecting the data should have a responsibility and an accountability that goes beyond consent. And that is not to say that consent doesn't play a role. The privacy self-management doesn't play a role. But it cannot be the sole role. The privacy cannot be the sole responsibility of an individual. If you ask me to protect my privacy, maybe I can, but that will make me look at the program of the Android phone that I bought. I may not want to do that. I want to buy an Android phone on trust. So if I have to question every bit of it, if I have to disassemble every app and check what it is doing or run to a colleague and ask her to disassemble this app before I download, that is not the way to protect privacy. That is putting too much obligation on an individual and most individuals, even computer scientists, will not be able to do it, will fall short. I trust the Apple phone. I trust the Apple MacBook. And if I have to examine every part of it, it becomes very, very difficult. So I think that the obligation will primarily have to be on a data controller and regulatory authority to protect most of my privacy. That's all I would say. Thanks. There is one question in the chat. Can this architecture be built into existing projects like say public credit registry or say national health stack? Do you suggest entirely replacing them with this logic? What are the major culps to cross it if this has to be integrated into the ongoing projects? I think that the considerations are very different. So I don't think that an ongoing project, you know, you can retrofit such a model into an ongoing project very easy. That is an engineering aspect that will have to be looked at in a great detail. But I would say they do not be easy to retrofit it in this model.  Whether we can build a prototype? Yes. You know, I'm pretty confident that we can build a prototype. Prashant can build a prototype fairly fast. But whether the prototype will work at a national scale? You know, that is, nobody can answer that, you know, that will require years of testing, stress testing, scaling and so on and so forth. So that's a big ongoing project. What we are trying to say is right now that this is the way to look at privacy. So privacy should be looked at in terms of these ingredients. That's what we are trying to say primarily. Professor Banerjee, this follow up to that question, that was mine actually. I mean, why can't it be retrofitted? That's actually the crux of my questions. Where are the major gulfs? Is it the accountability versus the consent model? I think that we are not used to looking at a regulator this way with an online presence. Right. So that itself is a problem. The regulatory capacity building is a problem. Programming the architecture in this way will require a pretty high performing remote execution environment. The remote execution environments that we know are things like SGX and so on and so forth. They have not really been tested at a scale of say other scale of say national health records and so on and so forth. So whether, you know, so for security remote execution, you will have some overheads. Now where the overheads can be absorbed in a very large application that will have to be evaluated. Also, you know, every time Intel has put out SGX, somebody has come up with an attack. So those attacks are very difficult, very, very tricky attacks, but they are attacks. So constantly there are attacks that are coming from there. Now whether the SGX can be implemented securely for something like an electronic health report. You know, that will have to be again, again, completely evaluate. But if you don't have an SGX and you don't have a remote execution environment at all and yet go ahead and implement an electronic health report system or a national digital identity system. I would argue that you will not be able to implement access control. So such a system will always have a privacy risk of access control. And if you don't have an online regulator, you will not be able to implement purpose limitation and there will always be a possibility of a function creep. So I am saying that while there are existing systems that take care of privacy to some extent, things like access control, function creep are always possibilities with those limitations. So this is something that we have to bear in mind and to prevent this, you need a regulatory architecture of this. You know, that's what we are trying to argue. Whether we can build it today, I'm not sure. I mean, I just quickly to come in, this is Malavika and I see that Ashikant has also mentioned the public registry actually sees a regulator as being part of the data infrastructure. And that is interesting actually because they did whatever we can see from the taskforce report and some of the very high level specs that have been put out that they are supposed to have such a regulator. I think what is what is not clear to us from that report and maybe that is some aspects of this model could be looked at right. I think they have got this purpose based access control, but it's not clear whether there are dynamic access control lists there. And what is the monitoring post post having your access level certified by the regulator and also aspects of the encrypt encryption standards for that and any safeguards like professor was saying against insider attacks right. Those kinds of things are from what we can see publicly and not get visible in the PCR documentation and I think there are some aspects of this that could be taken across. I'm not as Professor Banerjee said then present benchmark obviously the secure remote execution environment creating that itself requires a lot more buy in. But I understand that it is getting I mean it's potentially the costs of that are dropping right Professor Banerjee just on a very feasibility point because I know we didn't have time to. I think that remote execution is available at every laptop and you know our arm trust zones are available on all the Android phones also. They don't let developers program it as we do mentioned yesterday. But I think that those will become more and more common and you'll see more and more use and they will become better and better in the coming years. Right now if you buy a say Apple laptop it'll have a secure remote execution built into it or an Android. Yeah quickly make a point that when we talk about remote execution we also are assuming internet and in India that is not a given. So some of the issues are just like people are on cellular data and if you're doing crypto on cellular data you are just paying for a lot of bandwidth there. So the operational things are like it's not only the end devices so you might have a mobile phone which has trust zone. You have this thing but the link in between is dropping and if you are a doctor's patient and in aims there are 500 people waiting after you. You don't really want internet connection and remote execution to be going on there. So there are really hard systems challenges that in India will face. Of course there are lots of those issues to think about. My other concern is now that the PCR question has come up and I have looked at PCR a little bit with Malavika. My major concern is that if you go to RBI's page on a white paper the level of detailing that is available is grossly unsatisfactory. What are the privacy protection mechanism? What is the utility preserving mechanism? What is the performance that the thing will give and so on so forth. So if you also look at their tender document when they give it out. I have gone through the tender document. It is the first version that was out there. I think they are not giving out any design at all and I think that they are giving out a wish list. And even the wish list is very, very loosely specified. So I would have an objection to building public infrastructure with that kind of a due diligence. I would advocate that whenever you are trying to build something like that the entire design, first at a conceptual level, at various levels of granularity, at various levels of details should be completely made public and be publicly available for scooting. So that the various risks and so on so forth can be well identified. I think that if you build systems under closed doors there is a problem. And to the extent to which you can take care of these concerns are difficult. And I think that it is asking for trouble because you will build such a system and you will collect data around it and then it will go into litigation and people will find problems with it. And it will go to Supreme Court and it will be decided in some random ways. This is not the way to go about it at all. I think that public system and government systems need to be much more transparent in their design objectives and the design should be publicly available. So I have questions regarding the process by which the systems are built. So I don't think that's something I'm comfortable with. Okay, I think we are almost at the end of it. Prof. Banerjee, I think thank you for the clarifications that you had to give out that this does not include all the political side of the issues, for example. But you're only focusing on the technology side of things on the minimum set of things that one needs to ask when such systems are being built. But I guess you agree that there are a lot of these issues, especially with the tendering process that you mentioned. I guess more will happen over time where multiple people from multiple domains will critique in different ways. Thank you on that note. But if nobody else has anything, I will end this. Okay, I will send you all the presentations and the recording by tomorrow. And we will try to get one more posted sometime next month. And I guess August will be the third anniversary of the right to privacy judgment. We still don't have a data protection law. Yes. And let's see how long this will go on. Bye everyone. Thanks everyone. Bye.