 Aditi, been already introduced, so I'll just skip. My interest lies in security privacy and technosocialogy, which is basically impact of tech on humans and society or all. So diving directly into the topic, before beginning, I would like to have a show of hands of how many people have used Android ever or hacked Android. Yeah, all of us. I think all of us are kind of familiar with Android, which kind of makes sense because you're here. So if you have, you would have seen these permission outlets. Like, one appears when you're installing the app, where the app asks you a bunch of permissions. Then you can go to Settings and see what all app permissions have been there. And then the third one is a newly introduced one, which I really like, where you can decide whether you want to give permission throughout the time when you're using the app or also in the background and stuff like that. But we are here to demystify as to what permissions actually mean in Android world. So I'll try to do that in four simple steps. The first part of it is, why are you shown this screen? So if you're trying to code an Android app, suppose you're trying to code a weather app and it needs your location permission, when you add the function of get geocordinate, so get whatever, Android Studio asks you to add this particular permission in your Android manifest file. So in Android, there is Android manifest.xml, which is kind of the central file where all the permissions are listed. So they are shown up here, so uses permission brackets. So all the permissions that the app would be needing would be listed in here. So that is the first part. The app developer defining that this is the set of permission I need in order for my app to work. And when you install, Android picks up the same set and shows you out in the dialog box that we just saw. So that is the first part. The other part is, what happens in Android world? So if you have an app, how Android actually treats that app? So in Android, every app has a package name. And the funny part is it's not even unique. Like com.android.chrome identifies Chrome app, but you can as well create an app with that package name. Although it would not install on your device if Chrome already exists, but that loophole is there. So for Android, it identifies every app with the package name. And the interesting bit here is the user ID. So it assigns a particular user ID to the app, and it has this set of permissions listed on the app. So where can you find the central file? It is data system slash packages.xml. So you need to be root. Or if you're an emulator, you can do ADB root. And then you can pull this file out. And you can see all the packages, all the apps, which are in Android, and all the permissions associated with that app. So now here you see that it is just a list of strings, like Android permission or device power. What does this string exactly mean in OS world? So the next bit I'll show is a really interesting file, which does this mapping of the string with a group ID. Now, Android is nothing but Linux, right? And UIDs and group IDs kind of make sense to us, because we are familiar with it in Linux world. So you'll see that each permission is essentially related to a group ID here. For example, Bluetooth admin has a group ID, NetBT admin. And then there is a separate file, which does the mapping of group ID with the corresponding group code, which is a numeric value. So in Linux, UIDs are used to separate users, because Linux was designed to be a multi-user OS. So you had UIDs so that users can not interfere with each other's spaces. You do not have accessor sources of other user. Android kind of repurposed the same logic for apps. So every app basically has its own UID and a set of permissions, which are listed as GIDs. So that is in brief how permissions actually work in kernel land, in Android. And usually, whenever an app starts, Android has Dalvik VM, which uses to run Java or Kotlin code. Whenever you launch an app, it does not create the VM. It rather folks off a process from Zygot. So Zygot is a central process, which has root access. It has all the loaded libraries that your app needs in order to perform. And whenever you launch an app, basically, it just folks out of that thread. So Zygot has everything. And at the time of working, it assigns a set of group IDs that we just talked about, so that is the permissions that the app would have, and capabilities, and also a different UID. So at the time of specialization, app basically becomes its own app. Like, the privilege is reduced, and it is reduced to the group IDs to the permissions that the app asked for. So that is what happens. And this book, Android Security Internals, I find it really interesting by Nicollet. He has detailed a lot more into what happens exactly in Android kernel land and how security is ensured. So having talked about that, what all permissions can an app declare? So I was interested in seeing what all permissions are there on Android system. And to do that, you can simply try doing PMList, permissions dash f, which will list all the permissions on your device. Now note that not all permissions are seen across all the devices, because apps can also create their own custom permissions, which show up. And whenever you see in any permission here, they would be a permission, a package. Sometimes they also give the description. But the interesting bit here is the protection level. So the protection level can be normal, dangerous, privilege, signature, or privilege. We'll talk about the normal and dangerous one more. So normal is a set of permissions. Taking a step back, Android introduced permissions to limit access. You cannot access resources like location without declaring a permission. Now, the permissions that fall under normal are the ones that developers need to define in Android manifest, but they do not need user intervention. So you can as well define normal permissions, but it would not be shown in a prompt to user. They'll just stay there. Dangers are the ones like location for which you are shown prompt for. And then there are other like signature, or signature, or system. These are usually very restricted permissions. You cannot, not every app can define it. And there are usually signatures involved. Or the app needs to be in system. So usually system apps or custom apps of the OEMs use those kind of permissions. But I was not interested in data collected after defining this permission. I was interested in data collected without defining any permission on Android. So I created an app. I called it Jon Snow app. You know nothing. And this is the Android manifest of that app. So you see that there is no user's permission here. Like it's not using any permission. And that was the whole idea that without using any permission, what all information can I extract? So I'll just show the app right now. So you can see that it's like no permissions requested. It's grayed out. A rare occasion on Android. And when I say, what do you know, it'll give you the basic details like manufacturer, model, supported 32-bit stuff like that. And then I asked it, and hardware details, fingerprints, and stuff like that. And it also shows you whether configurations like ADB is enabled or not. Here, USB mass storage, Wi-Fi is on or not. Airplane mode is on or not. Data roaming, boot count, HTTP proxy. A bunch of system settings, essentially. So it was OK. It was interesting. Some information about my system, which is fine. It also tells you settings, which are very personal to you, like accessibility settings, inversion of colors, or parental controls on your device, whether they're established or not, whether you have touch exploration or not. Most interestingly, it was also able to know all the apps that I'm using. So the names of the apps, banking apps, or any other things. And this bit is the favorite one, because it is also able to gather information, which is kind of not like it doesn't need that kind of information. So information like when is your wake up alarm set up to. So I'll be waking up in six hours. Any app would know that. Or whether I'm listening to a song or not, based on the audio status. Microphone is mute or not. Battery is charging or not. Clipboard, what is the last thing you copied? So if you forward a chat from your loved one to someone else, this app, which has no permission setting on your device, will be able to read that message, or any link that you showed, anything that you copied, basically. And along with that, app widgets, so whatever widgets you installed on your mobile phones other than the apps. So it was able to collect all this information, and honestly, it was just a first goal. So I went to Android Studio and global settings, system settings, and I tried to access everything that Android Studio was letting me access without defining a permission. And this was what I was able to get in the first goal. And why does it matter? So I think this is a kind of broader problem in privacy that we say that these are data points, and these are just system settings, and we need it. But if you put a human behind these data points, you can easily make inferences about someone. So if you have apps you use, there has been research around that, that just on the basis of the apps you use, you can find out the gender of a person, or ethnicity, or age group, or addictions, health problems. If you're using banking apps, they will know which bank your money goes into, lifestyle apps, where do you shop your clothes from, and stuff like that. Because there's an app for everything. So app name kind of indicates your preference or your choice in life. Similarly, device controls, accessibility, health conditions, whether you are a child or not, these can be shown based on whether your parental controls are established or not. Clipboard data, Bluetooth on, right? So they are all these things. And the most importantly is that all the set of information, since it's so much, can be easily used to do device fingerprinting. So there has been talks around apps basically using a thing called advertising ID. So they collect everything from whatever you are performing on the app. They collect that information. They add a unique identifier, which can profile you, which is advertising ID. And it sends it over to advertising server. So that is how they maintain a profile of you, right? And the talks around advertising ID was that users should be able or given the right to remove that link of profiling and the ID used to identify that person. But that link does not hold, like that choice is no more there when your device can be so easily fingerprinted. And for browser fingerprinting, we still have had more discussions. But for Android device fingerprinting, there has been no solution as such for now. Other challenges that I see in existing permission model is permission re-delegation. In Android, since it is the, because of the rich functionality it offers, it allows for IPC, which is inter-processed communication. So it can easily happen that app A is taking location permission, app B is taking gallery permission, and then both of them are talking to each other through custom content your eyes or other ways in which Android allows information to be accessed across apps. And I did a little bit of experiment. I would not go in deep because we have very less minutes here. But what I tried to do was, can I find which app is talking to which app on my Android device? And I was able to do that by looking into the binder calls. So Android allows for IPC through binder. And binder does a lot of logging. So for every process, it keeps process logs, which get erased after some time. And those logs have the information of whether which process was interacted to from this process. So I kind of tried to use that log and make a mapping. So there's a script which you can share for people who are interested. So you can know which apps are talking on your device. But we will not go more in detail here. Let's talk about some other stuff. So what else is problematic? Then there's a thing called common libraries. So you use libraries for crash, dump collection. You use libraries for logging. And those libraries, whenever they are integrated, they have the same kind of access that the app has. So whatever permissions the app has access to, the library also has. And the library is a third-party thing all together. So they can take, again, location from one app. And that library is part of another app, so it can take images from the other app and basically collect and file you. How many minutes left? I'm sorry. Thank you. OK, so that is something which is happening, right? Like library collecting data or apps interacting with each other. And these are active problems which Android is trying to figure out how to solve as a platform. But I think there are broader conceptual concerns as well when it comes to privacy. For example, it's coping of data and granularized controls. Let's take this case. Allow SMS messaging to send and view SMS messages, right? So when you give this SMS read permission, it can basically read any SMS that comes to you. And the thing that I find problematic in this model is that you're kind of giving access to the storage. So when you allow the permission, you basically give the keys to your storage. But you do not know what will end up in your storage, right? Like what kind of SMS is it holding the confidential information? Is there a choice in which we can restrict that no only SMS from now on or the OTP that your app needs, you should only read that? We cannot define that choice, right? So today, when you give the SMS just because an app needs to read an OTP, you basically expose the whole SMS stack. So it can contain any SMS. It can contain any PII. And that is essentially additional information that you are giving off, which you don't need to, essentially. But we don't have a choice to restrict that. Another interesting thing is what happens to my previously collected data if I revoke permission. So the revoke permission flow itself is not very well designed. You can go and say that I don't give this permission anymore. But that revocation, how is it reflected on server side? Have people deleted your data because you do not want them to use it anymore? That flow is again not there happening. And then this is a really interesting thing that talking about data, and it's not related to Android, it's just in privacy in general. Whenever you share information, you do not share just your information, right? So if you're sharing, suppose you're giving access of your gallery, your gallery will not hold just your pictures. You're making a decision for other people in your circle whose pictures are also there in your gallery. And it is interesting. It is obviously complex to solve. But it kind of gives you, if you think about the question of, can you actually control what amount of your personal information goes online? Today, the answer is very difficult. You cannot, in a way, because if you just talk about, say, contacts, for example. So let's say Alice, Bob, and Carol are here in MCS 2022. And they Alice shared the contact to Bob so that they can connect. But later on, Bob happens to have a crowdsourcing app. And that contact got uploaded onto the cloud. The next day, Alice found out that, hey, my contact isn't there, and I do not like it. So she raised a request and said that please take my contact off, or PII off the cloud. And they might entertain that request and take it off. But then the data, which has already left Alice's device, has now reached to Bob. And Bob happened to share it with Carol. And then Carol happens the app, and it again ends up online. So basically, can you control? The answer is no, given the permission or once you have shared, basically it goes out of your reach. So these are the kind of problems that we are seeing in Android. And there are initiatives. There are talks around privacy sandbox in Android, which can potentially help us address it. But there's no significant piece of work which answers the question or provides a solution right now. So these are some of the challenges by platform design. And we have not even touched about the GDPR angle of it. So we have not talked about apps which take permissions. You have given permissions to them. You have trusted them to handle your data with respect. But they end up exposing it, right? So there have been articles. These are all fetched from wired. And they keep on happening every month. There are some article or the other indicating that. This app has leaked information out there. And that kind of shows uttered disrespect or an improper process system or policies around handling user data. So I would just like you to take a minute now and think what info about you is stored and monitored online. Like, can you think about today sitting here, what all information about you would be online? And when I think about it, I basically have no clue. And I would not, and I would not blame you because no one asked you anyway, right? They just uploaded it. The permission models are missed. So you have a lot of information, whether you believe it or not, about you online. And you're being tracked. And the data is being used. So that is all I had to talk about. Thank you so much for attending the talk. And yeah. Aditi, thank you so much. Can we take some questions if we have the time? Awesome. There's two microphones in the middle, folks, for the last time. Let's have some questions. OK, front line, please. Does it work? Yes. All right, so far, these pop-up messages, I've considered them to either be a placebo or one of the ways Google tries to thwart the competition. I'm a bit of a cynic with these pop-up questions. So let's reverse it for a moment. Which of the pop-up questions you think actually work? Can you explain what do you mean by pop-up questions? The pop-up questions for permission, the permission boxes. OK, so you're talking which ones work. Which ones work? So see, the intention of having them in the first place was to provide some sort of controls. What we're talking about is that they are not enough or there's a lot which can be worked upon. So we had things like, for example, initially, in order to access Wi-Fi, anyone could have access to your Wi-Fi. And then there was a study that, just based on the Wi-Fi, someone can interpret the location of the person. So they made that in order to access Wi-Fi, they added the condition that you need to declare location permission. So they are taking steps in that direction. And I do believe that if I'm giving location permission, it kind of gives me a little bit more control around whether my information is going out or not. So I would say that the ones which are there do work in some capacity. But there are still loopholes or things that need to be addressed. Because even if you give the permission, it is the first level of control that works. But once the data is gone out, after that, what happens to our data? There is a lot of scope of data flowing across which you do not control. All right, and this is, again, the cynic in me. How much of this is intentional? So the model that we are working on is advertising models. Oh, I would say that it is intentional in a way that if you're using Google products, the advertising model itself would need, in order to give you the right ads, they need to profile you. But at the same time, they claim that you can remove the advertising idea, or you have the rights to get off the system, not get personalized ads. So the things we are talking about here is how effective are those controls, right? So the choice should be there. The model is, unfortunately, or fortunately, advertising model. So it is intentional, of course. But then do you have a choice to be off-grid? That choice is something that we are discussing here. At first, thank you for your talk, of course. I have two few quick questions. First, about the Sandbox, about the modern Android with the work profiles. Like, there are different apps which are able to Sandbox or use the work profile as a Sandbox. I was wondering about the different provision models. Like, is it as secure as they say? Or is there data being shared between the work profile and the normal, personal profile? So I have not worked a lot with work profiles. They have introduced it recently. But based on whatever I've read in the documentation, they have a base in which you can share information across. But again, you have to be explicit about it. And then they have some sort of permission model around it. I think it's logically a separate space. So they have kind of tried to create the same different users kind of stuff, like you have in Linux. Another layer on top of that, you cannot share resources all together. And when I tried to create an app and work profile, it was actually difficult to have that communication. So I would say that, yeah, it does work. But I've not done a thorough study to say, yeah, it's fully secure in the way they are claiming it to be. And one last question is about the global permission model. Because some phones have also, like you say, like you cannot declare specific permission for the apps, like which apps are installed on your device. But there are global permissions, like allow apps to view other apps installs on the device. If you turn it off, no app will be able to use it. Can you tell me some more about how these, are they vendor-specific? Or are they built in OSPs? Or like, how do they work? The global app permissions? Yeah, I do not know how to do it. I think that's probably not the official term. But there are, in the settings app, they are like setting allow apps to view other apps on your device, or allow apps to know which other apps are installed on the device. That's the thing which doesn't have a app-to-app specific permission, but you can turn it off. Okay, so you're saying that a particular permission is given to all different apps, and then you can select which apps have that permission or not? No, it's more like there's one setting in the privacy app, like turn off, that apps will be able to view apps installs on the device. And when it's off, no app on the device can view which other apps are installed on the device. Oh, okay, so you're talking about, yeah, yeah, yeah. So they added a permission, I think, after Android 10 or Android 11, where you need to define the permission in order to see other apps installed. But this thing worked on the latest model as well. And if the permission, so there is some permission around the extracting the code. So from an app, you can also extract the code of other app. That is how usually app scanning or code scanning tools work on device. So they have added some restrictions around whether you can acquire the code, the binaries of the other app through your app, but the package names or the name of the apps can be attained. And if there was a permission, I think this one worked without permission, but the permission that they've added also normal, so it would not be taking users, you know, user won't be shown the prompt to allow, let an app read other apps. It will just work in background. I'll show it later. Yeah, sure, let's discuss it off after this. Thank you for the very interesting talk. Is there any way you could turn all those permissions off? You showed that even an app which has no permissions at all has a lot of permissions anyway. So could you turn off those permissions? For example, to delete them from an XML file? Because I have no smartphone. And that's of course a good way not to be profiled that way, but it becomes much more difficult time proceeds because everyone expects you to have one. So is there a way to turn profiling off? Currently, no. No, thanks. Thanks for your question, though. Maybe in addition to the question of the previous gentleman, if you use an open source Android distribution instead of the one that comes pre-installed with your phone, would that then solve these problems or at least improve them or does that doesn't even matter? I think it depends on if you wanna play around with Android OS, you can as well create yourself. Like I have known people taking care of the analytics module or how the collection happens and making changes somewhere there and having a custom OS version, like the vanilla one, but blocking certain things and then flashing that on the mobile and using it to be more secure. So I've seen people doing that. If you're using OEMs, I think those are even more bizarre because a lot of OEMs, like OEMs by OEM, I mean Samsung and other device manufacturers, they are coming up with pre-installed apps, right? So a bunch of them, more than what you need or what vanilla Android offers, a lot of them are like just custom apps which actually work or run at the system level itself, seeing everything that you're doing on device. So OEM would be like the least preference, building your own Android OS, which will take a bunch of work, but building that and then customizing it is a good option. If you are interested in that, you can do that. That will definitely help or reduce it in some extent. But again, you have to be conscious of the apps that you're installing, right? So if the app itself is collecting your information, the change that you would be doing on kernel level is restrict them to collect the information. So if you're able to do that in the source code, awesome. If you're not, then you have to be conscious of the apps that you're installing. Right, thank you. Okay, thanks. Hello, thank you for the wonderful talk and this is indeed quite scary to think about. I was wondering, what's your impression of the iOS model in that regard? I, maybe I have missed the part, but personally I've been quite impressed with the occasional granularity of permissions that I have been asked for. Yeah, so I guess iOS, I would say, so there's a catch here, right? Anyway, if you're using Google or Apple, the first thing you're doing as soon as you buy the device is showing your confidence in the company. So they will be taking the data for sure. But now the question comes to whether the data is just with the company or is it going with advertisers or trackers? So in iOS I found that they, I think recently they introduced a feature in their setting, in privacy settings, to stop tracking across all the apps. And that has actually made a lot of other companies who rely on data really angry because they are not able to get the right information into profile and do their work. So they have added that and I actually respect them for doing that. They also have features like, for example, in Instagram, if you're sharing photo, rather than giving access to your whole gallery, they ask you to pick the photo. So those are the kind of controls which can potentially be there in Android as well, but we do not see them in Android much. So my preference would be a little bit towards iOS. Not an official statement though, yeah. I think the approach you're taking with the app that has no permissions and then seeing what it can do is interesting and shocking to see how many data points you can still retrieve. Yeah. This is a bad point, of course, for Android compared to Linux, but on the other hand, if you look at a normal Linux distribution, it tends to run all the apps as the same user with access to all the same data. Now, if you combine the two and take a sandbox on the Linux in which you run each app in its own sandbox, it would be interesting to see how much information your app would still report. You might know you can run APK files on your desktop or on other mobile operating systems that have a sort of emulation layer for running APK files. It would be interesting to see how your app fares in that. So you're saying you're talking, I did not fully understand it, but is your question around application sandboxing and whether that, because Android does it in some ways, I'm trying to understand. So instead of taking Android, take a Linux distribution and a program like Anbox which can run Android applications. Take your application, run it in there and see how much is still revealed. Because if you do that, you have a separate sandbox on Linux for every app, I think. Yes, that is interesting. There are two questions, two things that come to my mind right now here. One is the way, so Android had that as I got and forking off as I got because of memory optimization and it's a smaller chip, they wanna make it work in pockets. It is a thing which will be there and a lot of apps. So they have the optimizations around that. So it's like all the things that I am taking are kind of global common utilities, basically the information that I got from and it's already loaded in as I got and it's forking off as I got. So you already have that permission. So if you are trying to completely sandbox it, it might work but it might not be performant or efficient or might conflict with their initial ideologies of why they chose it to be working. Another thing is in Android, there's a lot of cross-app interaction which is intentional. Like if you're going to WhatsApp, you want to add a contact, you're talking to another app there and that is intentional, that offers rich functionality and convenience to user. So it cannot completely peace and box it still, right? So that is the problem. Okay, thank you. Okay, I'm sorry but we are out of time now so I'm afraid no more questions. Perhaps a DT would hang around afterwards maybe if folks have any others. Thank you once again a DT please. For the last time everyone, let's give a DT a big round of applause. Thank you.