[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:17.840]  He's part of the 911 Association. This talk is being recorded to show it online later on, so if anyone has any questions,
[00:17.840 --> 00:23.320]  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:40.400]  And I will say for my part, I very much want to make this talk a lot less formal and a lot more interactive
[00:40.400 --> 00:43.260]  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.660]  I'm being told I can't be heard, so let me... I'm just going to hold this. How about that?
[01:03.660 --> 01:05.360]  Everybody hear me now? 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:30.580]  In fact, you would almost be appalled at how little location data we do get when we want to find you,
[01:30.580 --> 01:32.240]  which is when you call 911.
[01:32.320 --> 01:37.040]  So my talk is going to go over a little bit about what we do get, when we get it,
[01:37.040 --> 01:45.940]  how we are actually part of the privacy solution by virtue of keeping people who want access to location data
[01:45.940 --> 01:48.200]  away from it when they shouldn't have it,
[01:48.200 --> 01:56.940]  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:19.060]  So basically, a few thousand miles up, we have a constellation of 30-odd satellites orbiting the Earth,
[02:19.060 --> 02:20.980]  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:32.080]  And by singing the same song inside a receiver, essentially,
[02:32.080 --> 02:38.860]  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:48.900]  So we multiply that by the speed of light, correct for things like the diffraction of the ionosphere
[02:48.900 --> 02:54.540]  that delays these signals, and then once we have ranging from multiple satellites,
[02:54.540 --> 02:59.120]  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:12.940]  If you have a really good device with a great antenna and, you know, a multi-band receiver,
[03:12.940 --> 03:15.220]  and you leave it stationary for a very long time,
[03:15.220 --> 03:19.980]  you can get that down to like a tenth of a meter reliably, or better.
[03:20.020 --> 03:24.560]  But for this typical case of something that's cheap enough to put in a smartphone,
[03:24.560 --> 03:26.940]  and for us to carry around with us every day,
[03:26.940 --> 03:30.780]  and, you know, doesn't have a gigantic antenna sticking out the end of it,
[03:30.780 --> 03:34.660]  that's not really the reality. You're not going to get anything nearly that close.
[03:35.220 --> 03:40.780]  So, historically, we've had this problem of we need to find people when they call 911,
[03:40.780 --> 03:41.760]  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:54.020]  And when you established phone service, we could go to them and say,
[03:54.020 --> 03:59.240]  look, for every address that you put in your database, you have to validate that with somebody.
[03:59.240 --> 04:02.800]  It's something called the Master Street Address Guide for your locality,
[04:02.800 --> 04:06.480]  which is a table that contains all of the valid street names
[04:06.940 --> 04:11.200]  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:18.460]  If it wasn't, they had to go back to you and say, hey, it looks like your street doesn't exist,
[04:18.460 --> 04:21.160]  or potentially your number's out of the range.
[04:21.160 --> 04:22.960]  Like, what happened? 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:27.500]  But there was a process. We knew where everything was.
[04:27.620 --> 04:29.720]  Smartphones aren't like that. 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 --> 04:52.280]  In the network-based model, devices in the network either transmitted or received signals
[04:52.780 --> 04:59.600]  to or from a device and used information like angle of arrival, time difference of arrival,
[04:59.600 --> 05:06.760]  or absolute timing offsets to calculate ranging and bearing data and figure out where the device was.
[05:06.760 --> 05:08.620]  And that worked. 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:18.380]  With those sorts of methods, you can get within 200 to 300 meters very quickly,
[05:18.380 --> 05:22.100]  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:31.300]  So that was the typical technology in CDMA, or excuse me, in GSM networks,
[05:31.300 --> 05:34.500]  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:40.900]  CDMA had, at the time, a really cool advantage,
[05:40.900 --> 05:44.820]  which is when I talked about the way GPS satellites sing little songs,
[05:44.820 --> 05:48.180]  they're actually doing that in kind of a version of CDMA.
[05:48.200 --> 05:51.220]  All the satellites transmit on the same frequency,
[05:51.220 --> 05:56.200]  but they do it with different pseudo-random number sequences imposed over that,
[05:56.200 --> 06:00.260]  and you can pick individual satellites out by knowing which one of those are,
[06:00.260 --> 06:04.200]  looking up in an almanac, okay, what satellites should I be able to see,
[06:04.200 --> 06:06.480]  getting that from the constellation itself even,
[06:06.480 --> 06:09.760]  and using that data to figure out, okay, what should I listen for?
[06:09.760 --> 06:12.980]  Since CDMA handsets already had correlators inside
[06:12.980 --> 06:15.800]  that could do that for the networks they were attached to,
[06:15.800 --> 06:19.460]  someone had the bright idea, well, let's just reuse that as a GPS receiver.
[06:19.460 --> 06:20.760]  And it worked. It worked brilliantly.
[06:20.760 --> 06:23.440]  Now, the trouble was, early on, there was only one,
[06:23.440 --> 06:27.920]  because they only expected you to be carrying on one voice conversation at a time,
[06:27.920 --> 06:32.920]  so when, in the early days, they wanted to figure out where you were for 911 purposes,
[06:32.920 --> 06:37.120]  they actually had to say, hold on a second, you're going to hear silence
[06:37.600 --> 06:40.600]  while I determine your location, and then they would trigger,
[06:40.600 --> 06:44.180]  the 911 center would trigger something in the carrier network
[06:44.180 --> 06:46.540]  to actually start that process with your device.
[06:46.540 --> 06:50.080]  The device would listen for the satellites, collect the data, correlate it,
[06:50.080 --> 06:52.600]  ship it off to the network, the network would calculate your position
[06:52.600 --> 06:55.960]  and relay it via a database to the 911 center.
[06:56.000 --> 06:59.320]  Really kludgy, and you don't want to tell somebody in the midst of an emergency,
[06:59.320 --> 07:02.220]  please hold, right? That's not a great thing to tell someone
[07:02.220 --> 07:04.000]  when they're, like, screaming to death.
[07:05.500 --> 07:09.360]  So, over time, we got better, we got better chips with more correlators,
[07:09.360 --> 07:12.760]  we got to the point that we could actually put GPS chips in almost every phone,
[07:12.760 --> 07:14.600]  and these days, that's what everybody does.
[07:14.600 --> 07:18.580]  We have GPS chips. Most of the network technologies have sort of gone away.
[07:18.580 --> 07:22.600]  We still have two out there called Advanced Forward Link Trilateration,
[07:22.600 --> 07:27.100]  which is a ranging technology used mostly in CDMA networks,
[07:27.100 --> 07:32.500]  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:49.980]  You just listen for the time differences between transmissions of synchronized towers,
[07:49.980 --> 07:53.640]  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:14.540]  We don't want that stuff running all the time,
[08:14.540 --> 08:16.340]  because frankly we don't have anything to do with the data,
[08:16.340 --> 08:18.460]  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:24.680]  You don't want that going on, obviously for privacy reasons,
[08:24.680 --> 08:27.020]  otherwise you wouldn't be in the crypto privacy village,
[08:27.020 --> 08:30.520]  and you also don't want it going on because it's a very battery intensive activity
[08:30.880 --> 08:33.460]  to keep track of yourself precisely all the time.
[08:33.460 --> 08:37.680]  In fact, most of the things that you see, you know, this question,
[08:37.680 --> 08:41.480]  why is it that Uber can find me, but 911 can't, that we hear so often,
[08:41.480 --> 08:45.860]  I really hate this question, because like most of the time, Uber is not,
[08:45.860 --> 08:49.640]  Uber doesn't, hasn't measured where you are to any degree of certainty.
[08:49.640 --> 08:54.760]  They have software in your device platform and in their platform
[08:54.760 --> 08:57.300]  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:09.860]  There's some uncertainty associated with that location fix,
[09:09.860 --> 09:13.840]  and often in the case of commercial apps on smartphones,
[09:13.840 --> 09:16.060]  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:25.240]  That's calculated at about a 90% confidence level most of the time,
[09:25.240 --> 09:30.160]  which we want, we want only about a 10% margin that will find you outside the circle.
[09:30.160 --> 09:33.160]  But if you think about a place like Caesar's Palace,
[09:33.760 --> 09:39.640]  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:46.480]  200 meters might put me in any one of three different hotel towers,
[09:46.480 --> 09:49.740]  the casino, the conference center, and a bunch of restaurants.
[09:49.740 --> 09:53.540]  So you really have to deal with constraining that uncertainty somehow
[09:53.540 --> 09:56.640]  before you can use that for emergency response.
[09:56.640 --> 10:00.680]  Uber can make those guesses because it has that ability to then ask you,
[10:00.680 --> 10:03.060]  okay, where are you? 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:24.920]  Historically, only stuff that was baked into the baseband or the network
[10:24.920 --> 10:26.980]  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:36.600]  But we're starting to be able to use Wi-Fi and Bluetooth
[10:36.600 --> 10:40.260]  both to do sort of associative location to say,
[10:40.260 --> 10:45.620]  look, we know that Trey's Wi-Fi access point is at this particular address in this town
[10:45.620 --> 10:49.580]  because he's there all the time and he's associated with that and so on.
[10:49.580 --> 10:53.520]  So if the phone can see Trey's Wi-Fi access point,
[10:53.520 --> 11:00.200]  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:09.020]  We want to be able to say to the cops and firefighters in the field
[11:09.020 --> 11:11.520]  who really couldn't find their way out of the building without our help
[11:11.520 --> 11:16.020]  that this is exactly where to go.
[11:16.020 --> 11:20.500]  But that's not realistic. That's just not the way the physics of measurement work.
[11:20.500 --> 11:25.460]  And that's why the other thing that we're looking at, Bluetooth beacons,
[11:25.460 --> 11:30.760]  you put Bluetooth low energy in a light bulb for lots of really great reasons.
[11:30.760 --> 11:35.740]  One of the things you can do with that is associate that UUID,
[11:35.740 --> 11:39.800]  that Bluetooth beacon ID, with that location in a database.
[11:39.800 --> 11:43.020]  We're working on something called the National Emergency Address Database,
[11:43.020 --> 11:49.380]  which will actually associate Wi-Fi max and Bluetooth UUIDs with physical locations in the world
[11:49.380 --> 11:54.780]  so that if, for example, there's a beacon in this particular ballroom,
[11:54.780 --> 11:58.200]  I can be localized, if I'm within 10 to 30 meters of that,
[11:58.200 --> 12:01.860]  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:11.800]  But then it also means we've got to track those things and make sure that if they move,
[12:11.800 --> 12:15.480]  we find out about it, that there's some aging in the database to make sure
[12:15.480 --> 12:20.140]  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:32.060]  First off, your platform, your phone platform, whether it's Android, iOS, Blackberry, whatever,
[12:32.060 --> 12:34.380]  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:45.780]  Historically, that's only meant like the GPS chip and not some of the other cool things
[12:45.780 --> 12:49.480]  that you have in there like the accelerometers, gyroscopes, magnetometers, barometers,
[12:49.480 --> 12:52.280]  Wi-Fi, Bluetooth, et cetera, but we're working to change that.
[12:52.280 --> 12:55.420]  We're actually working to get to the point where we can ingest data
[12:55.420 --> 13:01.160]  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:15.260]  So GNSS, GPS, Galileo, Glonass, Compass, Baidu, all of those things work phenomenally well
[13:15.800 --> 13:23.040]  outdoors in urban and suburban environments and even to some extent in sort of urban clusters,
[13:23.040 --> 13:27.820]  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:35.480]  But Wi-Fi and Bluetooth things have much higher densities in those environments
[13:35.480 --> 13:37.580]  and consequently they are of more use.
[13:37.580 --> 13:40.320]  And so this is the concept behind device-based hybrid is
[13:40.320 --> 13:44.860]  we're going to opportunistically use what is best in the environment that it's in.
[13:44.860 --> 13:48.860]  So if you're in Manhattan and the best thing we have to figure out where you are
[13:48.860 --> 13:50.680]  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:05.840]  We've had one company called Rapid SOS that built some really cool stuff
[14:05.840 --> 14:12.960]  to kind of get location data around the database limitations of the legacy 911 network.
[14:12.960 --> 14:18.020]  And in doing that, they've kind of proven out that you can, you can get a lot more calls
[14:18.020 --> 14:24.360]  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:33.260]  Google just announced a few months back that they're going to be doing a lot more
[14:33.260 --> 14:38.340]  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:43.860]  They're putting dual frequency GPS receivers in their devices,
[14:43.860 --> 14:48.740]  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:56.700]  So in 3 to 4 years, your handset GPS locations,
[14:56.700 --> 14:59.240]  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:23.800]  If you happen to have, I think so,
[15:28.040 --> 15:30.380]  hmm, oh, there we go, we're back.
[15:30.380 --> 15:33.220]  If you happen to have a barometer,
[15:33.220 --> 15:37.260]  and you have a good external reference for what sea level pressure is,
[15:37.260 --> 15:40.120]  you can use those measurements, you can compare them and say,
[15:40.120 --> 15:43.980]  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 --> 15:50.880]  And so, you know, another example, this company, NexNav,
[15:50.880 --> 15:55.240]  their idea is to put sort of pseudolites or fake GPS satellites
[15:55.240 --> 16:00.300]  on cell towers in buildings and broadcast basically their own GPS signal
[16:00.300 --> 16:05.360]  down at 900 megahertz where it penetrates deep into buildings.
[16:05.360 --> 16:08.840]  And to broadcast as part of that hyperlocal barometric pressure corrections
[16:08.840 --> 16:14.840]  that let them pull up exactly the height that you are at
[16:14.840 --> 16:17.200]  with a great deal of reliability.
[16:17.200 --> 16:19.900]  Now, what do we know about 900? 900 is the junk band, right?
[16:19.900 --> 16:22.140]  Everything awful is in there, it's completely useless
[16:22.140 --> 16:25.300]  other than wireless meter readers who just sit on top of everything.
[16:25.420 --> 16:30.280]  Except that the one thing that is actually privileged in 900 megahertz
[16:30.280 --> 16:34.240]  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:40.560]  There are other folks who have them for other markets,
[16:40.560 --> 16:44.120]  but this is like a cool thing that you can do in the 900 megahertz band
[16:44.120 --> 16:48.760]  and you actually get interference protection if you do this.
[16:48.760 --> 16:53.000]  So, another cool thing. When you make that 911 call,
[16:53.000 --> 16:55.940]  all of this stuff kicks on and starts saying,
[16:55.940 --> 16:58.240]  okay, now where are you?
[16:58.440 --> 17:02.660]  Initially, when your 911 call arrives at a 911 center,
[17:02.660 --> 17:08.140]  most likely we will not have good location data at the start of the call.
[17:08.140 --> 17:12.380]  What typically happens, and this is something called phase 1 and phase 2,
[17:12.380 --> 17:16.820]  phase 1 location is what we get at the beginning of basically every wireless call
[17:16.820 --> 17:23.880]  and it just tells us the street address of the cell tower that you're attached to
[17:24.800 --> 17:27.420]  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:50.980]  And so by knowing that kind of general bearing and then asking you questions,
[17:50.980 --> 17:54.360]  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:02.600]  It actually happens because of a database process that got started in the 1980s
[18:02.600 --> 18:04.920]  built for the wireline world.
[18:04.920 --> 18:09.060]  And that's why before we can get your more precise location,
[18:09.060 --> 18:12.080]  we have to wait a period of time for a couple of processes to happen.
[18:12.080 --> 18:16.160]  So, first of all, the device has to actually calculate a fix
[18:16.160 --> 18:22.300]  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:35.720]  They have to further process it and implant it into the database
[18:35.720 --> 18:40.560]  that ultimately your local telephone company typically maintains
[18:40.560 --> 18:46.340]  because it was the one that they maintained for that wireline process oh so long ago.
[18:47.200 --> 18:51.720]  Then, at that point, the 911 center system either automatically or manually
[18:51.720 --> 18:56.640]  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:14.760]  Ultimately, those are going to get down to 50 meters horizontally
[19:14.760 --> 19:18.260]  and some number vertically that we don't know exactly what it will be yet,
[19:18.260 --> 19:21.540]  but we're working on that. 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:33.900]  Now, the one sort of worrisome part about this is those values, those location values,
[19:33.900 --> 19:37.340]  we know they're very sensitive. Those are actually transmitted in the clear.
[19:37.340 --> 19:42.640]  But they're transmitted in the clear only within trusted carrier networks
[19:42.640 --> 19:45.240]  and then only on the network's control plane.
[19:45.240 --> 19:48.440]  So the location information never touches the user data plane
[19:48.440 --> 19:54.400]  until it actually gets down to the 911 center and it is received at the start
[19:54.400 --> 19:57.560]  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:08.060]  We'll keep that, store it, as long as we have to, to provide you with service
[20:08.660 --> 20:14.080]  and to keep the sort of records that 911 centers are legally obliged to keep,
[20:14.080 --> 20:17.900]  whether it's for investigatory purposes or just because the legislature said
[20:17.900 --> 20:21.300]  we want everything to be kept for 90 days or 120 days.
[20:21.300 --> 20:26.180]  Some things may get archived if they look like they're going to be important down the line,
[20:26.180 --> 20:28.120]  but not necessarily everything.
[20:28.120 --> 20:34.100]  We typically want to get rid of non-critical 911 data that's not subject to a litigation hold
[20:34.100 --> 20:38.120]  as quickly as possible. We really just want to get that out of the system.
[20:39.440 --> 20:44.860]  This is where it gets a little interesting because obviously being in public safety,
[20:44.860 --> 20:49.820]  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:04.980]  People in the law enforcement and fire and EMS communities know that when you call 911,
[21:04.980 --> 21:07.060]  we get your location data.
[21:07.300 --> 21:11.320]  And so people not unreasonably often make the assumption that,
[21:11.320 --> 21:14.960]  well, if I need that for some other purpose, the way I should be able to get that
[21:14.960 --> 21:19.060]  is by just going to my friendly neighborhood 911 outfit and saying,
[21:19.060 --> 21:22.980]  hey, help me out with some of that good, good location data, right?
[21:22.980 --> 21:24.820]  And we get those requests all the time.
[21:24.820 --> 21:29.780]  Our members actually get location data requests from law enforcement and fire and EMS
[21:29.780 --> 21:32.900]  often when there's no actual 911 call going.
[21:32.900 --> 21:37.320]  So I said earlier, 911 really is on the front line of protecting user privacy
[21:37.320 --> 21:41.920]  because often the thing we have to do is tell sometimes even the boss no.
[21:41.920 --> 21:46.060]  Because we get 911 data for a purpose. We use it for a purpose.
[21:46.060 --> 21:50.500]  And that's part of user trust in the 911 system is that we're not going to misuse
[21:50.500 --> 21:52.660]  that 911 location data.
[21:53.100 --> 21:56.220]  The other reason that these things happen from time to time
[21:57.440 --> 22:01.540]  is we also have access to a process for exigent circumstances.
[22:01.820 --> 22:05.360]  So if you've ever seen the movie The Call with Halle Berry,
[22:05.360 --> 22:07.880]  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:16.640]  And she really took a lot of time and effort to get in the trenches
[22:16.640 --> 22:20.080]  with real 911 call takers and learn how they do what they do,
[22:20.080 --> 22:21.760]  which was really awesome and cool.
[22:22.160 --> 22:23.600]  Hopefully there will be a sequel.
[22:23.900 --> 22:28.860]  But in that movie, there was this occasion where a young woman was kidnapped
[22:28.860 --> 22:30.680]  and thrown in a trunk.
[22:31.120 --> 22:35.380]  And she made a very, she was only able to make a quick, discreet 911 call
[22:35.380 --> 22:37.900]  to say, you know, help, I'm in the trunk, right?
[22:38.700 --> 22:43.860]  When that happens, we've got to have some process to get some location data
[22:43.860 --> 22:46.200]  when you're not on a 911 call.
[22:46.200 --> 22:48.740]  Now the challenge for us is, as I talked about before,
[22:48.740 --> 22:51.980]  all of the location privacy settings and all of those sensors
[22:51.980 --> 22:57.520]  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:09.540]  And at that point, the best we can do, and I realize this sounds insane in 2017,
[23:09.540 --> 23:16.700]  is fax, yes, fax, a form to the carrier that was serving that 911 call
[23:16.700 --> 23:23.340]  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:38.280]  But it is still a process. It's not an automated kind of thing.
[23:38.280 --> 23:40.620]  It is a very manual process.
[23:40.800 --> 23:43.940]  And then what happens once the carriers, lawyers, and engineers
[23:43.940 --> 23:49.120]  have looked at the form and said, okay, yes, this is a valid accident circumstances request,
[23:49.120 --> 23:53.220]  there really is an ongoing emergency with a threat to life or property,
[23:53.220 --> 23:59.520]  then and only then can they start to do a little bit to help us.
[23:59.520 --> 24:03.360]  But again, you're not in a 911 call. 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:28.500]  So I talked before about, you know, GPS and the way the ranges kind of cross over
[24:28.500 --> 24:30.280]  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:37.400]  So that's a line and an arc and wherever they cross,
[24:37.400 --> 24:42.080]  that's sort of generally where you are because, again, our measurements are kind of fuzzy.
[24:42.180 --> 24:45.640]  That arc can be really wide. 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:09.740]  That's actually something that's done on a, you know, we're on the phone with AT&T, Verizon, Sprint, T-Mobile, somebody,
[25:09.740 --> 25:11.480]  saying, okay, where are they now?
[25:11.760 --> 25:14.000]  Okay, has the location changed? Where are they now?
[25:14.280 --> 25:16.740]  And it's this very sort of iterative manual thing.
[25:16.740 --> 25:23.000]  And eventually, hopefully, you can work out, okay, it's a car that's going down, you know, I-40 or something like that,
[25:23.000 --> 25:27.780]  and say, let's go try to intercept whatever that is and find somebody.
[25:27.780 --> 25:33.060]  And then, of course, immediately after that exigent circumstance passes,
[25:33.060 --> 25:36.760]  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:48.320]  So then you've got to start thinking about, okay, do we get a subpoena? Do we get a warrant?
[25:48.320 --> 25:56.980]  How do we actually acquire that location data in a way that can be used for some criminal prosecutorial purpose
[25:56.980 --> 26:01.660]  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:15.120]  Weirdly, I often hear people say, 112, which is the European emergency number,
[26:15.120 --> 26:20.180]  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:28.440]  It might. 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:49.460]  And I don't think we have a good answer right now,
[26:49.460 --> 26:56.280]  because your average 911 center is not technically sophisticated enough to be encrypting or hashing
[26:56.280 --> 26:59.260]  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:17.180]  So the next piece of this that I want to talk about is how we will acquire and use location information
[27:17.180 --> 27:21.080]  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:32.520]  But now, instead of dealing with legacy wireline databases from the late 70s, early 80s,
[27:32.520 --> 27:36.300]  we're going to take this into a more IP-based realm.
[27:36.300 --> 27:43.380]  So in next-generation 911, when you dial 911 from a phone, whether that's a voice call to 911
[27:43.380 --> 27:47.400]  or a video call or even a text session, we're going to have real-time text very soon.
[27:47.400 --> 27:51.680]  Or total conversation. If you have different accessibility needs,
[27:51.680 --> 27:54.960]  you'll have the ability to communicate in all of those different ways simultaneously,
[27:54.960 --> 27:57.480]  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:19.560]  Historically, when you bought phone service from the phone company,
[28:19.560 --> 28:22.280]  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:27.680]  When you bought voice service from the phone company,
[28:27.680 --> 28:31.420]  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:53.700]  I can buy my access network service from, for example, AT&T,
[28:53.700 --> 28:58.240]  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:11.380]  Historically, we have not done a good job of that
[29:11.380 --> 29:15.220]  because we've just bolted stuff on to the 911 systems over the years
[29:15.220 --> 29:21.160]  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:36.900]  They're the ones who have the sort of intimate, real-world, physical connection with you
[29:36.900 --> 29:41.620]  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 --> 29:53.240]  It gets sort of your here, generally,
[29:53.240 --> 29:56.000]  although we're trying to be very careful about giving that to devices
[29:56.000 --> 30:00.440]  because we can see a state where you might have malware on the device
[30:00.440 --> 30:02.920]  and you don't necessarily want to disclose location to that.
[30:02.920 --> 30:06.180]  So we're working on some cryptographic stuff to try and keep that private as well,
[30:06.180 --> 30:07.440]  to basically tokenize it,
[30:07.440 --> 30:11.580]  so that then the device can pass either that location value or that token
[30:11.580 --> 30:14.840]  to something called an emergency services routing proxy.
[30:15.040 --> 30:20.680]  And the purpose there is for the proxy to say to a big thing called a forest guide,
[30:20.680 --> 30:23.440]  which is basically a hierarchical database structure
[30:23.440 --> 30:27.400]  that tells you here are where all the countries in the world,
[30:27.400 --> 30:30.500]  what are their boundaries within those, what are the states within those,
[30:30.500 --> 30:34.760]  what are the counties within those, what are the 911 center service areas,
[30:34.760 --> 30:39.040]  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 --> 30:59.100]  Remember I talked about that old school way of doing the database of addresses
[30:59.100 --> 31:02.820]  where you have a list of street names, a table of street names,
[31:02.820 --> 31:04.900]  and a table of valid number ranges?
[31:05.140 --> 31:09.460]  That's all well and good if you only need to locate people in like row houses,
[31:09.460 --> 31:11.660]  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:28.520]  For example, if I'm Caesars Palace, I might have my own, I might be a limited municipality,
[31:28.520 --> 31:31.740]  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:47.980]  They're the entire voting block for the whole city of Reedy Creek,
[31:47.980 --> 31:49.960]  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:00.260]  But you have to be able to track those things so that you can do change management,
[32:00.260 --> 32:04.820]  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:10.100]  And then once you've consulted the forest guide,
[32:10.100 --> 32:16.340]  it'll give you an IP address for something called the border control function of the NG911 system,
[32:16.340 --> 32:20.940]  next generation 911 system, that actually serves that particular location.
[32:20.940 --> 32:26.080]  At that point, the routing proxy, whether it's in your access network provider's network
[32:26.080 --> 32:29.760]  or if it's disaggregated in the originating service provider's network,
[32:29.760 --> 32:34.080]  will actually send signaling and media to that border control function.
[32:34.080 --> 32:41.040]  To me, the coolest part of all this is if at some point during the call things change
[32:41.040 --> 32:45.020]  and there's some reason, your location changes or whatnot,
[32:45.020 --> 32:51.100]  and there's some reason to redirect the call either before the setup is complete or during the call,
[32:51.100 --> 32:53.960]  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:05.920]  Even if it's on a listen-only basis. And you can do that.
[33:06.020 --> 33:12.200]  And you also get another kind of cool capability is you can have now specialized 911 centers
[33:12.200 --> 33:17.060]  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:28.660]  Great school. They actually do a lot of cool engineering work related to 911 stuff.
[33:28.660 --> 33:33.760]  But if you have a 911 call that's coming from just the area of the Gallaudet campus,
[33:33.760 --> 33:39.540]  you might want to put that into a different queue for someone who has a hot connection with an ASL interpreter
[33:39.540 --> 33:43.020]  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:51.440]  And that's something in today's environment we absolutely can't do because, remember back,
[33:51.440 --> 33:55.780]  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:14.460]  It has a huge impact. If you're in a population that has a specific need like that,
[34:14.460 --> 34:21.280]  it's a really big deal to be able to get to something like that on the first try.
[34:21.280 --> 34:25.780]  Because today, one of the terrible things that happens is if you need to connect with somebody
[34:26.340 --> 34:32.660]  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:41.760]  I've used about 40 minutes here. I haven't had anybody volunteer questions, so I just want to level set.
[34:41.760 --> 34:47.980]  Are there things that I've covered in insufficient depth or not covered or other things you want to hear about
[34:47.980 --> 34:51.640]  so that I can kind of tune the rest of the talk? Yep.
[35:05.910 --> 35:10.270]  Oh, it's funny. You think there's IP switching involved in this. That's very quaint.
[35:10.270 --> 35:17.370]  So the question was, when I said that location data is transmitted in the clear,
[35:17.370 --> 35:20.850]  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:32.910]  So in LTE, it would be encrypted. In GSM, it would be encrypted probably weekly.
[35:32.910 --> 35:40.910]  Same thing in CDMA. 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:50.730]  The way it's actually transmitted within the telephone company networks
[35:50.730 --> 35:58.050]  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:08.550]  The data block we get with a 911 call, I think I said this in my talk the other day but it bears repeating,
[36:08.550 --> 36:18.850]  is 512 maximum, 512 non-extended ASCII character set letters and digits. 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:32.650]  One of the big things that we're looking forward to is once we have these next-gen systems
[36:32.650 --> 36:36.870]  where we can protect it properly, encrypt it, and it is an IP system,
[36:36.870 --> 36:39.710]  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:50.390]  Today, we couldn't do that. We couldn't pull up a visualization of a building
[36:50.390 --> 36:55.610]  and put circles or ellipsoids or spheres or other things in there and say,
[36:55.610 --> 37:02.130]  look in this general area because we have no way of representing that in the 911 systems that we have.
[37:02.130 --> 37:07.770]  Now, the cool thing is, the carrier standard that makes all of this work at kind of the numerical level
[37:07.770 --> 37:12.390]  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:24.030]  So I can send an ellipsoid point with uncertainty. 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:09.200]  Overwhelmingly, it's in the clear. There are places that are starting to do more encrypted communications.
[38:11.320 --> 38:17.420]  Badly, in most cases. If you look, Matt Blaze, Travis Goodspeed and some folks did an analysis a few years back
[38:17.420 --> 38:24.500]  of one, like, the dominant public safety radio standard in the U.S. 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:50.120]  So we're in the process of trying to fix that. Earlier this year, the Department of Homeland Security and NIST worked together to get a requirement into the standard
[38:50.120 --> 39:01.680]  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:45.300]  Because even though we are fixing the encryption problem, sort of, we're getting to a standard,
[39:45.300 --> 39:52.840]  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:02.420]  So most of the radio networks today, if you know an 8-digit code that is really easy to pull off the air,
[40:02.420 --> 40:06.680]  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:19.200]  So we know that's a problem. 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:39.920]  So there's a big debate about, well, do we even keep working on these standards,
[40:39.920 --> 40:43.680]  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:20.600]  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,
[41:20.600 --> 41:22.580]  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:46.680]  And even the chipset manufacturer, the folks who are putting those measurement devices,
[41:46.680 --> 41:50.820]  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:02.160]  In part because in the 911 business, one of our big concerns is always,
[42:02.160 --> 42:06.360]  well, can we adequately protect the safety of someone who calls 911,
[42:06.360 --> 42:10.160]  but doesn't want a third party to know that they have.
[42:10.180 --> 42:15.100]  One tactic that we see, particularly in an abused spouse situation all the time,
[42:15.100 --> 42:19.580]  is somebody calling 911 and pretending to order pizza.
[42:20.120 --> 42:25.340]  And when they do that, most clever telecommunicators and dispatchers will say,
[42:25.900 --> 42:29.340]  you're telling me that you need to order a pizza because you wanted to call 911
[42:29.340 --> 42:31.740]  and you don't want someone else to know, is that right?
[42:31.740 --> 42:33.620]  Yes, pepperoni.
[42:34.060 --> 42:38.740]  And that's the kind of thing where we don't want somebody to be able to look at the device and say,
[42:38.740 --> 42:43.180]  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 --> 43:16.560]  Okay, the question was, can the location information that is collected be used to prevent things like,
[43:16.560 --> 43:18.060]  for example, swatting?
[43:18.060 --> 43:21.020]  I promise I did not pay him to ask that question,
[43:21.020 --> 43:23.460]  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:48.000]  I do think one of the benefits of, frankly, having humans in the loop for 911 calls,
[43:48.000 --> 43:50.520]  is that rather cleverly a lot of the time they do say that.
[43:50.520 --> 43:56.180]  They'll say to somebody, look, before you go full swat on Brian Krebs again,
[43:57.080 --> 44:00.160]  maybe let's make sure that this call is actually coming from there.
[44:00.160 --> 44:02.300]  And the other thing that we've been able to train on is,
[44:02.300 --> 44:05.340]  when you get a call from a non-service initialized device,
[44:05.340 --> 44:07.560]  so a cell phone that doesn't have service,
[44:07.560 --> 44:11.280]  which is required to still be able to make a 911 call,
[44:11.280 --> 44:15.820]  treat that as suspect until you have really, really good information
[44:16.820 --> 44:19.340]  linking it to that person's thing.
[44:19.340 --> 44:25.540]  Now part of the challenge is, if you're too far away from the target of a swatting attack in the first place,
[44:25.540 --> 44:28.580]  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:37.820]  Like, well, if your call ended up in Boca Raton, but you're calling from Denver,
[44:39.540 --> 44:44.140]  then there's something, clearly something has happened that we don't expect
[44:44.140 --> 44:46.800]  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:53.280]  And in NG911, one of the things we're going to do is a lot more data analytics capabilities
[44:53.280 --> 44:56.020]  to make sure we're authenticating things like that.
[44:56.020 --> 44:58.760]  In fact, as I talked about, like the device-based hybrid
[44:58.760 --> 45:01.500]  and the National Emergency Address Database and all that,
[45:01.500 --> 45:06.500]  when we were negotiating those new rules with the wireless carriers and the FCC,
[45:06.500 --> 45:12.440]  that was one of our key concerns was if they get a Wi-Fi hotspot, for example,
[45:12.440 --> 45:19.220]  out of the database and it says this hotspot is here, let's say Caesars Palace in Las Vegas,
[45:19.220 --> 45:24.760]  but the call came in from a cell tower that was in Knoxville, Tennessee,
[45:24.760 --> 45:29.260]  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:54.580]  The question was, is there a 911 app? Let me be really clear.
[45:54.580 --> 45:57.960]  No, there is not a 911 app.
[45:59.000 --> 46:04.460]  If I could get Apple and Google to do one thing, it would be to just grep the entire app store,
[46:04.460 --> 46:08.800]  the entire Play Store, and delete anything that involves the words 911.
[46:08.800 --> 46:12.280]  They don't work. They're totally bogus.
[46:12.280 --> 46:17.100]  There's all kinds of things, and I hate to be this passionate and upset about it,
[46:17.100 --> 46:22.680]  because I love that there are developers out there trying to do helpful things for people in an emergency.
[46:23.280 --> 46:27.420]  But the thing that none of the developers, with maybe one exception,
[46:27.420 --> 46:34.020]  who have ever attacked this problem have understood is just how much legacy cruft there is
[46:34.020 --> 46:38.240]  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:46.660]  The only, there's been one startup that sort of kind of halfway cracked the problem,
[46:46.660 --> 46:51.060]  and they literally had to go and build millions of dollars of infrastructure.
[46:51.060 --> 46:55.680]  They built their own NG911 system to just do an end run around the whole thing,
[46:55.680 --> 46:59.900]  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:14.240]  Again, I appreciate people's passion, but it just doesn't work. Don't.
[47:15.740 --> 47:20.800]  Unfortunately, there are dozens of apps on both of the major platforms
[47:20.800 --> 47:26.060]  that purport to do something like connect you directly to the nearest police officer.
[47:26.060 --> 47:31.320]  Well, okay, A, the app provider doesn't know where the nearest police officer is,
[47:31.320 --> 47:35.240]  and B, the only way to connect to that nearest police officer is over a radio platform
[47:35.240 --> 47:38.800]  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:46.760]  Like, that's not the process. You know, they've got other stuff going on.
[47:46.760 --> 47:50.260]  You know, for the third of 911 calls that are like, cat up a tree,
[47:50.260 --> 47:55.760]  or McDonald's got my order wrong, or whatever the thing was that went wrong,
[47:55.760 --> 47:58.380]  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:03.860]  The people that take these calls are an important part of the process,
[48:03.860 --> 48:05.420]  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:27.620]  Let's say someone released an Android 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:36.940]  So the question was, if we have all this legacy stuff that's very susceptible,
[48:36.940 --> 48:39.140]  and, you know, minimum traffic carrying capacity,
[48:39.140 --> 48:43.000]  what if somebody has some malware that gets on a major platform,
[48:43.000 --> 48:45.060]  and then starts calling 911 repeatedly?
[48:45.400 --> 48:47.700]  What I will do is point you to the DEF CON media server,
[48:47.700 --> 48:52.540]  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:23.450]  Yes, yes, that is exactly the look you should have when I say they're still using MF and Cama,
[49:23.450 --> 49:25.450]  but they are. 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:36.450]  We'll still have to have SS7 interfaces for carrier networks that hang around,
[49:36.450 --> 49:40.610]  because signaling system 7 is going to be with us for some period of time.
[49:40.610 --> 49:43.410]  But next generation 911 is designed to start getting rid of that,
[49:43.410 --> 49:45.230]  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.