 Hello everyone, I hope you're doing well. In this short video, I'll be talking to you about Android permissions. So those things that you get a little pop-up for that says, hey, this app would like to access your location, click here to allow it, right? Permissions are an important part of the Android model of doing things, as well as the iOS model of doing things. So as a reminder, we talked about this a long time ago before the break. Apps are pretty well protected from each other in the Android operating system, right? So you don't want apps that are kind of reading and writing their each other's data without you, the user, knowing about it. So for example, you don't want Facebook scanning all of your Instagram. Oh, I guess Facebook owns Instagram now, don't they? You don't want Facebook scanning all of your Snapchat snaps, right? And yes, they are still stored on your device, at least for a little while. So you don't want application data kind of reading across applications without your knowledge. And the way that Android handles this is that every application runs in an application sandbox. We'll show an illustration of that just a second to remind you. So you can, as I mentioned before, apps can't read each other's data. And further, if you have a device with multiple users on it, say like an Android tablet, maybe you share it with your significant other or kids or whatever, and you have different users on that tablet, different users can't read the application data from someone else's user account. And this is all part of the Android operating system. You can, as an app developer, allow other apps to read your app's data if you so choose. And that might be useful in some cases. But just a reminder what this looks like. Android, we have the Android runtime here. And every time you start an application, right, and you open Snapchat or Facebook, it gets its own block on here. And this block is a virtual machine, and there's no lateral communication here. Everything goes through the Linux kernel where the permissions are enforced. So we can't talk to one another, we can't override each other's data, and that's a good thing. So the applications are protected from one another. But however, protecting users from malicious apps is a much more difficult problem. So Android and Google do try and do things like scan the uploaded apps to their stores for malware, for viruses, for Trojans, for all that sort of thing, right? So they do do that. It's a huge scale, though. It's hard to do. It's easy to obfuscate malware. They do try and do it, though, and they do catch things this way. But malicious is not just malware known signatures. It's also stealing your information or maybe transmitting data to places where you don't anticipate. And this is by far the most common thing, right? We just had an incident where some researchers discovered that the Zoom application on Mac was calling some Facebook APIs and potentially transmitting data there. So the question is why? Why? Why? But it's much more difficult to discover when apps are transmitting data somewhere where maybe you, the user, wouldn't want them to be. A lot of discoveries of this sort of behavior are by accident, or it's from security researchers who are really looking closely. It's not something you can do at scale, though, unfortunately. But the biggest hole in user privacy and security are the users themselves. Users are more than happy to trade their privacy for functionality, right? So one of my favorite cases is Candy Crush. You install Candy Crush and it says Candy Crush would like to access your contacts. Well, Candy Crush does not need access to your contacts in order to function. It wants them to help sell ads and add revenue and contribute to their ad network, right? So they don't need it. But it's not just your, you know, as you choose to sacrifice your privacy. It's not just yours that's getting compromised, potentially other people's, right? So LinkedIn is infamous for this. I don't know if you're on LinkedIn, but when I go on to LinkedIn, it will tell you something like, your contact Joe Schmo is now on LinkedIn. Would you like to connect with him? Well, maybe. But I never once gave LinkedIn permission access, or permission to access my contacts. And I never uploaded my contact data. So what happened? Well, Joe Schmo installed LinkedIn on his phone. And he gave on his phone LinkedIn permission to access his contacts, which happened to include me, right? So he has in a way compromised my privacy without me having to say anything. All right. And why did he do that? I don't know. But users in general are willing to trade privacy for functionality. So how does Android try and protect users from malicious apps? Well, they try and put the decision of what is malicious or not, or potentially malicious or not in the hands of the user. So by default, Android will block your app from accessing sensitive things like the camera, the microphone, the GPS, private things. The user Android requires that the app request permission from the user to access such resources, and the user can revoke or disable and uninstall the app at any time, right? Can revoke those permissions. This wasn't always the case way back in the old days of Android 511, which is, I want to say, early 2015. You had a model where when you installed an app, it requested all the permissions it would ever need, and you just accepted it. And when you accepted it, it was a blanket statement and it was done. So for the rest of the time this app was installed, it had access to all these things, right? And if you denied it, if you did not accept, you simply could not install the app and you couldn't use it, right? So it was kind of one and done. Said it and forget it. The biggest, I would say, what do I want to say here? The biggest culprit, the biggest criminal in this space is Facebook, right? The old Facebook app, whenever you install it, it needs access to all these things. Well, it doesn't need access to all these things. It wants access to all these things in order to harvest your data. But again, this was one and done. Accept it. It's installed and now, from now until forever, it can access all this stuff. Device ID and call information, right? SMS, it's reading your text messages. And think about this. This is 2015. It's the height of Facebook, arguably the height of Facebook. Grandma just wants to install this on her smart phone so she can look at cute pictures of her grandkids. Does she understand this stuff? No, of course she doesn't. She doesn't understand what she's giving up. Android's new permission model is Android makes you ask all the time, right? So for everything you need access to, if you need access to contacts, you need to ask. If you need access to location, you need to ask again. If you need access to microphone, you ask a third time, right? So every permission was separated and the user had to explicitly grant permission for each separate request. And there was also a facility to provide more detailed information. There's no such example here. But an app developer can provide more information about what you need access to the contacts for. They also introduced another mechanism where a user can revoke a permission at any time after the app has been installed. So if you go into your Android phone or your emulator and you click on settings and then you go to apps, you can get to a screen called app permissions here. And here's the permissions that the camera app requires. It needs access to the camera, of course. Take pictures, microphone if you want to record audio with your video. Storage to write and save the files to that it records. And location. Usually by default, your images that you take are tagged with their geographic location at which they were taken. Maybe you don't like that, but you want to use all this other stuff. So you turn off the location permission. That sort of ensures that it cannot possibly get your location data. You can also look to see in Android which apps have access to the camera itself, right? So Dropbox, the camera, Google Play, but these other things do not, okay? So it's a slightly different permission model. And now we also have in Android three protection levels. The first level is what we call normal. You can grant these at install time where you get kind of a picture that looks like this. Install time permissions. And these are things that are very little risk to the user privacy. So like access to the internet. Most apps need to talk to the internet. We'll just say, you know, tell the user we need to do that when they install and be done with it. But for more dangerous things, which Android calls these dangerous protections or dangerous permissions, you need to ask the user at runtime while they are using your app, can I access this thing? And these things access your private information. So there's a third protection level called signature. We won't get into that, but it's for companies like Alphabet or Google where they've got whole families of apps and they want to be able to share data between one another. So examples of normal permissions, accessing the internet, talking over Bluetooth, near field communication, fingerprint reader, which is kind of interesting to me. Dangerous permissions, getting your contacts, accessing the microphone to listen to you, getting your location. So your location is dangerous private information and, of course, reading your text messages. So this new permission model has some important implications for you, the app developer. The first thing to keep in mind is that users can grant and revoke permission at any time. So if you're writing an app that needs to access a person's location, you can ask for it and they can grant it. You can start recording their location information. Maybe you're walking down a trail trying to catch Pokemon. The user switches out of the app for a second, revokes the permission in the settings and comes back. What's going to happen? Is your app going to crash? Maybe. I don't know. You must always check to see if the user has granted the permissions you need before running the related code. If you don't, if you don't have permission to get something that you need access to, like location, your app will crash. It will throw a security exception and it will just explode. If there will be no fuzzy warning signs, it will just die. It will throw an exception. So that said, when users do not grant your app the permission it needs, your app should degrade gracefully. Don't just crash. Check for the permission. If the permission isn't there, ask for it. But if the user keeps denying it, then display a warning message. Show a slightly different version of your layout that says, I can't do my cool app tricks because I don't have location permission. You need to go give me that. Don't crash is the bottom line. But things general strategies to do. Try and keep these in mind. First of all, what permissions do you really need? You probably need to talk on the internet. But if you don't need permission to do something, don't ask for it. The more permissions you ask, the less likely a user will grant them all. Be transparent about why you need permission. You can explain when you pop up a little dialogue that asks for permission. You can explain why you are asking for it. Be transparent. Users appreciate that. You also need to keep in mind that some third-party libraries you may import in your build.gradle file and then make use of, they may need permission too. Like maybe they need to transmit over the internet or they need access to your camera. If your third-party library needs permission to access something, you have to ask for it and you have to grant it in your activity. Otherwise it will probably blow up. All right. So these are some of the implications of this permission model. In the lab we'll see an example of an app that just records where the user's current location is, kind of saves that day of the internet and displays it in a list. Part of that will involve first requesting permission from the user to get the location. And then once you get that permission, then you can actually start reading the location data. So we'll talk about that in a future video and in your lab.