 I'm just starting. My name is Chirayu Desai, and I am the lead engineer at the Calix Institute working on Calix OS. Calix OS is an Android-based operating system. It is a completely free and open source software project. The Calix Institute is a US-based nonprofit and funds development of Calix OS. We focus on making a version of Android that is private and secure while also keeping usability in mind. We try to make choices that respect your privacy and but also allow you to use all of the apps that you are used to without having to make compromises. It is available for Google Pixels and the Xiaomi Mi A2, which was an Android one device. We pick these devices because they support something which is known as bootloader re-locking, where you get the device, you unlock the bootloader to install our custom operating system into it, and then you are able to lock the bootloader once again with our operating system installed to make sure that any system modifications cannot be done without your knowledge. This feature is called verified boot and it ensures that what's running on the device matches exactly what we intended the operating system to be. This is supported on a handful of devices with a custom operating system. It is used by the default operating systems on on devices and we rely on it to keep the default Android security model intact, where the code which is running as a privileged system is limited and controlled by a single entity. Moving on to some features of KaliXOS, one of the things we include is MicroG, which is an open source implementation of the Google Play services, which you might be familiar with. Google Play services is this app that Google has built, which is now on almost all Android devices. It is a proprietary application and we cannot ship it. We prefer to ship open source code as much as we can. And it is a big application, implementing all sorts of things, doing lots of data collection. Studies have shown how much data an Android device sends to Google servers. A lot of that happens through Google Play services. However, as an app developer, you might be using APIs which are provided by Google Play services, such as Firebase, Maps, Google login, and without Play services, those APIs won't exist and the application simply wouldn't work. There's where MicroG comes in. It is a completely open source implementation of Google's APIs. And we include it with our operating system. However, we do it in a unique way, where as you are seeing on your screen, you are presented with an option to keep MicroG enabled or disable it when you're first setting up the device. You may not want to use apps that rely on Google services or perhaps you don't want to send any data to Google servers at all, in which case you can choose to keep MicroG disabled and it will just be, as if it's not present on your device. And this is still beneficial. We'll go into details about it later. If you do enable it, then you'll see a screen which shows the MicroG settings and it sort of also shows some of the APIs that it implements. One of the main reasons to keep MicroG enabled is for push notifications from apps which use Google Cloud Messaging or Firebase Cloud Messaging. MicroG implements these APIs. So as an app developer, you do not have to do anything. On a stock Google device, the same application will just use the play services code to fetch notifications. And then if the same application is running on KaliXOS with MicroG installed, it will be using the open source MicroG code to fetch notifications. In both cases, they come from the server and there are no other changes required. It just works. That's the best part. Some more things that MicroG implements are things such as Maps APIs, which is what you would use to show a map in your application. This is implemented using Mapbox. Additionally, it implements a plugin-based network location provider system. If you're familiar with location on Android or just any device in general, we have GPS or GNSS, which uses satellites to pinpoint, to track down, to pinpoint the location of your device. However, the initial fix can take time. There are methods to assess the initial fix and one of those is using these network location providers. We have providers such as Mozilla's backend and then there are additional providers available which they use Apple's Wi-Fi location database or there are databases available which contain local cell tower information. The point here is that you try and use something such as Wi-Fi or cell towers to get a rough approximation of the area you are in and then GPS, and by the time the GPS logs, you get a accurate location and this makes the initial location check really quick and this is what you would get on stock. Google implements all of these. You may have seen toggle for Wi-Fi scanning and Bluetooth scanning. These are also part of Google Play Services. However, here, Micro-G implements this for us and it does it in a completely open source and modular manner. Then one of the best things about Micro-G is that it implements APIs which apps need to work. However, it only provides stub implementations for APIs which are usually not desired in a privacy respecting open source project such as analytics. It provides analytics APIs so that applications can work. However, the APIs are stubbed which means they simply return true or return zero or return an empty string. This makes the apps work. However, it still avoids analytics collection which is a big win for a privacy respecting operating system. So we talked about the choice to enable or disable Micro-G on the first setup on the first boot earlier. This lists out the options. Going through, there are three options. The first is simply you disable Micro-G. However, I said that this is still beneficial where because you are able to disable Google Play Services on stock, some apps are still able to handle this well. What this means is even when Micro-G is disabled just because it is present on the system even if disabled applications such as Google Camera and YouTube, they work. They see that there is a Google Play Services or Micro-G package, shares the same package name. They see that it is present on the system. They are fine even if it's disabled, they will just work. So that is a big advantage of always including Micro-G by default and then providing a choice to disable or enable it based on what you want. The second choice is what is the default? What would happen if you just pressed next without changing anything? Which is where Micro-G is enabled by default and so are things like push notifications and device registration. What this means is we include a few applications with the OS. One of those is signal and what this signal uses Firebase Cloud Messaging for the notifications. And what this means is that by default, if you just go through the setup without changing any options and you open up signal, it is able to register with Google to receive notifications, just find a notifications work. This is the default. There is a third option that some people prefer to use which is they want to log into a Google account to use with Google apps. You are able to do this with Micro-G as well. Any Google app or any other app that requests a Google login is able to request a login in the same manner. And when you log in, a Google account gets added to the device. This is beneficial for some people who are using apps which has maybe they're using Google Drive to access a bit of data. Maybe they're using Google Slides, Google Docs. Not all apps work, but a good chunk does. And I believe that is a good compromise between privacy and just being able to use a custom OS and not having to use proprietary code. You have to give up on some applications but we try our best to make sure as many work as possible. And there's a feature that we have added last year after a lot of UX iteration is the integration of signal and WhatsApp calls in the default dialer. The dialer is the full application on the device. It's what shows up if you tap the phone icon. You can see two screens here. One is the call history screen which is showing a dialog box. That is the option. Whenever you try to make a call, you are given an option to choose between signal, WhatsApp, or just your mobile SIM provider. This, in a way, is similar to the dual SIM dialog box that you get on devices where you have two SIMs, where you are given a choice to choose between two SIMs, except here you are given a choice to choose a different app entirely. Additionally, if you choose your SIM card, Airtel in this case, you are shown a yellow warning in the in-call screen which says that the location and the audio of the call are not private. What this means is we are just trying to say that normal phone calls are not secure and we want to make the user aware of those with a subtle warning which just appears on the screen. It's there for you to see it, but it does not get in any way of making the call. You can just call like usual. Some more details on this integration. We went through a lot of calls we went through a lot of iteration to figure out the best way to integrate this. As I mentioned before, signal is something we integrate with the operator. We include with the operating system. It is a good end-to-end encrypted messaging solution which works quite well and it works well for calls as well. And so that is shown as an option by default. If the signal app, somehow you choose to not to install the signal app on your device, you still get an option to install signal. If signal is installed, the way this works is whenever you dial a number by either by manually typing it in, selecting a contact or just trying to make a call again based on your call history. The code, the underlying code will try to see which contact the number belongs to and then try to see if there is an associated signal entry for that contact. If there is and for that contact and for that specific number. If there is, we are able to use signals APIs to make a call. This is similar to, you must have seen that the contacts app on your device when you have a contact and they are present on signal or WhatsApp or sometimes some other apps as well. You get the signal call and message options right there in the contacts app. This uses the same APIs, but there's a lookup when making the call and directly calls signal right away instead of making a telephonic call. This is something we try to do across our operating system. We try to reuse existing code that is already exist and is we try to repurpose existing code. In this case, you already had contacts entries for signal. So we just repurpose that into making signal calls directly. And what this means is that we are not trying to reinvent the wheel and applications themselves don't need any changes. It just works. The other option that you saw was WhatsApp and with WhatsApp, there is a compromise to be made here. We all know WhatsApp is owned by Facebook and we know that while it is end to end encrypted, Facebook is still able to collect some metadata about your usage of WhatsApp. However, the end to end encrypted nature is still better than a regular phone call and it is a case of whether you are okay with Facebook having some metadata of your call or are you okay with your operator having metadata as well as being able to listen into your calls if they so choose given that they are not encrypted. So what we have done with WhatsApp is that the WhatsApp option is not shown by default. However, if you do have the WhatsApp app installed, we will show the option and we will try to do the same contact matching that we do for signal. The idea here is that if you're using WhatsApp, if you choose to use WhatsApp, you might be fine with making calls through that, even they work quite well. And so we will provide you the option. If you are not using WhatsApp already, we do not want you to push you towards the proprietary sort of product. So we simply won't show the option. This took a lot of back and forth with the design team, with the technical team, figuring out the best way to implement this and figuring out what's the best way to show this to the user to make it as frictionless as possible. There's another topic which is the default servers used by the device. For DNS, by default it will use whatever your ISP has configured or whatever you have configured on your router. However, you are able to, if those are not working or if those are not configured properly, the device will fall back to Cloudflare DNS. You're also able to directly pick Cloudflare DNS as a DNS over DNS or private DNS option, which will route all DNS queries securely to Cloudflare. There are some other servers that any Android device connects to by default, such as servers for network time protocol, which is used to synchronize the time. There is a connectivity check server, which is used to see if the internet connection has a connectivity. What this means is you may have sometimes seen a small cross next to the Wi-Fi icon. That happens when the connectivity check fails. Like maybe your internet went down, but your Wi-Fi is up. And so it tries to ping a server. If it is not able to access the server, it will try again and then it will declare that there is no connectivity. And so the device can then fall back to mobile data for communication. There is also another captive portal check, where a captive portal is simply a Wi-Fi network with a login screen. These are detected using a captive portal address. We keep these last two to Google servers by default currently. And the rationale is that these are simply requests to Google servers. They're not collecting and sending any extra data from your device. And all Android devices, or like most Android devices are doing it, all of the pixels running Google stock software would be using the same servers. What this means is that when your device is running the stock OS and that brings Google servers and when your device is running Kaliq OS that brings Google servers, there is no difference. They get the same data, which is just a user agent, which is also hard coded and an IP address. And they do not get any additional data. So they are not able to tell if you're running a different OS. And if there is somebody monitoring all your traffic, they are not able to tell that you're running a different OS. It just looks the same. Google servers are also reliable and they have a good track record with protecting the data that they collect. So we feel that this is an acceptable compromise. However, some users still don't want to do this and they want to use a different server. So in the future, we will be looking to provide options. Finally, I would like to talk about some of the firewall features that are included with the operating system. As we speak, as you are seeing this, the April update would have is already, has already been released and that contains our new firewall app, which is called Datura. It relies on some operating system code to block Wi-Fi for apps or block mobile data access for apps or even prevent an app from using a VPN. In case you choose to do that, that is all toggle-label. Additionally, you can also completely isolate an app from the internet. In case you want to use the app completely offline. For the app, in a way, this is similar if the device is in airplane mode. There really is no network and apps should already be built to handle this. So this is seamless because it is then at a network level rather than at a network level, which means it is transparent for the app. In the future, we are also planning to add options to block trackers or ads, similarly at a network level, because network level blocking is very common. You see it in browsers. You see it where DNS servers, whether they are local DNS servers or there's something like a piehole or whether it is some remote DNS server. My point is that the lists are common and this is a common method, which makes it quite reliable as opposed to something entirely new for Android. One of the features that we added recently was a global clear text toggle. But this is that it's off by default, but if you turn it on, it will prevent all clear text traffic from the device. And when I say all traffic, I mean all traffic. Even the system cannot send a single HTTP request out. It has to be HTTPS or rather I should say it has to be TLS as that is what the code checks again. Some of you might be familiar with this. There is a network security config in Android where you're able to say if you want to use clear text network traffic with your app. This uses the same underlying implementation, but instead of that being only per app, we have extended it to be global. And we ran into some interesting problems with this because even DNS is clear text by default. The plain DNS that we use on port 53 that is not TLS. And fine, you might say, okay, just switch over to DNS over TLS that is already supported on Android. Well, yes, but DNS over TLS also needs to do one initial lookup to resolve the server. And that was fun to figure out. We ended up just allowing that only that initial lookup and not allowing any only from only DNS traffic from that for that initial lookup and then to the DNS server and then simply removing that exception once private DNS is established. TLS only also means that VPN apps may or may not work. However, we have a per app toggle implemented for this, which means you are able to, you are able to remove this restriction from just your VPN app to have it work. Thank you for listening to the talk. With KXOS, we are trying to build something that respects your privacy, keeps the security model intact. And we include a good collection of open source software open source apps that we feel are essential. The idea is that you should be able to take a KXOS phone go anywhere in the world and still be able to get on the internet even when some regimes are blocking internet access, whether this be through Tor browser, whether this be through a KX VPN, which is our free VPN service. The app is included with the OS. It is completely free. There are no accounts. There is no data collection. It just works. So that is the idea and we are just trying to build more features to help with this. Thank you. Thanks, Chirayu. So we can take questions now. If people have questions on Zoom, you can post them in the Q&A tab. Those who are on YouTube, you can post your questions in the comment section. So Chirayu, I had one question. What is the adoption currently for KX and also how do you go about actually telling people that something like this exists? So one interesting thing is, we currently do not have a solid number of users because we were not collecting any metrics at all. I am giving a talk tomorrow about how we are going to be collecting some metrics in a privacy-preserving manner. But apart from that, adoption is done through some usual channels of people familiar with installing custom operating systems on their device. And then even for those who are not so familiar with the whole process, we have a program which you can download and it will just do all these steps for you. Got it. And if there are people who want to contribute to the efforts, are there links or how do contributors join in? Yeah, so there is, I put a link to the website in the Zoom chat, it's calixos.org. We have metrics IRC telegram channels and the operating system is completely open source. So and all development is done in the public as well. We mainly use the cloud issues to track features and bugs. So that can be a good place to start just report an issue if you know of something or maybe you want us to look at something or if you want to work on something, see if there's something in the issues that interest you. And is there a pattern you have seen among contributors like are there people from specific geographies who contribute, who have been contributing to this project? So one of the things is that since we built the entire OS, it is a quite resource intensive. You have to download like a hundred gigabytes of source code, you need even more space on your development machine. So that best limit contributions to the OS as a whole. But there are some independent applications that we have received contributions to and we always say that contributions to documentations are also contribution documentation is also welcome because that's not something we are really, we could be better at. Okay, yeah, I think that's a general challenge for open source development projects and it's something for us also to look into how we can address it. I had one last question, I'm just trying to recall what that was. Let's see if there are any questions meanwhile and if I can recall my question. Right, so I know in your abstract, you mentioned that on the one hand, you're trying to create a privacy preserving OS which gives you more control and on the other hand, there are implications and you have covered this in your talk but if you could kind of just recap one or two critical points once again, sort of drive home the point to the audience. Yeah, so I think one of the things that people may have heard of is routing your device where you are able to change anything in the operating system as you wish. Now this may seem nice, like you have the freedom to do whatever you want but on the other hand, this is not good for security because if you are able to do anything, a malicious app is just one step away from also being able to do the same thing. So this is where some people are used to tinkering with their devices, routing to install things but we are trying to, we don't officially allow or support that but what we're trying to instead do is, we try to ask people that what are you using root for? One of the most common answers was for backing up applications. So we built this open source backup application for Android called Seed Vault and that is included with the OS and that will back up your apps, call logs, text messages, contacts, everything. And the other thing that people use root for is network traffic blocking firewall things. So that is also something we built into the OS. So what we're trying to do is just provide the same functionality but in a more secure and private manner. There is a question on YouTube which is what do you think about the future of custom ROM? This is asked by Abhishek Zala. Okay. So in one way it may seem like there's less and for some people there's less and less reasons to use a custom ROM these days like why bother just use what you get with your phone but on the other hand, awareness about the privacy implications are increasing day by day and if you just look at what's being collected on your stock device and the fact that you can't really do much about it without changing the OS means that there is still a good balance to be had after installing the custom ROM. Got it. Let's see if Abhishek has a follow up question and if there are any more questions we still have about five minutes so if there are any questions. Chirail how did you get involved in this project? And I think that kind of also leads me to ask this question that somebody had asked her saying that how do you get people to kind of take up privacy engineering and I'm like it's not a discipline yet so it might be useful to hear from you. Yeah, so that is a really good question. I started off doing Android development while I was still in school just trying to. I had a phone and the company wouldn't update it so I tried to look into how could I update it and that's how I got into the Android side of things. But then one day I was introduced to the executive director and founder of the Killing Institute, Nicholas Merrill. And he wanted to talk about Android phones and we just ended up chatting and I really liked his goals. And so I started off just doing what I knew just doing normal Android development but as I continued it has been around four years from that day. So as I continued working on this ended up understanding more and more about privacy by attending conferences like these and just talking to other people working in the same space and also other colleagues at our nonprofit. I started off as just an Android developer but I ended up learning a lot about privacy just doing my normal Android development things but pausing to think about privacy while you're doing anything. Got it, I think that's a fairly useful answer. I have a couple more questions that are sort of unrelated to your talk and hopefully if there are any questions while I'm asking questions, we'll take them up. So you are aware that Haskell did conduct a research on the state of privacy and technology and one of our findings has been that or at least the data shows that with respect to mobile apps, we really are kind of we have leaky buckets and it's not a very good situation at all. I know you're not an app engineer yourself but is there a comment you have about the ecosystem in general and also how do you distinguish your work from that of app developers and is there like a piece of advice that you would like to give at this point in time? Yeah, so while I'm not a day to day app developer I still end up working on apps as part of the project. I think one of the things that is in a lot of the times is maybe the app itself is not doing so much of the collecting but it is some third party SDK that they have pulled in and so this is something we're very careful about while developing the operating system. We really look at what source code we are playing from there. If you are going to include some third party project we try and think a little bit before rather than just adding a dependency and shipping it. We try to understand the implications and if there is an attitude about that if app developers started looking at the SDKs they're integrating and asking why is this doing so much collection that might lead to a change because they are the ones in control of the integration after all. Got it. There is a follow up question from Abhishek Zalla and I've posted it here in the comments he asks or Abhishek asks do you think Google is killing custom ROMs by bringing new safety net restrictions? So what this refers to is safety net is this thing that Google has to ensure that your device is safe and the most common use of this is banking applications where they will check if the device is safe and refuse to run like they can say that your device is rooted you can't use the bank app and so this is something Google implements in play services but it's not available on our operating system but I feel like I don't think Google has some malicious like killing custom ROM thought in their mind while they're implementing it. I think they are genuinely doing it for security reasons because in some cases it is valuable in other cases like you have gaming apps check this, check if the device is secure and that feels a bit overkill in some cases it is genuinely useful and I hope we can work with Google towards the solution. Yeah, I think this is a good point and also something to also for us to think about in terms of how to take things forward in a more constructive fashion because there's obviously a sentiment that big tech is evil but at the same time you have to engage with the so-called evil if you have to make systemic changes. All right, so I think we're almost, we're at 245 and I shouldn't do injustice to Sandeep whose talk is next. So having said that, Cherie, thank you so much. I'm really glad that after two and a half years of first meeting in Andhrava in the pre-COVID days and talking about killings, this has materialized and I think that should be inspiration to people who are participating that, you know just like Cherie, you have an opportunity to speak, you just have to reach out to us or actually don't even reach out to us, just check hasgleek.com and make a submission. Having said that Cherie has a talk tomorrow and you already pointed out that he's going to refer to the work that they're doing in terms of how they collect data and how they do analytics and I think that will be interesting because tomorrow we're trying to look at how do you do privacy from a consumer's point of view. The other thing that is also taking place tomorrow is the Birds of Feather session where we're looking at building apps and mobile apps and how do practitioners actually think about security and privacy or if they don't think about privacy and security, what is the ecosystem that we really need to build going forward? And Cherie also sort of dropped a hint to banking apps and someone is here, so someone talk also tomorrow on what really, what is really wrong with net banking but I won't give away too much. We'll move straight into Sandeep's talk from here, Cherie, thanks a lot for joining in.