WEBVTT 00:00.000 --> 00:07.000 Hi, can everyone hear me? 00:07.000 --> 00:08.000 Yes? 00:08.000 --> 00:09.000 Right. 00:09.000 --> 00:15.000 Some here to present networking sandbox for Android. 00:15.000 --> 00:19.000 Android is a pity lockdown, opening system, 00:19.000 --> 00:22.000 it's pretty restrictive for applications, 00:22.000 --> 00:25.000 especially applications that are installing your phone. 00:25.000 --> 00:29.000 But it's especially suspiciously lags on networking sandbox. 00:29.000 --> 00:34.000 And I'll discuss how to build one. 00:34.000 --> 00:38.000 My name is Murtazza, and I worked on ASP at 116, 00:38.000 --> 00:41.000 which is Amazon Research for five years. 00:41.000 --> 00:47.000 And then I moved to AWS, worked on this with databases. 00:47.000 --> 00:50.000 The boy was born to me in my wife, 00:50.000 --> 00:55.000 and that meant one year of my life, went by. 00:55.000 --> 00:58.000 Then I worked on this project, networking sandbox, 00:58.000 --> 01:03.000 and on it, I've been working on for five years. 01:03.000 --> 01:06.000 Pro bono, our app is free and open source. 01:06.000 --> 01:10.000 Then I was again a dad to twins and passed one year of my life 01:10.000 --> 01:13.000 as being just a blur. 01:13.000 --> 01:15.000 So to give an introduction about Android, 01:15.000 --> 01:17.000 there's an application sandbox, 01:17.000 --> 01:21.000 and then Android is a mere amalgamation of the Linux kernel 01:21.000 --> 01:27.000 plus the HAL subsystem, which is a very weird way of doing drivers in user space. 01:27.000 --> 01:30.000 And a BSD Lipsy layer. 01:30.000 --> 01:33.000 And for networking later things, 01:33.000 --> 01:35.000 the init process starts, 01:35.000 --> 01:37.000 NetD and DNS proxyD. 01:37.000 --> 01:41.000 So NetDman is responsible for handling all the administrative data tasks. 01:41.000 --> 01:45.000 Any task that you might do on Linux using capnet admin privileges. 01:45.000 --> 01:49.000 And DNS proxyD must basically establish all the forwards connections 01:49.000 --> 01:51.000 to upstream. 01:51.000 --> 01:55.000 And there's finally a turn device with which you can control 01:55.000 --> 01:58.000 all the traffic that's going out of Android. 01:58.000 --> 02:00.000 Some of it, not all of it. 02:00.000 --> 02:03.000 So application sandbox is a bit like a pyramid. 02:03.000 --> 02:06.000 At the top, there's a sitcom BPA filter. 02:06.000 --> 02:09.000 Every Android process, folks itself from Zygote. 02:09.000 --> 02:12.000 Zygote is the parent process for all Android apps. 02:12.000 --> 02:16.000 And the Zygote process contains the entire Android runtime. 02:16.000 --> 02:19.000 And all associated Android related fonts, for example, 02:19.000 --> 02:22.000 resources like fonts and Android classes. 02:22.000 --> 02:24.000 The SDK complete SDK. 02:24.000 --> 02:27.000 So Zygote itself, before it approaches, 02:27.000 --> 02:31.000 it applies a sitcom filters, which restricts something like 20, 30 02:31.000 --> 02:35.000 system calls that appears to be used on Android 02:35.000 --> 02:37.000 to compromise the kernel. 02:37.000 --> 02:40.000 Then there's a middle-value layer, which is the permissions layer 02:40.000 --> 02:41.000 that you see on Android. 02:41.000 --> 02:44.000 Every time you try to access camera, you try to access the location. 02:44.000 --> 02:45.000 There's a function pop. 02:45.000 --> 02:47.000 That's implemented by the middle-value where the Android framework. 02:47.000 --> 02:52.000 Then there's the back, which is the typical 02:52.000 --> 02:55.000 unique access control. 02:55.000 --> 02:59.000 On Android, every app that's installed gets its own user ID. 02:59.000 --> 03:01.000 So every app is its own user. 03:01.000 --> 03:05.000 And then the user ID is used to apply decision access control. 03:05.000 --> 03:08.000 The root user Android is fairly useless because everything is 03:08.000 --> 03:09.000 split up in capabilities. 03:09.000 --> 03:12.000 And when in its starts, the various demons, 03:12.000 --> 03:15.000 like OLD, NETD, Debugity, it gives it only 03:15.000 --> 03:17.000 specific abilities that it needs. 03:17.000 --> 03:19.000 Not no root access. 03:19.000 --> 03:23.000 And finally, the last layer is the Maclayer, which is 03:23.000 --> 03:24.000 written by SE Linux. 03:24.000 --> 03:28.000 This was contributed by Samsung around the time of Android 5, 03:28.000 --> 03:32.000 which is 2014, 2015. 03:32.000 --> 03:35.000 So you see comments like this in Android, 03:35.000 --> 03:36.000 so it's very common. 03:36.000 --> 03:38.000 So you would wonder why certain things, 03:38.000 --> 03:40.000 and so you're using Lipsy if you're writing 03:40.000 --> 03:44.000 Java app, Java, the VM uses Lipsy underneath. 03:44.000 --> 03:47.000 And you would wonder why things don't work like they work on other 03:47.000 --> 03:48.000 Linux distributions. 03:48.000 --> 03:50.000 And you'll end up seeing comments like this, 03:50.000 --> 03:52.000 that there's a free BSB system, 03:52.000 --> 03:56.000 maybe as a system here differently from Linux. 03:56.000 --> 03:59.000 Like I said, every app that sends out a DNS request, 03:59.000 --> 04:01.000 sends it to DNS proxyD, which sends it upstream. 04:01.000 --> 04:03.000 So DNS proxyD is like a sub-resolve, 04:03.000 --> 04:06.000 a caching stop is all or also caches request. 04:06.000 --> 04:07.000 That's a problem. 04:07.000 --> 04:10.000 But because it's placed on the free BSB implementation, 04:10.000 --> 04:13.000 we can bust the caches by setting the details to zero. 04:13.000 --> 04:16.000 This obviously would not work for DNS sec queries. 04:17.000 --> 04:19.000 The VPN is controlled. 04:19.000 --> 04:21.000 Again, a VPN app, if it has permissions, 04:21.000 --> 04:24.000 it can talk to net demand and then set up rules. 04:24.000 --> 04:27.000 And the routing tables and the IP rules, 04:27.000 --> 04:28.000 as appropriate. 04:28.000 --> 04:31.000 For instance, a VPN app can say that all applications 04:31.000 --> 04:34.000 that are installed on the phone must be routed through the 04:34.000 --> 04:35.000 Transdivis. 04:35.000 --> 04:36.000 The applications don't get a saying, 04:36.000 --> 04:37.000 it's taken out opt-out. 04:37.000 --> 04:39.000 The VPN app controls which applications 04:39.000 --> 04:42.000 go through the Transdivis and which don't. 04:42.000 --> 04:44.000 And every application is subject to something called 04:44.000 --> 04:45.000 a Spanoid Networking. 04:45.000 --> 04:47.000 This is very peculiar to Android. 04:47.000 --> 04:50.000 The system calls basically a system calls 04:50.000 --> 04:54.000 to create sockets or disallowed when an application 04:54.000 --> 04:59.000 doesn't have permission and the scope internet. 04:59.000 --> 05:01.000 So this is Daniel McKay. 05:01.000 --> 05:03.000 He says that a VPN, 05:03.000 --> 05:06.000 the Tandivis is actually a perfect way of providing 05:06.000 --> 05:13.000 a firewall functionality on graph in OS and other Android. 05:13.000 --> 05:15.000 So this is what it looks like. 05:15.000 --> 05:17.000 Any app that's trying to connect to the internet 05:17.000 --> 05:20.000 would now get its packets sent to the Tandivis. 05:20.000 --> 05:25.000 The VPN app is the only app that can read. 05:25.000 --> 05:27.000 The only app that can read from the Tandivis. 05:27.000 --> 05:29.000 So every read is a single packet read. 05:29.000 --> 05:30.000 Every write is a single packet right. 05:30.000 --> 05:32.000 It's a special file. 05:32.000 --> 05:35.000 And these packets are sent to device and 05:35.000 --> 05:36.000 extracts. 05:36.000 --> 05:38.000 You have an S like something Google built for its cloud 05:38.000 --> 05:39.000 compute. 05:39.000 --> 05:42.000 And it completely implements the entire kernel 05:42.000 --> 05:45.000 system called surface in user space. 05:45.000 --> 05:47.000 As part of implementing that, 05:47.000 --> 05:50.000 it also implements the entire networking 05:50.000 --> 05:51.000 subsystem in user space. 05:51.000 --> 05:53.000 It's written in go the app. 05:53.000 --> 05:54.000 It's a network engine. 05:54.000 --> 05:55.000 It's written in go. 05:55.000 --> 05:58.000 So it simply bring over the pieces of the TCP IP layer 05:58.000 --> 06:01.000 that's running in the user space from device 06:01.000 --> 06:02.000 over and right in Android. 06:02.000 --> 06:06.000 It works fine to my surprise. 06:06.000 --> 06:08.000 And from device and next stack, 06:08.000 --> 06:10.000 the packets, the individual packets that 06:10.000 --> 06:12.000 there are reading from the Tandivis, 06:12.000 --> 06:13.000 are converted back again into 06:13.000 --> 06:15.000 sockets and sent out to mobile or Wi-Fi networks. 06:15.000 --> 06:17.000 This is also being 06:17.000 --> 06:18.000 peculiar to Android via both networks and 06:18.000 --> 06:19.000 back here at the same time. 06:19.000 --> 06:22.000 For example, Wi-Fi might be only IPv4. 06:22.000 --> 06:25.000 A mobile network might be IPv4 plus IPv6. 06:25.000 --> 06:27.000 So if an application signed quite IPv6, 06:27.000 --> 06:30.000 you would have to read it to mobile phone network 06:30.000 --> 06:32.000 and because Wi-Fi wouldn't work. 06:32.000 --> 06:35.000 So the loop back there is if a VPN app wants to 06:35.000 --> 06:38.000 firewall itself, it can write its own 06:38.000 --> 06:41.000 packet so it identifies which will get sent back to it 06:41.000 --> 06:43.000 and then the firewall decisions can be taken. 06:43.000 --> 06:45.000 This is slightly complicated, but I've been 06:45.000 --> 06:47.000 implemented. 06:47.000 --> 06:50.000 And another thing we do specifically is send fake DNS 06:50.000 --> 06:52.000 responses. 06:52.000 --> 06:54.000 We send fake DNS responses to 06:54.000 --> 06:57.000 trick apps into thinking that these are IP that 06:57.000 --> 06:58.000 they need to connect to. 06:58.000 --> 07:00.000 And when they actually try to connect to that IP, 07:00.000 --> 07:03.000 we're going to figure out exactly which 07:03.000 --> 07:06.000 other IPs are available from a pool of IP addresses. 07:06.000 --> 07:08.000 And this is an anti-sensorship measure, which 07:08.000 --> 07:13.000 will stop over subsequent slides. 07:13.000 --> 07:16.000 All of this is very good, but a VPN can help 07:16.000 --> 07:19.000 and app bypass the turn device, which means it will 07:19.000 --> 07:22.000 bypass the firewall, the two-timented or sandbox. 07:22.000 --> 07:24.000 A privilege app can bypass any 07:24.000 --> 07:26.000 restriction Android at will. 07:26.000 --> 07:28.000 This is the how Android structure. 07:28.000 --> 07:31.000 A privilege app is any app that Google 07:31.000 --> 07:32.000 themselves implement. 07:32.000 --> 07:34.000 You cannot write a privilege app, I cannot write it. 07:34.000 --> 07:35.000 Google can. 07:35.000 --> 07:39.000 So there apps can bypass the firewall. 07:39.000 --> 07:42.000 So it's not a full proof, but. 07:42.000 --> 07:44.000 So this is what the app looks like today. 07:44.000 --> 07:47.000 As you can see, it has four main functionalities, 07:47.000 --> 07:49.000 a DNS of firewall, a proxy layer. 07:49.000 --> 07:52.000 And it shows applications that it shows all 07:52.000 --> 07:54.000 the install applications and the sandboxing 07:54.000 --> 07:56.000 that can perform on them. 07:56.000 --> 07:58.000 Again, this is Daniel McKay. 07:58.000 --> 08:00.000 He says that graph inverse is a security 08:00.000 --> 08:01.000 for the standard distribution. 08:01.000 --> 08:03.000 He says that documents everything 08:03.000 --> 08:07.000 in DNS on two his users that want this layer of control 08:07.000 --> 08:13.000 on their networking related privacy and security. 08:13.000 --> 08:20.000 So in DNS section, we implement five, six different protocols. 08:20.000 --> 08:21.000 We implement it. 08:21.000 --> 08:23.000 Oblius DNS or HTTPS. 08:23.000 --> 08:26.000 That's a relatively new standard. 08:26.000 --> 08:28.000 That not many apps implement. 08:28.000 --> 08:32.000 It has its own encryption mechanism using HPKE. 08:32.000 --> 08:37.000 I will probably keep the encryption. 08:37.000 --> 08:39.000 And on any Android university, 08:39.000 --> 08:43.000 you'd not see more than five k to 10 k unique domains being hit. 08:43.000 --> 08:45.000 Which means that you can keep your cache as small 08:45.000 --> 08:47.000 and reply to every request from the cache. 08:47.000 --> 08:49.000 This is much, much faster. 08:49.000 --> 08:52.000 This helps because if you're doing encrypted DNS, 08:52.000 --> 08:55.000 4kB is just a TLS handshake, just a certificate 08:55.000 --> 08:57.000 and just a handshake is 4kB. 08:57.000 --> 08:59.000 And a DNS query is very light. 08:59.000 --> 09:01.000 30 bytes, the queries and the responses are 100 bytes. 09:01.000 --> 09:05.000 So you're spending 4kB in handshake just to exchange 30 bytes 09:05.000 --> 09:07.000 of data that sounds very useful to me. 09:07.000 --> 09:10.000 So we implement a bunch of techniques like an order of 1 LFU cache. 09:10.000 --> 09:12.000 LFU cache is a really good for DNS. 09:12.000 --> 09:14.000 We implement a variant of S4 LRU, 09:14.000 --> 09:16.000 that was published by Facebook. 09:16.000 --> 09:18.000 We also call as request into one. 09:18.000 --> 09:21.000 So if there are 25 apps that are trying to connect to Google.com, 09:21.000 --> 09:24.000 we only send one request out for that 30 second window. 09:24.000 --> 09:27.000 And from that reply, we send that reply out to all different apps. 09:27.000 --> 09:30.000 This happens pretty frequently on mobile devices 09:30.000 --> 09:32.000 because when you unlock the device, 09:32.000 --> 09:34.000 all the applications are trying to get the notifications. 09:34.000 --> 09:36.000 And all of these notifications, 09:36.000 --> 09:38.000 it's the same five-based APIs. 09:38.000 --> 09:40.000 So you can just send one DNS request out 09:40.000 --> 09:42.000 instead of sending multiple DNS requests out. 09:42.000 --> 09:45.000 And we also pull connections to reduce the order of handshakes 09:45.000 --> 09:48.000 and implement the LFU solution where we can. 09:48.000 --> 09:52.000 Another particular idea of implementing DNS on Android is that 09:52.000 --> 09:54.000 a DNS or a GPS or DNS or TLS is your need. 09:54.000 --> 09:57.000 The DNS is always for a DNS or because the DNS or a GPS 09:57.000 --> 10:00.000 and DNS or TLS is always have domain names in them. 10:00.000 --> 10:02.000 So you need to resolve them first. 10:02.000 --> 10:04.000 This is the amount to easily blocks. 10:04.000 --> 10:06.000 If I block domain resolution for popular DNS resolvers, 10:06.000 --> 10:09.000 like DNS.google and cloudshaddener.com, 10:09.000 --> 10:12.000 then see the two simply do censorship. 10:12.000 --> 10:15.000 What we do is we pay Mware IP addresses a compile time 10:15.000 --> 10:18.000 for these popular DNS domains in the app. 10:18.000 --> 10:22.000 So there's no need to resolve a DNS. 10:22.000 --> 10:26.000 There's no need to resolve IP address for the popular DNS resolvers. 10:26.000 --> 10:29.000 Also, because of per app split tunneling, 10:29.000 --> 10:32.000 like you can send first app can be sending it traffic 10:32.000 --> 10:35.000 to ViGuard 1, second app could be sending traffic to mobile device, 10:35.000 --> 10:37.000 mobile data, third app could be sending data to 10:37.000 --> 10:40.000 could be connecting via the Wi-Fi network. 10:40.000 --> 10:42.000 Each of these networks have their own DNS implementations. 10:42.000 --> 10:46.000 So we need to implement a per transport cache. 10:46.000 --> 10:49.000 So all of these are complications of implement 10:49.000 --> 10:52.000 implementing a DNS layer on Android. 10:52.000 --> 10:55.000 DSO TCP is again another complex piece, 10:55.000 --> 10:58.000 which except for two apps that I know, 10:58.000 --> 11:01.000 now the other Android DNS implementation apps implement. 11:01.000 --> 11:03.000 They only implement DSO TCP, 11:03.000 --> 11:05.000 and you'd find that some of the trackware SDKs, 11:05.000 --> 11:07.000 like in mobile and gamuga, 11:07.000 --> 11:12.000 they simply use DSO TCP that bypass these DNS blockers. 11:12.000 --> 11:15.000 Also, some of these apps are missing HTTP, 11:15.000 --> 11:17.000 HTTP implementation, which is used for 11:17.000 --> 11:21.000 encrypted client hello and IP hints. 11:21.000 --> 11:27.000 So HTTP records can be as complicated as this. 11:27.000 --> 11:29.000 And if you're not traversing them properly, 11:29.000 --> 11:30.000 it's not parsing them properly. 11:30.000 --> 11:33.000 You could miss some of the domains that you might 11:33.000 --> 11:35.000 wanted to block, but now you're not blocking. 11:35.000 --> 11:38.000 Because those domains are closed in this maze of HTTP DNS. 11:38.000 --> 11:43.000 It's like seen aim, but it's much more sophisticated than seen aim 11:43.000 --> 11:47.000 blocking. 11:47.000 --> 11:50.000 So firewall contains, we're building file, 11:50.000 --> 11:53.000 contains 70 million domain names from which you can choose. 11:53.000 --> 11:55.000 And these domain names, if you lay them on a hash map, 11:55.000 --> 11:59.000 it's on 500 MP, and there's only five 12 MP on Android for an app. 11:59.000 --> 12:03.000 So what we do is, we take the domain name and 12:03.000 --> 12:08.000 flatten them out and put them on the disk. 12:08.000 --> 12:12.000 It's basically a radic stride that's laid out on the disk. 12:12.000 --> 12:16.000 And these implementations, I mean, 12:16.000 --> 12:18.000 this particular radic stride follows the 12:18.000 --> 12:20.000 sudden try implementation. 12:20.000 --> 12:24.000 That is the most optimal representation of a try. 12:24.000 --> 12:26.000 That's possible. 12:26.000 --> 12:29.000 So this file is simply m mapped into memory. 12:29.000 --> 12:32.000 So only the pieces of file that you're reading from the stride 12:32.000 --> 12:34.000 are the ones that are mapped into memory. 12:34.000 --> 12:36.000 The rest are simply not used. 12:36.000 --> 12:40.000 So this stride, I think, is around 100 MP in size. 12:40.000 --> 12:44.000 And also the lookups are pretty fast, because it's a try. 12:44.000 --> 12:47.000 And five pay addresses, we build a thread bit tree, 12:47.000 --> 12:49.000 we keep it entirely in memory. 12:49.000 --> 12:51.000 Tripit tree is also a variation of a petrisha 12:51.000 --> 12:52.000 try or radic stride. 12:52.000 --> 12:58.000 It only stores the critical bit as the name says. 12:58.000 --> 13:02.000 Another peculiar thing that we have to implement for firewall on Android 13:02.000 --> 13:05.000 is something called as isolate, because it's too much 13:05.000 --> 13:09.000 tiring for people to add too many things to the block list. 13:10.000 --> 13:12.000 Reverse it on its head. 13:12.000 --> 13:15.000 So the only thing that you allow and app is allowed to connect. 13:15.000 --> 13:18.000 So you can put certain apps in isolate mode. 13:18.000 --> 13:21.000 Also another big problem with the VPN apps on Android is that 13:21.000 --> 13:24.000 applications cannot detect app lane modes. 13:24.000 --> 13:27.000 What that means is that on connectivity laws on network laws, 13:27.000 --> 13:29.000 these applications try to keep setting packets, 13:29.000 --> 13:33.000 and this results in battery drain. 13:33.000 --> 13:36.000 So we have to somehow communicate the stall in network or 13:36.000 --> 13:40.000 connectivity laws to other applications. 13:40.000 --> 13:44.000 The specific APIs for the Android and not many, 13:44.000 --> 13:46.000 we can apps do it. 13:46.000 --> 13:50.000 Our app also includes an independent mapping for net behavior, 13:50.000 --> 13:54.000 for net behavior for UDP and TCP, those are two RSEs. 13:54.000 --> 13:57.000 And there are certain apps like telegram, 13:57.000 --> 13:59.000 Instagram, and WhatsApp that do their own DNS. 13:59.000 --> 14:02.000 So if they do their own DNS, and if you are domain name block list, 14:02.000 --> 14:04.000 then those block lists are bypass. 14:04.000 --> 14:06.000 What we do is that we detect that these applications 14:06.000 --> 14:09.000 did not use our DNS, and they tried to connect to an IP 14:09.000 --> 14:12.000 straight up, and we block the requests that we see that 14:12.000 --> 14:19.000 are going straight to IP addresses without resolution. 14:19.000 --> 14:21.000 So why I got slightly complicated as you can see, 14:21.000 --> 14:22.000 that's device on the other side. 14:22.000 --> 14:26.000 So basically, device on the right, 14:26.000 --> 14:31.000 it converts packets into sockets, and the device 14:31.000 --> 14:35.000 just below why I got converts sockets into packets. 14:35.000 --> 14:37.000 Because why I got it in packets? 14:37.000 --> 14:39.000 Can't deal with sockets. 14:39.000 --> 14:41.000 So it's kind of like, device, a middle version of the device, 14:41.000 --> 14:43.000 which is run keysp, IP stack in the reverse, 14:43.000 --> 14:45.000 and it creates fake devices. 14:45.000 --> 14:48.000 We can run multiple situi guards, null problem, 14:48.000 --> 14:50.000 and these vi guards can send out QDP. 14:50.000 --> 14:57.000 I mean, they encapsulate these packets into UDP and send them out. 14:58.000 --> 15:01.000 Viagad rely on high frequency timer, 15:01.000 --> 15:02.000 but that's not algorithm. 15:02.000 --> 15:06.000 Android only RTCs that expose via the go-lang layer, 15:06.000 --> 15:09.000 which is what the official implementation is written in. 15:09.000 --> 15:12.000 So that actually gives us a lot of pain. 15:12.000 --> 15:17.000 Also roaming sockets, Viagad can roam among networks, 15:17.000 --> 15:20.000 and that implementation is also missing from Android. 15:20.000 --> 15:22.000 Tail scale implemented this in there, 15:22.000 --> 15:23.000 but it's a waste for the implementation. 15:23.000 --> 15:25.000 We are trying to move bits and pieces, 15:25.000 --> 15:28.000 and see in the open source code over to our code. 15:28.000 --> 15:29.000 And find a censorship. 15:29.000 --> 15:31.000 We implement these four techniques right now. 15:31.000 --> 15:35.000 We split TC packet at either 30 second or 64. 15:35.000 --> 15:38.000 So these values come from project called Geneva, 15:38.000 --> 15:41.000 and they published certain numbers. 15:41.000 --> 15:44.000 And they said that if you split the TC packet at randomly between 32 and 64, 15:44.000 --> 15:47.000 it actually confuses a lot of DPI sensors. 15:47.000 --> 15:49.000 And so we split it as randomly, 15:49.000 --> 15:52.000 and then some of the DPI sensors get really confused 15:52.000 --> 15:54.000 and packets go through. 15:54.000 --> 15:57.000 The other thing we do is you could fragment the TLS record 15:57.000 --> 16:01.000 at 6 or 64 between 64 bytes. 16:01.000 --> 16:03.000 So this is what a TLS record looks like. 16:03.000 --> 16:05.000 It has record type protocol version, 16:05.000 --> 16:08.000 and you can see N plus 5 is the size of the record, 16:08.000 --> 16:09.000 and then the message. 16:09.000 --> 16:13.000 So you split exactly between 64 byte, 16:13.000 --> 16:15.000 and you send out two packets, 16:15.000 --> 16:17.000 and the DPI, because it's a stateless DPI. 16:17.000 --> 16:19.000 If it's a stateless DPI, it will be able to again 16:19.000 --> 16:21.000 re-joint the packets and the stateless DPI, 16:21.000 --> 16:22.000 the packet goes through. 16:22.000 --> 16:25.000 So all of this information comes from Geneva. 16:25.000 --> 16:28.000 It's not something that we found out ourselves. 16:28.000 --> 16:32.000 And IP printing is basically a variant on domain printing. 16:32.000 --> 16:34.000 So a client is trying to access service one. 16:34.000 --> 16:35.000 It gets access to service one, 16:35.000 --> 16:38.000 but the IP that is using access service one is some of the IP. 16:38.000 --> 16:41.000 Now if you recall, I mentioned what take gain is addresses. 16:41.000 --> 16:42.000 So we'll play face addresses, 16:42.000 --> 16:43.000 and then we have a full of IP addresses. 16:43.000 --> 16:45.000 So we know that these full of IP addresses are Amazon's network. 16:45.000 --> 16:47.000 These full of IP addresses are Google's network. 16:47.000 --> 16:51.000 And we know that this particular service is available behind Google's network. 16:51.000 --> 16:53.000 So we connect to any of these other IPs, 16:53.000 --> 16:54.000 actually the connection goes through. 16:54.000 --> 16:56.000 So that's called IP printing. 16:56.000 --> 16:58.000 And domain printing is basically the client itself, 16:58.000 --> 17:00.000 asking for service number one, 17:00.000 --> 17:01.000 but actually behind the scenes, 17:01.000 --> 17:02.000 connecting to service number two. 17:02.000 --> 17:09.000 So most of our net range is written in Go. 17:09.000 --> 17:12.000 It's actually painful. 17:12.000 --> 17:16.000 So these are kind of errors that you see on Android, 17:16.000 --> 17:18.000 just one line, index out of range one. 17:18.000 --> 17:20.000 There's no stateless, you don't know which part of the code 17:20.000 --> 17:21.000 this error came from. 17:21.000 --> 17:23.000 And if at all there's a tombstone, 17:23.000 --> 17:25.000 all you see is runtime.rays or AB. 17:25.000 --> 17:28.000 So Go is a program language that implements system call, 17:28.000 --> 17:29.000 like it doesn't use Lipsy. 17:29.000 --> 17:34.000 It uses a system call all the way through even on BST machines. 17:34.000 --> 17:39.000 The BST people obviously don't like that because I think they say that the stable layer, 17:39.000 --> 17:40.000 ABL layer is the Lipsy layer, 17:40.000 --> 17:42.000 and not the system call layer unlike full Linux, 17:42.000 --> 17:43.000 which is a system call layer. 17:43.000 --> 17:45.000 So these are the kind of, 17:45.000 --> 17:47.000 this is what it results in, 17:47.000 --> 17:52.000 we just see the system call that says runtime.rays. 17:52.000 --> 17:54.000 So C Go is also not Go. 17:54.000 --> 17:56.000 So C Go is what runs on Android. 17:56.000 --> 18:00.000 It's not Go and there's a lot of handling that we have to do 18:00.000 --> 18:03.000 when the code jumps from Go to Java and comes back from Java to go. 18:03.000 --> 18:05.000 We have to do a lot of handling our own. 18:05.000 --> 18:09.000 A lot of H cases, there are a lot of bugs, there are a lot of crashes there. 18:09.000 --> 18:11.000 Android has something called as memory tagging extensions. 18:11.000 --> 18:13.000 And if you find such things in Go code, 18:13.000 --> 18:17.000 which just can't pages and pages of 4KB in size, 18:17.000 --> 18:20.000 then that's a big problem because memory tagging extensions don't let you go 18:20.000 --> 18:23.000 beyond the page boundary that you actually own. 18:23.000 --> 18:27.000 So SQLite is also kind of slightly problematic for analytical queries 18:27.000 --> 18:28.000 because you can see we show them, 18:28.000 --> 18:30.000 we show charts for app charts, 18:30.000 --> 18:32.000 we show many statistics. 18:32.000 --> 18:34.000 And batching rights is a problem, 18:34.000 --> 18:36.000 right heavy in memory tables, 18:36.000 --> 18:38.000 very lot of battery, 18:38.000 --> 18:41.000 analytical queries are a big problem because the queries are very expensive. 18:41.000 --> 18:43.000 Back up in restore with Val, 18:43.000 --> 18:47.000 right I had logging is a nightmare. 18:47.000 --> 18:50.000 So this is Nathan Feta's, 18:50.000 --> 18:52.000 I think he's the lead developer on the Guardian Pro. 18:52.000 --> 18:53.000 It's over, he said in 2021, 18:53.000 --> 18:55.000 our project has improved way, way, way, 18:55.000 --> 18:56.000 since I don't know if he still uses it, 18:56.000 --> 19:00.000 but this is what he wrote in 2021. 19:00.000 --> 19:03.000 So most of our problems come from obscure networks 19:03.000 --> 19:05.000 because there are 3 billion Android devices 19:05.000 --> 19:08.000 and it's a very fragmented ecosystem. 19:08.000 --> 19:13.000 And our app is also an observability and the security layer. 19:13.000 --> 19:17.000 So what we do is we show real-time logs from our applications to users. 19:17.000 --> 19:20.000 They can copy these logs and send to us so that we able to debug it. 19:20.000 --> 19:23.000 They can also copy these logs into popular LLM 19:23.000 --> 19:27.000 and the LLM is actually able to make sense of actually what's going wrong with the app. 19:27.000 --> 19:30.000 So we actually show the logs here to all the users there. 19:30.000 --> 19:34.000 So we have 3 million unique IPs hitting our DNS servers, 19:34.000 --> 19:36.000 900 came stores on page 250. 19:36.000 --> 19:39.000 We have the second most popular VPN app on Android. 19:39.000 --> 19:42.000 So funding mostly comes from these four patterns. 19:42.000 --> 19:45.000 Mozilla Builders has gained a 12K, in July 20th, 19:45.000 --> 19:48.000 first-in-a-12K, in 2013, in 2004, 19:48.000 --> 19:52.000 and first-in-a-20-25K in this year. 19:52.000 --> 19:56.000 And first-in-a-in-plus from this we funded our travel to first-in. 19:56.000 --> 19:57.000 So thanks to them. 19:57.000 --> 19:59.000 And CloudFlare also supports us, 19:59.000 --> 20:02.000 but I cannot disclose them all, but it's very high. 20:02.000 --> 20:05.000 All right, so these are the references. 20:05.000 --> 20:08.000 And hopefully the slides will be up. Thank you. 20:17.000 --> 20:19.000 Do we have any questions? 20:31.000 --> 20:34.000 Hi, thank you very much for the presentation. 20:34.000 --> 20:36.000 I had a question, maybe it's very simple. 20:36.000 --> 20:39.000 You've mentioned, if I didn't misunderstand it, 20:39.000 --> 20:42.000 that you have a feature in Writhing Firewall, 20:42.000 --> 20:45.000 where you identify calls that are made, 20:45.000 --> 20:49.000 or a request that are made to the same IP addresses, 20:49.000 --> 20:51.000 within a 30-second window, 20:51.000 --> 20:54.000 and you just issue one request. 20:54.000 --> 20:58.000 Have you ever seen this leads to any issues across applications? 20:58.000 --> 21:01.000 No, we actually map on the domain name. 21:01.000 --> 21:04.000 So if at all, there's 30 requests for Google.com, 21:04.000 --> 21:06.000 and then we make them, we only make one request out, 21:06.000 --> 21:08.000 and we get other requests. 21:08.000 --> 21:10.000 I don't, I don't, I don't have seen this become a prod. 21:10.000 --> 21:13.000 I at least have been no public report of the problem 21:13.000 --> 21:14.000 for on this. 21:18.000 --> 21:19.000 We're running out of time. 21:19.000 --> 21:20.000 Thank you very much. 21:20.000 --> 21:22.000 Maybe another round of applause. 21:31.000 --> 21:33.000 Thank you very much.