WEBVTT 00:00.000 --> 00:08.160 Our next speaker here, Trey Fogetti, is here to talk about the challenges of user privacy in a location-sensitive system like 911. 00:08.640 --> 00:11.300 He's part of the 911 Association. 00:11.800 --> 00:23.320 This talk is being recorded to show it online later on, so if anyone has any questions, please walk down to the microphone at the center aisle and we can record the questions too. 00:23.320 --> 00:25.260 So without further ado, Trey. 00:25.940 --> 00:29.500 Thank you so much, and thank all of you for being here this afternoon. 00:29.500 --> 00:32.360 I know your time at DEF CON is precious. 00:32.740 --> 00:43.260 And I will say for my part, I very much want to make this talk a lot less formal and a lot more interactive than some of the talks that you'll see in the other tracks. 00:43.260 --> 00:48.540 So if you have at some point a question about anything that I'm saying, please don't wait until the end. 00:48.540 --> 00:54.180 Come up to the microphone, and as soon as I get to a convenient pausing point, I will take your question. 00:54.180 --> 00:59.060 Because this is a really interesting area that I'm very passionate about. 00:59.140 --> 01:03.080 I'm being told I can't be heard, so let me... I'm just going to hold this. 01:03.080 --> 01:03.660 How about that? 01:03.660 --> 01:04.660 Everybody hear me now? 01:04.660 --> 01:05.360 Good. 01:05.760 --> 01:13.040 So where we start is... I get a question all the time. 01:13.080 --> 01:17.020 So you guys at 911, you're just tracking everybody all the time, right? 01:17.020 --> 01:18.760 That's how you know where I am. 01:18.900 --> 01:21.300 And the answer couldn't be further from the truth. 01:21.300 --> 01:24.760 We are not tracking you at any time. 01:24.760 --> 01:32.240 In fact, you would almost be appalled at how little location data we do get when we want to find you, which is when you call 911. 01:32.320 --> 01:56.940 So my talk is going to go over a little bit about what we do get, when we get it, how we are actually part of the privacy solution by virtue of keeping people who want access to location data away from it when they shouldn't have it, and how we acquire and store and use location data when you make it available by calling 911. 01:57.120 --> 02:03.580 So at the outset, I think I want to start with just a quick thing about how location works. 02:03.660 --> 02:08.100 Are folks here familiar with how GPS works, like generally? 02:08.900 --> 02:12.100 Okay, I'm going to go into it just kind of at a very high level. 02:12.100 --> 02:20.980 So basically, a few thousand miles up, we have a constellation of 30-odd satellites orbiting the Earth, roughly every 90 minutes. 02:20.980 --> 02:27.060 And each one of them is singing a unique song, but they're singing it on the same frequency. 02:27.280 --> 02:38.860 And by singing the same song inside a receiver, essentially, you can find out how far off in time your song is from the one being sung by the satellite. 02:38.860 --> 02:41.080 And that tells you a time offset. 02:41.080 --> 02:59.120 So we multiply that by the speed of light, correct for things like the diffraction of the ionosphere that delays these signals, and then once we have ranging from multiple satellites, then your device can calculate its location in 3D space. 02:59.120 --> 03:01.440 Now, it's pretty good horizontally. 03:01.440 --> 03:08.160 GPS, in the best of cases, can give us 5 to 10 meter fixes most of the time. 03:08.160 --> 03:19.980 If you have a really good device with a great antenna and, you know, a multi-band receiver, and you leave it stationary for a very long time, you can get that down to like a tenth of a meter reliably, or better. 03:20.020 --> 03:32.340 But for this typical case of something that's cheap enough to put in a smartphone, and for us to carry around with us every day, and, you know, doesn't have a gigantic antenna sticking out the end of it, that's not really the reality. 03:32.340 --> 03:34.660 You're not going to get anything nearly that close. 03:35.220 --> 03:41.760 So, historically, we've had this problem of we need to find people when they call 911, so how are we going to do that? 03:41.760 --> 03:43.600 Well, in the wireline world, it was easy. 03:43.600 --> 03:47.040 We knew where the telephone company's wires went. 03:47.040 --> 03:50.900 They kept a billing database that said, you know, here's where our wires go. 03:50.900 --> 03:59.240 And when you established phone service, we could go to them and say, look, for every address that you put in your database, you have to validate that with somebody. 03:59.240 --> 04:11.200 It's something called the Master Street Address Guide for your locality, which is a table that contains all of the valid street names and all of the valid number ranges within those street names. 04:11.540 --> 04:14.120 And so they could submit that address, make sure that it was valid. 04:14.120 --> 04:21.160 If it wasn't, they had to go back to you and say, hey, it looks like your street doesn't exist, or potentially your number's out of the range. 04:21.160 --> 04:21.900 Like, what happened? 04:21.900 --> 04:22.960 Did somebody build something new? 04:22.960 --> 04:25.240 And if that's the case, okay, we've got to go fix the database. 04:25.300 --> 04:26.300 But there was a process. 04:26.300 --> 04:27.500 We knew where everything was. 04:27.620 --> 04:28.800 Smartphones aren't like that. 04:28.800 --> 04:29.720 They move around. 04:29.720 --> 04:31.780 Cell phones generally move around. 04:31.780 --> 04:37.600 And so we had to come up with ways to figure out where mobile devices were. 04:37.600 --> 04:41.920 In the early days, there were two very general ways of doing this. 04:41.920 --> 04:45.620 There was called the network-based model and the handset-based model. 04:45.620 --> 05:06.760 In the network-based model, devices in the network either transmitted or received signals to or from a device and used information like angle of arrival, time difference of arrival, or absolute timing offsets to calculate ranging and bearing data and figure out where the device was. 05:06.760 --> 05:07.380 And that worked. 05:07.380 --> 05:08.620 It's actually very fast. 05:08.620 --> 05:11.180 It's one of the fastest ways to find someone generally. 05:11.180 --> 05:13.460 The problem is it's not terribly precise. 05:13.460 --> 05:22.100 With those sorts of methods, you can get within 200 to 300 meters very quickly, but you'll never get down to some tens of meters. 05:22.100 --> 05:23.920 It just doesn't work that way. 05:23.920 --> 05:34.500 So that was the typical technology in CDMA, or excuse me, in GSM networks, because in GSM networks, that was what was convenient. 05:34.500 --> 05:37.900 They had the right sort of signal structure to do that kind of ranging. 05:38.080 --> 05:48.180 CDMA had, at the time, a really cool advantage, which is when I talked about the way GPS satellites sing little songs, they're actually doing that in kind of a version of CDMA. 05:48.200 --> 06:04.200 All the satellites transmit on the same frequency, but they do it with different pseudo-random number sequences imposed over that, and you can pick individual satellites out by knowing which one of those are, looking up in an almanac, okay, what satellites should I be able to see, 06:04.200 --> 06:09.760 getting that from the constellation itself even, and using that data to figure out, okay, what should I listen for? 06:09.760 --> 06:19.460 Since CDMA handsets already had correlators inside that could do that for the networks they were attached to, someone had the bright idea, well, let's just reuse that as a GPS receiver. 06:19.460 --> 06:19.980 And it worked. 06:19.980 --> 06:20.760 It worked brilliantly. 06:20.760 --> 06:35.920 Now, the trouble was, early on, there was only one, because they only expected you to be carrying on one voice conversation at a time, so when, in the early days, they wanted to figure out where you were for 911 purposes, they actually had to say, hold on a second, 06:35.920 --> 06:46.540 you're going to hear silence while I determine your location, and then they would trigger, the 911 center would trigger something in the carrier network to actually start that process with your device. 06:46.540 --> 06:55.960 The device would listen for the satellites, collect the data, correlate it, ship it off to the network, the network would calculate your position and relay it via a database to the 911 center. 06:56.000 --> 07:00.240 Really kludgy, and you don't want to tell somebody in the midst of an emergency, please hold, right? 07:00.240 --> 07:04.000 That's not a great thing to tell someone when they're, like, screaming to death. 07:05.500 --> 07:14.600 So, over time, we got better, we got better chips with more correlators, we got to the point that we could actually put GPS chips in almost every phone, and these days, that's what everybody does. 07:14.600 --> 07:15.680 We have GPS chips. 07:15.680 --> 07:18.580 Most of the network technologies have sort of gone away. 07:18.580 --> 07:32.500 We still have two out there called Advanced Forward Link Trilateration, which is a ranging technology used mostly in CDMA networks, and then OTDOA, which stands for Observed Time Difference of Arrival. 07:32.500 --> 07:35.860 How many navigation nerds are there in the room who have heard of LORAN? 07:37.120 --> 07:39.140 Okay, we got a few people, good. 07:39.140 --> 07:40.980 So, this is the really cool thing. 07:40.980 --> 07:45.560 OTDOA is just LORAN with cell towers instead of LORAN chains. 07:45.560 --> 07:53.640 You just listen for the time differences between transmissions of synchronized towers, and then you can use that to do hyperbolic ranging, which is really fun. 07:53.640 --> 07:55.060 It's kind of a cool sort of thing. 07:55.060 --> 08:00.540 Again, it's one of these network technologies that are fast, but not necessarily super precise. 08:01.960 --> 08:06.000 All well and good, okay, fine, you've got a measurement system. 08:06.800 --> 08:08.340 What do we do with that now? 08:08.340 --> 08:11.960 In the 911 case, and I said this before, we're not tracking you. 08:11.960 --> 08:18.460 We don't want that stuff running all the time, because frankly we don't have anything to do with the data, and it's really not of any interest to us. 08:18.460 --> 08:21.460 We need to know where you are when you have an emergency. 08:21.840 --> 08:33.460 You don't want that going on, obviously for privacy reasons, otherwise you wouldn't be in the crypto privacy village, and you also don't want it going on because it's a very battery intensive activity to keep track of yourself precisely all the time. 08:33.460 --> 08:49.640 In fact, most of the things that you see, you know, this question, why is it that Uber can find me, but 911 can't, that we hear so often, I really hate this question, because like most of the time, Uber is not, Uber doesn't, hasn't measured where you are to any degree of certainty. 08:49.640 --> 08:57.300 They have software in your device platform and in their platform that's making a very educated guess. 08:57.320 --> 09:01.940 People tend to focus on the little blue dot that tells you where the thing thinks you are. 09:01.940 --> 09:05.680 What they often don't realize is that there's also a blue circle around that. 09:05.680 --> 09:16.060 There's some uncertainty associated with that location fix, and often in the case of commercial apps on smartphones, that uncertainty is actually relatively large. 09:16.060 --> 09:19.980 It can be on the order of hundreds or even thousands of meters. 09:20.760 --> 09:30.160 That's calculated at about a 90% confidence level most of the time, which we want, we want only about a 10% margin that will find you outside the circle. 09:30.160 --> 09:39.640 But if you think about a place like Caesar's Palace, an uncertainty of 100 meters or 200 meters makes it really difficult to find someone. 09:39.640 --> 09:42.020 It makes it really difficult to go search for them. 09:42.020 --> 09:49.740 200 meters might put me in any one of three different hotel towers, the casino, the conference center, and a bunch of restaurants. 09:49.740 --> 09:56.640 So you really have to deal with constraining that uncertainty somehow before you can use that for emergency response. 09:56.640 --> 10:01.880 Uber can make those guesses because it has that ability to then ask you, okay, where are you? 10:01.880 --> 10:03.060 In fact, does this match up? 10:03.060 --> 10:05.260 And if not, drag the map and pick the little dot. 10:05.260 --> 10:07.260 We don't have that luxury in 911. 10:07.900 --> 10:09.780 So I've said that we're not tracking you. 10:09.780 --> 10:11.200 Well, what are we doing? 10:11.240 --> 10:14.020 When you call 911, a few things happen. 10:14.020 --> 10:16.840 I've talked about some of the different methods that we've used. 10:17.420 --> 10:21.000 We're starting to add things from the handset now. 10:21.200 --> 10:26.980 Historically, only stuff that was baked into the baseband or the network was really available for 911. 10:27.220 --> 10:29.680 But these days, we're actually doing a lot more than that. 10:29.680 --> 10:33.760 This is bleeding-edge stuff that's just starting to come into the devices. 10:33.820 --> 10:49.580 But we're starting to be able to use Wi-Fi and Bluetooth both to do sort of associative location to say, look, we know that Trey's Wi-Fi access point is at this particular address in this town because he's there all the time and he's associated with that and so on. 10:49.580 --> 11:00.200 So if the phone can see Trey's Wi-Fi access point, that's probably a location of association that we can use as a starting point for a search. 11:00.200 --> 11:02.120 It's kind of a probabilistic sort of thing. 11:02.120 --> 11:04.880 That's a very uncomfortable proposition for 911. 11:04.880 --> 11:06.860 We want things to be deterministic. 11:06.860 --> 11:16.020 We want to be able to say to the cops and firefighters in the field who really couldn't find their way out of the building without our help that this is exactly where to go. 11:16.020 --> 11:17.160 But that's not realistic. 11:17.160 --> 11:20.500 That's just not the way the physics of measurement work. 11:20.500 --> 11:30.760 And that's why the other thing that we're looking at, Bluetooth beacons, you put Bluetooth low energy in a light bulb for lots of really great reasons. 11:30.760 --> 11:39.800 One of the things you can do with that is associate that UUID, that Bluetooth beacon ID, with that location in a database. 11:39.800 --> 11:55.960 We're working on something called the National Emergency Address Database, which will actually associate Wi-Fi max and Bluetooth UUIDs with physical locations in the world so that if, for example, there's a beacon in this particular ballroom, I can be localized, 11:55.960 --> 12:01.860 if I'm within 10 to 30 meters of that, I can be localized very, very precisely with that. 12:01.860 --> 12:05.180 But of course, that takes getting a lot of beacons out in the world. 12:05.180 --> 12:07.340 Thank you, Internet of Things, that's going to be easy. 12:07.400 --> 12:20.140 But then it also means we've got to track those things and make sure that if they move, we find out about it, that there's some aging in the database to make sure as things get older, we trust them less to provide location and so on. 12:20.580 --> 12:25.760 So at call time, when you make a 911 call, a couple of things happen. 12:25.760 --> 12:34.380 First off, your platform, your phone platform, whether it's Android, iOS, Blackberry, whatever, completely overrides your location privacy settings. 12:34.380 --> 12:40.220 It says, look, you've made a 911 call, this is really important, turn everything on, we need to find you. 12:40.220 --> 12:52.280 Historically, that's only meant like the GPS chip and not some of the other cool things that you have in there like the accelerometers, gyroscopes, magnetometers, barometers, Wi-Fi, Bluetooth, et cetera, but we're working to change that. 12:52.280 --> 13:01.160 We're actually working to get to the point where we can ingest data from all of those different things to create something called device-based hybrid. 13:01.420 --> 13:07.800 And this is where we use things opportunistically where they make sense. 13:07.800 --> 13:27.820 So GNSS, GPS, Galileo, Glonass, Compass, Baidu, all of those things work phenomenally well outdoors in urban and suburban environments and even to some extent in sort of urban clusters, not necessarily in Manhattan and San Francisco and downtown Atlanta and Chicago. 13:27.820 --> 13:30.660 In those places, GPS is really, really awful. 13:30.860 --> 13:37.580 But Wi-Fi and Bluetooth things have much higher densities in those environments and consequently they are of more use. 13:37.580 --> 13:44.860 And so this is the concept behind device-based hybrid is we're going to opportunistically use what is best in the environment that it's in. 13:44.860 --> 13:50.680 So if you're in Manhattan and the best thing we have to figure out where you are is Wi-Fi and Bluetooth, we'll use that. 13:50.840 --> 13:55.500 And if not, if you're out someplace where GPS is working great, we'll use that. 13:56.460 --> 14:00.620 All of this is just, just sort of starting to happen. 14:01.100 --> 14:12.960 We've had one company called Rapid SOS that built some really cool stuff to kind of get location data around the database limitations of the legacy 911 network. 14:12.960 --> 14:24.360 And in doing that, they've kind of proven out that you can, you can get a lot more calls clustered down in that, you know, 0 to 20 meter range with device-based hybrid. 14:24.360 --> 14:27.080 And, and I don't mean to like endorse Rapid or, or something like that. 14:27.080 --> 14:28.900 There are tons of folks working on this. 14:28.900 --> 14:38.340 Google just announced a few months back that they're going to be doing a lot more in their fused location provider for emergency services purposes over the next 3 or 4 years. 14:38.540 --> 14:40.520 Including, and this, I thought this was really cool. 14:40.520 --> 14:48.740 They're putting dual frequency GPS receivers in their devices, which allows you to directly measure and cancel the ionospheric diffraction delay. 14:48.740 --> 14:51.720 And that is the primary source of error in a GPS fix. 14:51.720 --> 14:59.240 So in 3 to 4 years, your handset GPS locations, indoors and out, are going to be phenomenally better. 14:59.240 --> 15:02.440 They, they really will just get meaningfully better. 15:03.200 --> 15:06.960 We're also seeing barometers go into devices, which is really cool. 15:07.320 --> 15:13.900 These allow us to implicitly pull out a vertical location. 15:13.900 --> 15:16.580 If you have, oop, I've gone dead. 15:16.580 --> 15:18.220 If you happen to have, 15:21.320 --> 15:23.800 I think so, 15:28.040 --> 15:30.380 hmm, oh, there we go, we're back. 15:30.380 --> 15:43.980 If you happen to have a barometer, and you have a good external reference for what sea level pressure is, you can use those measurements, you can compare them and say, okay, I must be this much up or down from that reference datum. 15:43.980 --> 15:47.580 Now, in order to do this, you've got to have measurements that are fairly localized. 15:47.820 --> 16:05.360 And so, you know, another example, this company, NexNav, their idea is to put sort of pseudolites or fake GPS satellites on cell towers in buildings and broadcast basically their own GPS signal down at 900 megahertz where it penetrates deep into buildings. 16:05.360 --> 16:17.200 And to broadcast as part of that hyperlocal barometric pressure corrections that let them pull up exactly the height that you are at with a great deal of reliability. 16:17.200 --> 16:18.680 Now, what do we know about 900? 16:18.680 --> 16:19.900 900 is the junk band, right? 16:19.900 --> 16:25.300 Everything awful is in there, it's completely useless other than wireless meter readers who just sit on top of everything. 16:25.420 --> 16:34.240 Except that the one thing that is actually privileged in 900 megahertz is multilateration and location monitoring services. 16:34.240 --> 16:38.220 And there are licenses and these guys happen to have a lot of them. 16:38.240 --> 16:48.760 There are other folks who have them for other markets, but this is like a cool thing that you can do in the 900 megahertz band and you actually get interference protection if you do this. 16:48.760 --> 16:51.500 So, another cool thing. 16:51.500 --> 16:58.240 When you make that 911 call, all of this stuff kicks on and starts saying, okay, now where are you? 16:58.440 --> 17:08.140 Initially, when your 911 call arrives at a 911 center, most likely we will not have good location data at the start of the call. 17:08.140 --> 17:27.420 What typically happens, and this is something called phase 1 and phase 2, phase 1 location is what we get at the beginning of basically every wireless call and it just tells us the street address of the cell tower that you're attached to and the GPS coordinates of the tower. 17:27.420 --> 17:29.440 Again, this is not you, this is the tower. 17:30.080 --> 17:35.440 And it tells us the central bearing of the cell sector that's serving you. 17:35.440 --> 17:38.280 So, if you look up at a cell tower, it's usually kind of triangular. 17:38.280 --> 17:40.720 It's got antennas on the vertices of the triangle. 17:40.720 --> 17:43.540 Each of those has a particular central bearing. 17:43.540 --> 17:46.300 It's serving about 60 to 120 degrees. 17:46.300 --> 17:54.360 And so by knowing that kind of general bearing and then asking you questions, hopefully we can figure out, if you don't know, where you are. 17:55.740 --> 17:58.440 The way all of that works is super kludgy. 17:58.440 --> 18:04.920 It actually happens because of a database process that got started in the 1980s built for the wireline world. 18:04.920 --> 18:12.080 And that's why before we can get your more precise location, we have to wait a period of time for a couple of processes to happen. 18:12.080 --> 18:22.300 So, first of all, the device has to actually calculate a fix that is better than whatever it had from the tower and so forth. 18:22.300 --> 18:26.060 And then it has to communicate that back to the carrier network. 18:26.060 --> 18:31.500 The carrier network has to pass that to a database management system provider. 18:31.500 --> 18:46.340 They have to further process it and implant it into the database that ultimately your local telephone company typically maintains because it was the one that they maintained for that wireline process oh so long ago. 18:47.200 --> 18:56.640 Then, at that point, the 911 center system either automatically or manually can re-query the database and say, okay, is there anything better? 18:56.660 --> 19:02.760 And typically by the 15 to 25 second mark is when we'll start to see an improvement. 19:02.760 --> 19:08.000 Something like a GPS fix that's within the allowable error range. 19:08.000 --> 19:11.320 The carriers have location targets that they have to hit. 19:11.320 --> 19:19.460 Ultimately, those are going to get down to 50 meters horizontally and some number vertically that we don't know exactly what it will be yet, but we're working on that. 19:19.780 --> 19:21.540 Or a dispatchable address. 19:21.540 --> 19:26.000 And dispatchable address is the process I talked about before with the database piece of it. 19:26.640 --> 19:34.960 Now, the one sort of worrisome part about this is those values, those location values, we know they're very sensitive. 19:34.960 --> 19:37.340 Those are actually transmitted in the clear. 19:37.340 --> 19:45.240 But they're transmitted in the clear only within trusted carrier networks and then only on the network's control plane. 19:45.240 --> 19:57.560 So the location information never touches the user data plane until it actually gets down to the 911 center and it is received at the start or some number of seconds into your call. 19:58.140 --> 20:02.900 And then at that point, we look at this as like a hot potato. 20:02.900 --> 20:21.300 We'll keep that, store it, as long as we have to, to provide you with service and to keep the sort of records that 911 centers are legally obliged to keep, whether it's for investigatory purposes or just because the legislature said we want everything to be kept for 90 days or 120 days. 20:21.300 --> 20:28.120 Some things may get archived if they look like they're going to be important down the line, but not necessarily everything. 20:28.120 --> 20:35.840 We typically want to get rid of non-critical 911 data that's not subject to a litigation hold as quickly as possible. 20:35.840 --> 20:38.120 We really just want to get that out of the system. 20:39.440 --> 20:49.820 This is where it gets a little interesting because obviously being in public safety, 911 is part of a lot of law enforcement responses. 20:49.820 --> 20:53.500 A lot of law enforcement responses start as a result of a 911 call. 20:53.500 --> 20:55.060 In fact, almost all of them do. 20:57.300 --> 21:00.600 And 911 is known for having location data. 21:00.600 --> 21:07.060 People in the law enforcement and fire and EMS communities know that when you call 911, we get your location data. 21:07.300 --> 21:21.540 And so people not unreasonably often make the assumption that, well, if I need that for some other purpose, the way I should be able to get that is by just going to my friendly neighborhood 911 outfit and saying, hey, help me out with some of that good, 21:21.540 --> 21:22.980 good location data, right? 21:22.980 --> 21:24.820 And we get those requests all the time. 21:24.820 --> 21:32.900 Our members actually get location data requests from law enforcement and fire and EMS often when there's no actual 911 call going. 21:32.900 --> 21:41.920 So I said earlier, 911 really is on the front line of protecting user privacy because often the thing we have to do is tell sometimes even the boss no. 21:41.920 --> 21:44.960 Because we get 911 data for a purpose. 21:44.960 --> 21:46.060 We use it for a purpose. 21:46.060 --> 21:52.660 And that's part of user trust in the 911 system is that we're not going to misuse that 911 location data. 21:53.100 --> 22:01.540 The other reason that these things happen from time to time is we also have access to a process for exigent circumstances. 22:01.820 --> 22:07.880 So if you've ever seen the movie The Call with Halle Berry, so small aside, I got to meet Halle Berry. 22:07.880 --> 22:09.380 She is amazing in person. 22:09.380 --> 22:12.880 She is even more beautiful and even more friendly and awesome and wonderful. 22:12.980 --> 22:21.760 And she really took a lot of time and effort to get in the trenches with real 911 call takers and learn how they do what they do, which was really awesome and cool. 22:22.160 --> 22:23.600 Hopefully there will be a sequel. 22:23.900 --> 22:30.680 But in that movie, there was this occasion where a young woman was kidnapped and thrown in a trunk. 22:31.120 --> 22:37.900 And she made a very, she was only able to make a quick, discreet 911 call to say, you know, help, I'm in the trunk, right? 22:38.700 --> 22:46.200 When that happens, we've got to have some process to get some location data when you're not on a 911 call. 22:46.200 --> 22:57.520 Now the challenge for us is, as I talked about before, all of the location privacy settings and all of those sensors and measurement systems are not on unless you're in a 911 call. 22:57.520 --> 23:04.600 So the moment you hang up, we lose the ability to query for updated location information. 23:04.660 --> 23:23.340 And at that point, the best we can do, and I realize this sounds insane in 2017, is fax, yes, fax, a form to the carrier that was serving that 911 call to say, we need the best location data you've got for this particular phone number. 23:23.680 --> 23:28.120 The turnaround time for that can be 15 to 45 minutes. 23:28.120 --> 23:29.960 They generally, they do take it very seriously. 23:29.960 --> 23:34.340 They try to get the accident circumstances request processed as quickly as possible. 23:34.340 --> 23:36.400 But it is still a process. 23:36.400 --> 23:38.280 It's not an automated kind of thing. 23:38.280 --> 23:40.620 It is a very manual process. 23:40.800 --> 23:59.520 And then what happens once the carriers, lawyers, and engineers have looked at the form and said, okay, yes, this is a valid accident circumstances request, there really is an ongoing emergency with a threat to life or property, then and only then can they start to do a little bit to help us. 23:59.520 --> 24:01.420 But again, you're not in a 911 call. 24:01.420 --> 24:03.360 They can't turn on all the sensors. 24:03.460 --> 24:08.840 Typically the best we can do is we fall back to that sort of phase one information. 24:08.840 --> 24:14.140 We can typically get, okay, what tower and sector is serving the device. 24:14.420 --> 24:16.640 So we get, you know, kind of a point and a bearing. 24:17.200 --> 24:24.420 And if we're really, really lucky, in some cases, they will also be able to give us a range estimate. 24:24.500 --> 24:30.280 So I talked before about, you know, GPS and the way the ranges kind of cross over and you can get a location out of that. 24:30.280 --> 24:34.700 Another way you can develop a location fix is with a bearing and a range. 24:34.700 --> 24:42.080 So that's a line and an arc and wherever they cross, that's sort of generally where you are because, again, our measurements are kind of fuzzy. 24:42.180 --> 24:43.980 That arc can be really wide. 24:43.980 --> 24:45.640 That line can be really thick. 24:45.640 --> 24:47.500 You get kind of an annular sector. 24:48.360 --> 24:50.600 But, hey, that's still useful data. 24:50.600 --> 24:54.340 But again, it's not data that we're getting easily. 24:54.340 --> 24:56.700 It's something that's very, very protected. 24:57.120 --> 25:00.880 And in the 911 case, when we do get that, again, that's a manual process. 25:00.880 --> 25:02.320 So there's no database to put that in. 25:02.320 --> 25:11.480 That's actually something that's done on a, you know, we're on the phone with AT&T, Verizon, Sprint, T-Mobile, somebody, saying, okay, where are they now? 25:11.760 --> 25:13.020 Okay, has the location changed? 25:13.020 --> 25:14.000 Where are they now? 25:14.280 --> 25:16.740 And it's this very sort of iterative manual thing. 25:16.740 --> 25:27.780 And eventually, hopefully, you can work out, okay, it's a car that's going down, you know, I-40 or something like that, and say, let's go try to intercept whatever that is and find somebody. 25:27.780 --> 25:36.760 And then, of course, immediately after that exigent circumstance passes, that location data that was used for that purpose basically has to go away. 25:36.980 --> 25:43.820 Because it wasn't necessarily obtained with an investigative purpose for law enforcement purposes. 25:43.820 --> 25:47.300 So then you've got to start thinking about, okay, do we get a subpoena? 25:47.300 --> 25:48.320 Do we get a warrant? 25:48.320 --> 26:01.660 How do we actually acquire that location data in a way that can be used for some criminal prosecutorial purpose that's not related to an immediate emergency response? 26:01.900 --> 26:06.960 So that's kind of the multiple phasic approach that you have within the 911 center. 26:06.960 --> 26:09.460 We have the sort of baseline case. 26:10.440 --> 26:20.180 Weirdly, I often hear people say, 112, which is the European emergency number, is really part of the global emergency calling standard, and you should use that. 26:20.580 --> 26:25.120 And in a lot of places, using 112 might actually get you to a 911 center. 26:25.120 --> 26:26.340 It might. 26:26.340 --> 26:28.440 It won't always, but it might. 26:28.440 --> 26:33.560 And if it does, the challenge, though, is it won't turn on, usually, any of that cool location stuff. 26:33.560 --> 26:35.560 So don't dial 112 unless you're in Europe. 26:37.460 --> 26:45.420 Once that location process is over with, there is sort of a residual question of, what do we do with the data? 26:45.420 --> 26:59.260 And I don't think we have a good answer right now, because your average 911 center is not technically sophisticated enough to be encrypting or hashing or doing things like that with those sorts of data. 26:59.260 --> 27:03.500 They kind of have to rely on whatever their system vendor makes available. 27:04.140 --> 27:09.400 And oftentimes, that doesn't include robust confidentiality and integrity mechanisms. 27:09.400 --> 27:10.840 But that is something we're working on. 27:10.840 --> 27:21.080 So the next piece of this that I want to talk about is how we will acquire and use location information in a next-generation 911 environment. 27:21.340 --> 27:27.260 And basically, the process still stays heavily dependent on what the device and the network knows. 27:27.260 --> 27:36.300 But now, instead of dealing with legacy wireline databases from the late 70s, early 80s, we're going to take this into a more IP-based realm. 27:36.300 --> 27:47.400 So in next-generation 911, when you dial 911 from a phone, whether that's a voice call to 911 or a video call or even a text session, we're going to have real-time text very soon. 27:47.400 --> 27:48.940 Or total conversation. 27:48.940 --> 27:57.480 If you have different accessibility needs, you'll have the ability to communicate in all of those different ways simultaneously, which is really awesome if you have a hearing or speech disability. 27:58.820 --> 28:01.840 At that point, you've got a couple of things that have to happen. 28:01.840 --> 28:08.280 First, the device needs to figure out what 911 system its call should go to. 28:08.300 --> 28:12.700 So it's going to query something in the access network provider's network. 28:12.700 --> 28:14.920 And here I want to stop and define a couple of terms. 28:16.400 --> 28:22.280 Historically, when you bought phone service from the phone company, you were really buying two very different things. 28:22.280 --> 28:25.280 But it looked like the same thing because it was all you knew. 28:25.380 --> 28:31.420 When you bought voice service from the phone company, you were buying, first off, a transport network. 28:31.520 --> 28:35.960 So that's an access network that is capable of moving things around. 28:35.960 --> 28:38.000 But you were also buying an originating service. 28:38.000 --> 28:44.500 The ability to connect from one endpoint to another endpoint using some particular address. 28:45.000 --> 28:49.120 Today, networks don't have to do all of those things in an integrated way. 28:49.120 --> 28:58.240 I can buy my access network service from, for example, AT&T, and I can buy my voice originating service from Vonage, for example. 28:59.220 --> 29:02.180 We have to accommodate that in the 911 system. 29:02.180 --> 29:07.960 We have to be able to deal with the fact that your carrier is no longer just the phone company. 29:07.960 --> 29:09.500 It may be somebody else. 29:09.540 --> 29:21.160 Historically, we have not done a good job of that because we've just bolted stuff on to the 911 systems over the years and we haven't really integrated a lot of these new technologies into the way the system works. 29:21.820 --> 29:24.680 So your device goes to the access network provider. 29:24.680 --> 29:26.140 Well, okay, why? 29:26.200 --> 29:29.800 Well, the infrastructure provider, they know where their wires go. 29:29.800 --> 29:32.440 They know where their cell towers are. 29:32.440 --> 29:41.620 They're the ones who have the sort of intimate, real-world, physical connection with you that can be used to start that process of localizing the call. 29:41.620 --> 29:45.960 So your device goes and queries their location information server. 29:46.480 --> 29:50.680 It gets back, currently, actually location by value. 29:50.680 --> 30:02.920 It gets sort of your here, generally, although we're trying to be very careful about giving that to devices because we can see a state where you might have malware on the device and you don't necessarily want to disclose location to that. 30:02.920 --> 30:14.840 So we're working on some cryptographic stuff to try and keep that private as well, to basically tokenize it, so that then the device can pass either that location value or that token to something called an emergency services routing proxy. 30:15.040 --> 30:30.500 And the purpose there is for the proxy to say to a big thing called a forest guide, which is basically a hierarchical database structure that tells you here are where all the countries in the world, what are their boundaries within those, what are the states within those, 30:30.500 --> 30:39.040 what are the counties within those, what are the 911 center service areas, and oh, by the way, you're there, great, you go to this 911 center. 30:39.040 --> 30:40.580 That's where your call should go. 30:41.060 --> 30:45.800 So this involves a lot of GIS processing. 30:45.920 --> 30:47.640 That's geospatial information system. 30:47.640 --> 30:50.840 I think I have a slide here that actually shows some of that. 30:50.840 --> 30:54.360 So we actually have a standard for geospatial information systems. 30:54.940 --> 31:04.900 Remember I talked about that old school way of doing the database of addresses where you have a list of street names, a table of street names, and a table of valid number ranges? 31:05.140 --> 31:11.660 That's all well and good if you only need to locate people in like row houses, but what if you have an apartment building? 31:11.660 --> 31:13.840 How do we know that a floor number is valid? 31:13.840 --> 31:16.180 How do we know that a room number is valid? 31:16.180 --> 31:22.580 And moreover, how do we decide where do all of those 911 calls within that thing go? 31:22.580 --> 31:31.740 For example, if I'm Caesars Palace, I might have my own, I might be a limited municipality, I might have my own response center that can get you help faster. 31:31.740 --> 31:35.900 We might want to route all of the calls within Caesars Palace to them instead. 31:37.240 --> 31:38.680 Disney World is a great example of that. 31:38.680 --> 31:40.860 They actually have the Reedy Creek Improvement District. 31:40.860 --> 31:44.700 There are like six Disney executives that have houses like on the property. 31:44.700 --> 31:49.960 They're the entire voting block for the whole city of Reedy Creek, and they actually have their own 911 center. 31:49.960 --> 31:51.520 It's like a best practice place. 31:51.520 --> 31:52.500 Everybody loves to hold it up. 31:52.500 --> 31:54.480 It's like shiny and new and a good place to go. 31:54.720 --> 32:04.820 But you have to be able to track those things so that you can do change management, so that you can know when somebody puts up a new building. 32:04.820 --> 32:07.220 How do we add that to our addressing system? 32:07.840 --> 32:20.940 And then once you've consulted the forest guide, it'll give you an IP address for something called the border control function of the NG911 system, next generation 911 system, that actually serves that particular location. 32:20.940 --> 32:34.080 At that point, the routing proxy, whether it's in your access network provider's network or if it's disaggregated in the originating service provider's network, will actually send signaling and media to that border control function. 32:34.080 --> 32:53.960 To me, the coolest part of all this is if at some point during the call things change and there's some reason, your location changes or whatnot, and there's some reason to redirect the call either before the setup is complete or during the call, there's actually an intelligent mechanism to say, 32:53.960 --> 32:58.340 hey, there's this other 911 center that might need to be involved in this response. 32:58.340 --> 33:01.860 Do you telecommunicator handling the call want to loop them in? 33:01.860 --> 33:04.340 Even if it's on a listen-only basis. 33:04.580 --> 33:05.920 And you can do that. 33:06.020 --> 33:17.060 And you also get another kind of cool capability is you can have now specialized 911 centers that deal just with particular populations that have very specific needs. 33:17.060 --> 33:24.240 So, for example, in Washington, D.C., we have one of the largest universities for the deaf and hard of hearing, Gallaudet. 33:24.380 --> 33:25.260 Great school. 33:25.260 --> 33:28.660 They actually do a lot of cool engineering work related to 911 stuff. 33:28.660 --> 33:43.020 But if you have a 911 call that's coming from just the area of the Gallaudet campus, you might want to put that into a different queue for someone who has a hot connection with an ASL interpreter or knows ASL themselves and can handle that video call that way, 33:43.020 --> 33:47.460 or who's trained specially to handle real-time text calls. 33:47.460 --> 33:55.780 And that's something in today's environment we absolutely can't do because, remember back, we're routing everything based on that cell tower and the sector. 33:55.780 --> 33:57.900 At the beginning of the call, that's all we know. 33:57.900 --> 34:05.000 In the future, the idea is we're going to route based on the actual X, Y, and hopefully Z someday from the device. 34:05.000 --> 34:09.980 And that makes it a lot easier to do much more granular things like that that can really help. 34:09.980 --> 34:11.080 It has a huge impact. 34:11.080 --> 34:21.280 If you're in a population that has a specific need like that, it's a really big deal to be able to get to something like that on the first try. 34:21.280 --> 34:32.660 Because today, one of the terrible things that happens is if you need to connect with somebody like a video interpreter, that can delay your 911 call on the order of 15 to 30 minutes. 34:32.820 --> 34:36.080 And that is not an amount of time you want to be waiting in an emergency. 34:37.360 --> 34:38.860 I've used about 40 minutes here. 34:38.860 --> 34:41.760 I haven't had anybody volunteer questions, so I just want to level set. 34:41.760 --> 34:51.100 Are there things that I've covered in insufficient depth or not covered or other things you want to hear about so that I can kind of tune the rest of the talk? 34:51.100 --> 34:51.640 Yep. 35:05.910 --> 35:06.910 Oh, it's funny. 35:06.910 --> 35:08.750 You think there's IP switching involved in this. 35:08.750 --> 35:10.270 That's very quaint. 35:10.270 --> 35:20.850 So the question was, when I said that location data is transmitted in the clear, what part of the sort of transactional structure was I talking about? 35:20.850 --> 35:27.710 So from the device to the network, it is encrypted at the level of whatever the bearer established. 35:27.710 --> 35:30.430 So in LTE, it would be encrypted. 35:30.430 --> 35:32.910 In GSM, it would be encrypted probably weekly. 35:32.910 --> 35:34.930 Same thing in CDMA. 35:35.410 --> 35:40.910 Within the carrier network, it will be segregated but not necessarily encrypted. 35:41.150 --> 35:45.670 And then the way it's... I know this is why I laughed about the whole IP switching thing. 35:45.670 --> 35:58.050 The way it's actually transmitted within the telephone company networks is as a series of either medium frequency tones or maybe DTMF in some cases. 35:58.050 --> 36:02.970 It's really kind of hilarious how some of this stuff still actually works. 36:03.190 --> 36:17.390 The data block we get with a 911 call, I think I said this in my talk the other day but it bears repeating, is 512 maximum, 512 non-extended ASCII character set letters and digits. 36:17.850 --> 36:18.850 And that's all. 36:18.850 --> 36:25.850 So when you want to represent something like a physical location, that's all you've got to work with. 36:25.850 --> 36:29.110 And so we've really had to figure out, okay, how do we dumb this stuff down? 36:29.110 --> 36:39.710 One of the big things that we're looking forward to is once we have these next-gen systems where we can protect it properly, encrypt it, and it is an IP system, is actually starting to be able to represent things graphically. 36:39.710 --> 36:46.010 I think I showed... here's an example of an uncertainty around a floor, for example. 36:46.770 --> 36:48.170 Today, we couldn't do that. 36:48.170 --> 37:02.130 We couldn't pull up a visualization of a building and put circles or ellipsoids or spheres or other things in there and say, look in this general area because we have no way of representing that in the 911 systems that we have. 37:02.130 --> 37:12.390 Now, the cool thing is, the carrier standard that makes all of this work at kind of the numerical level is something called J standard 036, I think it's an ATIS slash TIA standard. 37:12.410 --> 37:17.750 It actually defines the ability to send different geometric shapes. 37:17.750 --> 37:21.030 So I can send an ellipsoid point with uncertainty. 37:21.070 --> 37:24.030 I can send a point with spherical uncertainty. 37:24.030 --> 37:28.430 I can start to do annular segment, things like that. 37:28.430 --> 37:31.650 Nobody does that because, again, we don't have any way to represent it today. 37:44.080 --> 37:51.000 So the question was, what percentage when it comes to dispatch is sent in the clear versus encrypted or perhaps digital? 37:51.000 --> 37:56.660 I assume you mean... and I assume you mean the radio part. 37:56.660 --> 38:01.800 Okay, so the radio part of dispatch, how much of it is encrypted, how much of it is in the clear? 38:02.600 --> 38:04.140 Overwhelmingly, it's in the clear. 38:04.200 --> 38:09.200 There are places that are starting to do more encrypted communications. 38:11.320 --> 38:13.260 Badly, in most cases. 38:13.300 --> 38:21.460 If you look, Matt Blaze, Travis Goodspeed and some folks did an analysis a few years back of one, like, the dominant public safety radio standard in the U.S. 38:21.760 --> 38:24.500 and found that it was basically hopelessly insecure. 38:24.500 --> 38:35.760 They used a really weak, kind of, even more broken version of RC4 as the stream cipher in some commercial implementations that were very cheap. 38:35.860 --> 38:40.900 And so everybody used those, even though they weren't terribly interoperable and they're not at all secure. 38:40.900 --> 38:42.980 So we're in the process of trying to fix that. 38:42.980 --> 39:01.680 Earlier this year, the Department of Homeland Security and NIST worked together to get a requirement into the standard so that, I think, starting in 2018, going forward, all radios built to that standard will now have to have AES-256 as a mandatory part of their cipher suite. 39:01.680 --> 39:07.120 They can still have broken versions of RC4, but AES-256 has to be in there as well. 39:07.120 --> 39:11.820 And part of the reason for that is, in the public safety community, interoperability is a huge deal. 39:11.820 --> 39:15.600 Disasters may start local, but they usually don't stay local. 39:15.900 --> 39:18.540 And when they go beyond the, you know... 39:18.540 --> 39:23.220 Disasters don't obey jurisdictional lines, no matter how much we admonish them. 39:23.220 --> 39:28.380 And so eventually you've got to have help from your neighbor, and when that happens, being able to talk with them is a big deal. 39:29.120 --> 39:32.380 The other thing... I appreciate that question about encryption. 39:32.620 --> 39:38.900 The other thing that I want to raise a serious point about, though, is authentication and integrity checking. 39:38.900 --> 39:52.840 Because even though we are fixing the encryption problem, sort of, we're getting to a standard, we are still not doing anything about protecting radio networks from bad devices. 39:52.840 --> 39:55.140 So devices that don't belong there. 39:55.140 --> 40:06.680 So most of the radio networks today, if you know an 8-digit code that is really easy to pull off the air, you can get a radio attached to that network and start receiving traffic from it. 40:06.680 --> 40:08.640 It's not authenticated in any way. 40:08.640 --> 40:12.160 And then there are also vulnerabilities to replay attacks in these networks. 40:12.160 --> 40:16.280 So you don't have good integrity mechanisms either. 40:16.340 --> 40:17.880 So we know that's a problem. 40:17.880 --> 40:19.200 It's something we're working on. 40:19.200 --> 40:27.560 The trouble is, these are tens of million dollar networks that turn over once every 15 to 20 years. 40:27.680 --> 40:30.420 And the next iteration may just not happen. 40:30.420 --> 40:35.700 Because they're actually building an LTE network right now for first responders that's going to be nationwide. 40:35.700 --> 40:43.680 So there's a big debate about, well, do we even keep working on these standards, because at some point we're just going to use that, because it'll be better. 40:44.180 --> 40:46.240 Not necessarily soon, but someday. 40:48.320 --> 40:49.560 Other questions? 41:09.880 --> 41:14.900 So the question was, when you make a 911 call, location stuff turns on. 41:14.940 --> 41:22.580 Does the data that's developed as a result of that get stored on the phone in a way that it could be recovered by forensic analysis, the cops down the line or something? 41:22.580 --> 41:26.260 I don't know a really good answer to that question. 41:26.320 --> 41:31.280 The challenge is, there are so many parties involved. 41:31.280 --> 41:35.080 Because there are legal obligations and interests that the carriers have. 41:35.080 --> 41:41.180 There are very different legal obligations and interests that the handset manufacturer has. 41:41.180 --> 41:50.820 And even the chipset manufacturer, the folks who are putting those measurement devices, how those interface with the 911 aspect of the device can vary. 41:50.820 --> 41:53.000 So I don't know the answer to that, unfortunately. 41:53.080 --> 41:58.020 My hope would be that once the 911 call goes away, that that location data goes away as well. 41:58.040 --> 42:10.160 In part because in the 911 business, one of our big concerns is always, well, can we adequately protect the safety of someone who calls 911, but doesn't want a third party to know that they have. 42:10.180 --> 42:19.580 One tactic that we see, particularly in an abused spouse situation all the time, is somebody calling 911 and pretending to order pizza. 42:20.120 --> 42:31.740 And when they do that, most clever telecommunicators and dispatchers will say, you're telling me that you need to order a pizza because you wanted to call 911 and you don't want someone else to know, is that right? 42:31.740 --> 42:33.620 Yes, pepperoni. 42:34.060 --> 42:43.180 And that's the kind of thing where we don't want somebody to be able to look at the device and say, oh, you called 911 from the house, where you know you're not supposed to call anybody. 42:43.180 --> 42:48.780 That would be a potential information disclosure that would not be good. 42:49.200 --> 42:51.120 There's a question right there. 42:51.380 --> 42:54.840 Could you come up to the mic so that we can get this on the recording? 42:58.700 --> 42:59.660 Okay, 43:09.580 --> 43:18.060 the question was, can the location information that is collected be used to prevent things like, for example, swatting? 43:18.060 --> 43:23.460 I promise I did not pay him to ask that question, but that is like the best possible question you could ask. 43:24.400 --> 43:28.860 It is something that we have been looking at for a very long time. 43:28.860 --> 43:30.980 The answer is yes, absolutely. 43:31.040 --> 43:33.700 It should be used that way every time. 43:34.320 --> 43:42.720 I go through no end of amazement that people don't always check mismatches like that when there is a call. 43:42.740 --> 43:50.520 I do think one of the benefits of, frankly, having humans in the loop for 911 calls, is that rather cleverly a lot of the time they do say that. 43:50.520 --> 44:00.160 They'll say to somebody, look, before you go full swat on Brian Krebs again, maybe let's make sure that this call is actually coming from there. 44:00.160 --> 44:14.780 And the other thing that we've been able to train on is, when you get a call from a non-service initialized device, so a cell phone that doesn't have service, which is required to still be able to make a 911 call, treat that as suspect until you have really, 44:14.780 --> 44:19.340 really good information linking it to that person's thing. 44:19.340 --> 44:28.580 Now part of the challenge is, if you're too far away from the target of a swatting attack in the first place, your call's not going to go to the right 911 center anyway. 44:28.780 --> 44:31.620 And then you're going to raise a whole host of other questions. 44:31.620 --> 44:46.800 Like, well, if your call ended up in Boca Raton, but you're calling from Denver, then there's something, clearly something has happened that we don't expect and that we ought to be asking more questions about. 44:47.360 --> 44:49.440 So great, great question, really appreciate that. 44:49.440 --> 44:56.020 And in NG911, one of the things we're going to do is a lot more data analytics capabilities to make sure we're authenticating things like that. 44:56.020 --> 45:11.840 In fact, as I talked about, like the device-based hybrid and the National Emergency Address Database and all that, when we were negotiating those new rules with the wireless carriers and the FCC, that was one of our key concerns was if they get a Wi-Fi hotspot, 45:11.840 --> 45:29.260 for example, out of the database and it says this hotspot is here, let's say Caesars Palace in Las Vegas, but the call came in from a cell tower that was in Knoxville, Tennessee, okay, Houston, we have a problem, don't use that location data. 45:29.260 --> 45:32.640 Fall back, use the tower, use the GPS, whatever else you've got. 45:32.640 --> 45:38.560 So location data that comes from the database process has to be corroborated going forward. 45:38.560 --> 45:43.640 That was a big deal for us from an integrity standpoint to make sure that we had corroboration. 45:44.500 --> 45:45.520 Yep, in the back. 45:50.900 --> 45:53.500 The question was, is there a 911 app? 45:53.500 --> 45:54.580 Let me be really clear. 45:54.580 --> 45:57.960 No, there is not a 911 app. 45:59.000 --> 46:08.800 If I could get Apple and Google to do one thing, it would be to just grep the entire app store, the entire Play Store, and delete anything that involves the words 911. 46:08.800 --> 46:10.760 They don't work. 46:10.760 --> 46:12.280 They're totally bogus. 46:12.280 --> 46:22.680 There's all kinds of things, and I hate to be this passionate and upset about it, because I love that there are developers out there trying to do helpful things for people in an emergency. 46:23.280 --> 46:38.240 But the thing that none of the developers, with maybe one exception, who have ever attacked this problem have understood is just how much legacy cruft there is that stands between anything you can do with an app and the 911 system. 46:38.240 --> 46:40.740 It just doesn't work. 46:41.000 --> 46:51.060 The only, there's been one startup that sort of kind of halfway cracked the problem, and they literally had to go and build millions of dollars of infrastructure. 46:51.060 --> 46:59.900 They built their own NG911 system to just do an end run around the whole thing, and then ultimately find some carrier partner to trunk the calls out to PSAPs. 47:00.940 --> 47:05.720 No, there is no app that works with 911, and there won't be. 47:05.960 --> 47:09.360 There are very good reasons that you should not do that. 47:09.580 --> 47:13.420 Again, I appreciate people's passion, but it just doesn't work. 47:13.420 --> 47:14.240 Don't. 47:15.740 --> 47:26.060 Unfortunately, there are dozens of apps on both of the major platforms that purport to do something like connect you directly to the nearest police officer. 47:26.060 --> 47:38.800 Well, okay, A, the app provider doesn't know where the nearest police officer is, and B, the only way to connect to that nearest police officer is over a radio platform that I guarantee you that app developer knows nothing about. 47:39.000 --> 47:42.540 And moreover, that police officer does not want your 911 call. 47:42.540 --> 47:44.320 Like, that's not the process. 47:44.540 --> 47:46.760 You know, they've got other stuff going on. 47:46.760 --> 47:58.380 You know, for the third of 911 calls that are like, cat up a tree, or McDonald's got my order wrong, or whatever the thing was that went wrong, the nearest cop, the nearest firefighter doesn't want that. 47:58.380 --> 48:01.320 We have these things centralized for a very good reason. 48:01.320 --> 48:05.420 The people that take these calls are an important part of the process, and you can't circumvent that. 48:05.760 --> 48:09.200 So, sorry to be passionate about it, but yeah, no, no app, and won't be. 48:10.480 --> 48:11.500 Down front? 48:15.900 --> 48:17.480 Let's say someone released an Android 48:27.200 --> 48:27.620 9. 48:27.960 --> 48:29.960 Clearly you missed my talk yesterday. 48:31.400 --> 48:32.960 So that actually happened. 48:32.960 --> 48:45.060 So the question was, if we have all this legacy stuff that's very susceptible, and, you know, minimum traffic carrying capacity, what if somebody has some malware that gets on a major platform, and then starts calling 911 repeatedly? 48:45.400 --> 48:52.540 What I will do is point you to the DEF CON media server, because once that talk goes up, you can get 45 minutes of a great answer to that question. 48:52.640 --> 48:54.300 In the back. 49:02.210 --> 49:04.850 The question is, what about the integration with SS7? 49:05.590 --> 49:11.390 The regrettable reality is, SS7 is going to be with us for some period of time. 49:11.390 --> 49:15.610 For most 911 systems, SS7 would be an upgrade. 49:15.610 --> 49:17.830 Because they're still using MF and Cama. 49:18.690 --> 49:24.010 Yes, yes, that is exactly the look you should have when I say they're still using MF and Cama, but they are. 49:24.010 --> 49:25.450 That's how they're signaling things. 49:25.450 --> 49:27.090 They're not using SS7. 49:28.050 --> 49:31.410 The ultimate goal is to bypass that completely. 49:31.410 --> 49:40.610 We'll still have to have SS7 interfaces for carrier networks that hang around, because signaling system 7 is going to be with us for some period of time. 49:40.610 --> 49:45.230 But next generation 911 is designed to start getting rid of that, get it out of the system as quickly as we can. 49:46.090 --> 49:48.990 I think we've got time for maybe one or two more questions. 49:53.130 --> 49:55.590 Okay, I'll be hanging around in the hallway then. 49:55.590 --> 49:59.490 Thank you all very much for coming to the talk, and great getting to chat with you. 49:59.490 --> 49:59.930 Take care.