WEBVTT 00:05.020 --> 00:06.100 Hey, everyone. 00:06.100 --> 00:10.480 If you're anything like me, your missed calls list looks a lot like this. 00:10.960 --> 00:12.760 And I know I'm not unique. 00:12.820 --> 00:17.420 You know, the average person gets about 14 unwanted calls every month. 00:17.420 --> 00:22.940 And you might notice that some of these in my call list are flagged as spam, which is somewhat useful. 00:23.180 --> 00:26.460 But what if we could actually start to verify callers? 00:26.460 --> 00:34.620 What if we weren't just flagging things as spam and potentially harmful, but actually doing the opposite and saying, hey, you can trust this call? 00:34.920 --> 00:36.900 We already do this with websites. 00:36.900 --> 00:38.520 We already do this with emails. 00:38.520 --> 00:40.960 Why can't we do this with phone numbers? 00:42.220 --> 00:45.220 The good news is the short answer is that we can. 00:45.260 --> 00:52.560 And I'm going to be telling you about this TLS-like technology that's been developed to solve the call authentication problem. 00:52.560 --> 01:01.660 It's called Shake It and Stir, and we'll be diving into the history of why this is a problem, some definitions and technical details of the spec, how the U.S. 01:01.660 --> 01:03.860 is going to enforce implementation. 01:03.860 --> 01:07.840 Unfortunately, a lot of this is specific to North America right now. 01:08.140 --> 01:16.840 But we'll also be diving into the limitations of what this technology is, one of those obviously being that it's not applicable to the rest of the globe yet. 01:17.500 --> 01:19.220 So my name is Kelly Robinson. 01:19.220 --> 01:21.720 I have been working at Twilio for about three years. 01:21.720 --> 01:25.980 Twilio offers a lot of communication services, including a lot of stuff around telephony. 01:26.000 --> 01:30.500 I actually work on Twilio's account security products for things like phone verification. 01:30.500 --> 01:39.040 But this was just something that I got really interested in in terms of what the telephony security of actually authenticating call systems was. 01:39.220 --> 01:54.920 So we have a separate team that I'm not involved with at Twilio that is working on implementing some of this stuff, but this is just some of my own research into what this is, how it works, and hopefully I can share that with you in somewhat of an introduction to what Shake and Stir is. 01:56.620 --> 02:00.400 So let's start with just talking about what telephony security even means. 02:00.400 --> 02:08.000 Telephony security is in quotes there very obviously because basically there wasn't a lot of security when telephony got started. 02:08.000 --> 02:14.680 There was a monopoly of companies, and even as recent as 30 years ago, the network basically looked like this. 02:14.680 --> 02:23.100 It was private, it was closed, there was proprietary technology everywhere, there were just a couple of companies, and they all basically knew how to trust each other. 02:23.100 --> 02:28.420 They all knew who they were dealing with, and they all had direct lines of communication with one another. 02:28.940 --> 02:32.980 And if you compare that to today, there's literally thousands of companies. 02:32.980 --> 02:35.840 It's really easy to access this technology. 02:36.040 --> 02:49.220 There's more standard technology now built on top of IP, so you don't have to have this kind of proprietary technology and a lot of infrastructure to get started, and there's all these potential paths and routes for a call to take. 02:49.280 --> 02:54.820 And you can think of the difference in accessing the telephony network like you would in deploying a website today. 02:54.820 --> 03:05.840 So this is the difference between having your own on-prem hardware, your own servers that you're running, versus today you can use something like AWS to get up and running very quickly. 03:07.280 --> 03:12.840 And before we dive into this a little bit further, I do want to give a little bit more context on some telephony jargon. 03:12.840 --> 03:18.380 If you aren't familiar with telephony, I wasn't before I started working at a telephony company. 03:18.380 --> 03:20.160 And starting with the PSTN. 03:20.160 --> 03:28.100 So this is the analog and digital systems like cellular networks, undersea fiber optic cables, and copper telephone lines. 03:28.100 --> 03:31.660 And this is what allows people across the globe to complete voice calls. 03:32.160 --> 03:36.280 Something that you might have heard of before is VoIP, and this is the voice over internet protocol. 03:36.280 --> 03:41.240 This is what a lot of mobile infrastructure and businesses are actually using now. 03:41.520 --> 03:43.440 And so this is what people are moving towards. 03:43.440 --> 03:51.260 This is kind of the standard technology that people have more access to now, but it can also interact with the PSTN. 03:51.880 --> 03:57.380 And then finally SIP is a way to initiate IP phone calls and other communications. 03:57.380 --> 04:01.140 You can kind of think of it like an HTTP request for phone calls. 04:01.140 --> 04:09.380 It contains metadata and instructions about where a call is both coming from, who it's going to, and some other data about what the call should be. 04:09.540 --> 04:16.800 And the important thing to note here is that shaken and stir will only apply to SIP initiated phone calls. 04:18.040 --> 04:20.160 And so let's kind of talk about what the problem is here. 04:20.160 --> 04:25.360 And I specifically frame this as unwanted robocalls because not all robocalls are bad. 04:25.360 --> 04:33.220 So you can think of things like prescription pickup notifications, food delivery services, you know, things like the school has a snow delay type thing. 04:33.220 --> 04:40.140 There's reasons to automatically dial, but we do know that most of the robocalls that we get aren't that. 04:40.140 --> 04:41.480 They're spam and that's bad. 04:41.480 --> 04:46.360 And so we wanted to focus on the greater problem of the unwanted robocalls here. 04:46.640 --> 04:52.060 And the reason this is a problem, it's gotten super common in the last five to ten years for a few main reasons. 04:52.060 --> 04:54.160 First, there's a lot of cheap dialers now. 04:54.160 --> 05:03.700 It's really easy to do this automated dialing in an efficient way that actually makes spam and fraud more both efficient but also profitable. 05:04.000 --> 05:07.260 And second, there's over 4,000 service providers in the U.S. 05:07.260 --> 05:14.200 alone and that makes it easier to access and also gives you more access options to access the PSTN. 05:14.320 --> 05:19.300 And third, there's no validation or authentication on who is placing a call. 05:19.380 --> 05:22.960 So you can basically set the from number to whatever you want. 05:23.120 --> 05:27.140 And so there's an app that I downloaded at iOS that just lets you spoof phone numbers. 05:27.180 --> 05:29.720 And you don't really even have to know how SIP works. 05:29.720 --> 05:34.940 Like there's a way that you can do this with some SIP knowledge that's even more cheap. 05:34.940 --> 05:43.400 But there's like these consumer applications that you can download if you're an iOS or Android user that, you know, you don't have to have any technical know-how. 05:43.400 --> 05:48.780 And you can just have to believe me that this is a call I placed to myself from 867-5309. 05:50.320 --> 05:53.660 So you might be asking, like, why isn't this just illegal, right? 05:53.660 --> 05:59.160 And the main reason is that because there are some legitimate use cases for spoofing phone numbers. 05:59.160 --> 06:07.960 So nowadays the practice for companies like Uber or DoorDash or something like that, they'll proxy phone calls through a third number that connects individuals. 06:07.960 --> 06:15.620 So like when you call your Uber driver, when your DoorDash delivery person calls you, you're not getting a phone call from their number. 06:15.620 --> 06:20.500 You're getting a phone call from a third party, a number that's being proxied in between you. 06:20.500 --> 06:24.600 And that, you know, has privacy use cases and also some cost-saving measures . 06:24.600 --> 06:26.740 But it wasn't always like that, right? 06:26.740 --> 06:39.420 And so you also had enterprise systems or private branch exchanges that might be placing a call to a customer from an individual agent's line, but they want to display something like the toll-free callback number. 06:39.500 --> 06:41.440 And historically, those were just spoofed. 06:41.440 --> 06:43.640 You would say, hey, this isn't coming from me, Kelly. 06:43.640 --> 06:46.300 This is coming from my organization. 06:46.580 --> 06:51.180 And I want to make sure that you see this phone number in case you need to call that back. 06:51.180 --> 06:52.760 And these systems still exist. 06:52.760 --> 06:55.380 So we can't just outlaw this completely. 06:56.280 --> 07:10.740 In fact, the New York Times actually spoofed their from number until 2011, you know, and it was one of those things to help protect their sources if journalists were calling from their desk phones that didn't want to necessarily be calling from an individual journalist's phone. 07:10.740 --> 07:14.880 But they now actually will use a 212 number that you can call back. 07:17.270 --> 07:19.930 We did introduce some legislation to address this. 07:19.930 --> 07:22.890 The 2009 Truth and Caller ID Act was what did that. 07:22.890 --> 07:27.470 So again, this is only about 10 years old that we started to really think about this as a problem. 07:27.470 --> 07:32.890 But we can't completely ban call spoofing because of the legitimate ways that businesses are still using it. 07:32.890 --> 07:38.710 So legislation specifies that it is illegal to spoof numbers if there's that intent to defraud. 07:38.710 --> 07:41.390 But there's also this enforcement struggle with this. 07:41.390 --> 07:47.570 Because the network hops, it might take five or 10 service providers before you know who actually initiated the call. 07:47.570 --> 07:54.110 And they might or might not be able to tell you about the caller because they're placing calls on behalf of many, many customers. 07:54.590 --> 07:58.430 Tracking down a spammer takes a lot of time and effort and therefore money. 07:58.450 --> 08:00.790 And that makes enforcement of this really hard. 08:01.430 --> 08:03.210 So that brings us to the solution. 08:03.210 --> 08:06.030 That brings us to Shaken and Sturr and what we're here to do. 08:06.390 --> 08:09.970 Shaken and Sturr are the most egregious of backronym crimes. 08:10.390 --> 08:15.730 So Shaken is the signature-based handling of asserted information using tokens. 08:16.450 --> 08:20.250 Sturr, again, is secure telephony identity revisited. 08:20.350 --> 08:21.390 It does get worse. 08:21.390 --> 08:28.550 There's a proposal out there for Lemon Twist, but we're not even going to look at that because I think people are just getting a little too creative. 08:28.610 --> 08:42.730 But basically as the FCC describe it, what Shaken and Sturr does, calls would have their caller ID signed as legitimate by the originating carriers and then validated by the terminating carriers before reaching consumers. 08:42.990 --> 08:47.090 And so this is where it comes into that TLS-like authentication. 08:47.150 --> 08:58.770 You are signing calls as legitimate and then the terminating service provider would then display some information to the end user signifying that calls can be trusted and they were not spoofed. 08:58.770 --> 09:00.810 And we're not reinventing the wheel here. 09:00.810 --> 09:08.190 We're borrowing from other web authentication, things like public key infrastructure, certificates, JSON web tokens are all being used for this. 09:08.190 --> 09:14.470 And it's very similar to emails DKIM and DMARC, which basically authenticates the from sender in an email. 09:14.850 --> 09:27.130 And so a lot of the work that was done on Shaken and Sturr was done in conjunction with some of the authors from DKIM and DMARC as a way to set best practices for this type of communication. 09:28.190 --> 09:34.150 And this is a simplified view of the end-to-end system, what happens with the Shaken and Sturr signed calls. 09:34.150 --> 09:42.710 So the signing service includes some public key infrastructure key management and it will be up to the originating service provider to do the key management there. 09:42.710 --> 09:45.250 And so calls are routed in a few ways. 09:45.250 --> 09:54.250 So basically between the originating service provider and the terminating service provider, you might remember from that early slide that there's like all these kind of routes that a call can take. 09:54.410 --> 09:59.630 And the way that that happens is there's something called the LNP or local number portability. 09:59.670 --> 10:11.870 And this is what people are using to both track whether numbers have been ported between carriers, but it also works as kind of a DNS like lookup to look up phone numbers so that you can then route calls to the right service provider. 10:11.890 --> 10:17.110 And usually the originating service provider, it's up to them to basically do this routing. 10:17.430 --> 10:21.050 The onus is on them to decide on the route that a call is going to take. 10:21.050 --> 10:24.170 They're usually using something called least cost routing. 10:24.610 --> 10:27.570 Twilio uses like an inter-exchange carrier. 10:27.710 --> 10:30.650 There's vendors that allow you to do this to route calls. 10:30.790 --> 10:38.270 I don't want to get into that too much, but basically when it is being passed through the other service providers in the middle there, it is just being passed through. 10:38.270 --> 10:40.690 There's not additional validation in the middle there. 10:40.690 --> 10:42.810 They're just passing the call through. 10:43.630 --> 10:50.170 And then on the other side of things, the terminating service providers then has their own verification service. 10:50.250 --> 11:03.390 And the verification service is what contacts the certificate authority and uses the certificate authority's authority there to then verify whether or not the call that came into them is a valid signed call. 11:03.390 --> 11:06.650 And so certificate authorities are being chosen by ADIS. 11:06.650 --> 11:10.410 That's the Alliance for Telecommunications Industry Solutions. 11:10.550 --> 11:13.310 And so this is a standards body that authored Shaken. 11:13.550 --> 11:18.630 So some of the certificate authorities that have been chosen are people like Newstar and Transnexus. 11:18.650 --> 11:21.910 I think there's a few others that haven't been publicly announced yet. 11:21.910 --> 11:27.330 And these are similar to the certificate authorities that administer TLS certificates like Let's Encrypt. 11:27.490 --> 11:31.670 And so then when a call reaches a terminating service provider, it's up to the client. 11:31.670 --> 11:37.770 So this would be somebody like Apple or Google to decide how to display that the calls are trusted. 11:37.770 --> 11:41.830 And so this could be something like, hey, I've got a checkmark next to this call. 11:41.830 --> 11:47.130 We display something like you saw on an early slide there that says there's a verified caller here. 11:47.130 --> 11:53.830 You could do something like a lock that we have in browsers with TLS, HTTPS sites. 11:53.830 --> 11:55.190 So there's different options here. 11:55.190 --> 12:01.410 And that has not been standardized in terms of how to signify this to consumers that these calls are not spoofed. 12:01.410 --> 12:16.170 And so I think that's going to be one of the interesting challenges that we see as this gets rolled out more is how do we build this trust on the consumer end of things and display this to them in a consistent way so that they know what to expect. 12:17.170 --> 12:21.450 So let's get into a little bit of the weeds of how this actually works from the technical perspective. 12:21.490 --> 12:24.070 So this is what a SIP header looks like currently. 12:24.210 --> 12:26.710 You can see the metadata included there. 12:26.730 --> 12:32.930 Just a reminder, SIP is the way to initiate VoIP calls or a way to initiate VoIP calls. 12:33.030 --> 12:34.610 But note the from here. 12:34.610 --> 12:38.090 So the problem here, Ray, is that the from number can be spoofed. 12:38.090 --> 12:44.750 And that happens if either the originating service provider allows it, isn't doing any validation on that. 12:44.770 --> 12:46.910 There might be those legitimate reasons for that. 12:46.910 --> 12:52.570 But they basically want to make sure that... and a lot of legitimate service providers are already doing this validation. 12:52.570 --> 12:56.190 They're not letting you place calls from numbers that you don't have access to. 12:56.190 --> 13:00.190 But there's... like I mentioned, there's over 4,000 service providers in the U.S. 13:00.190 --> 13:00.950 alone. 13:00.950 --> 13:04.710 A lot of the long-tail service providers might not be doing this validation. 13:05.770 --> 13:09.090 And so what Shaken does is it introduces a new identity header. 13:09.090 --> 13:12.890 And this is in the form of a base64 encoded JSON web token. 13:12.950 --> 13:17.210 And I'm going to focus on just some of the information that's encoded in the middle section here. 13:17.270 --> 13:23.410 And so the information that's encoded there includes things like the attestation level. 13:23.570 --> 13:25.250 And so this is in the header. 13:25.350 --> 13:29.150 And we'll talk more about what the attestation level is on the next slide. 13:29.190 --> 13:33.110 But this is basically the crux of whether or not we trust this call. 13:33.110 --> 13:38.490 But it also includes some additional metadata, like who the call is going to, who placed the call. 13:38.490 --> 13:42.490 And then importantly, the origination ID. 13:42.610 --> 13:46.910 This is for the originating service provider's underlying customer. 13:47.230 --> 13:50.150 And so this is set by the originating service provider. 13:50.150 --> 14:00.850 And so the originating service provider, the OSP there, is really putting their reputation on the line saying, hey, this is my customer that is placing this call and I'm giving them this level of attestation. 14:00.850 --> 14:10.010 And this is important because this ID makes it near instant to identify bad actors because you can trace back the call to the underlying customer. 14:10.010 --> 14:14.530 And this is what's going to allow us to enforce the Truth in Caller ID Act. 14:14.910 --> 14:29.090 And so not only does Shaken allow you to build trust in calls that aren't spoofed, but it also allows a lot of the enforcement side of things to make sure that we can track down bad actors more quickly and more efficiently. 14:29.930 --> 14:36.590 And so back to the attestation levels, there are three levels that can be attributed to a caller. 14:36.590 --> 14:42.210 And so the originating service provider is going to decide what the attestation level is here. 14:42.210 --> 14:44.830 So A is the highest level of attestation, of course. 14:44.830 --> 14:51.010 And so this is saying, I know who this customer is and I know they can use this number that they are calling from. 14:51.010 --> 14:55.970 And so that is what you would assume most of the legitimate business calls being placed are. 14:56.610 --> 15:10.650 Attestation levels B and C have some less level of trust in the call, but this is still likely to be a less fraudulent call if it's signed with any of these attestation levels than if it wasn't signed at all. 15:10.910 --> 15:26.670 And so generally, I think what, and this is where we don't have a lot of standardization around this yet, but the clients, so the Googles, the Apples, are going to have to decide in conjunction with the carriers, the Verizons, the T-Mobiles, these types of people, 15:26.670 --> 15:28.390 how to display trust. 15:28.390 --> 15:36.090 And likely what's going to happen is that they're only going to display a checkmark or a verified caller if there is that attestation level A. 15:38.330 --> 15:43.730 So new technology is really great, but we need to make sure that people are actually implementing this. 15:43.730 --> 15:54.430 And so one of the things that is good about this is it puts the onus on businesses to do the implementation and not as much on the consumers to increase consumer protections. 15:54.430 --> 15:59.930 But the main way that we're going to ensure that businesses implement this is with the TRACED Act. 15:59.930 --> 16:04.030 And so this is the Telephone Robocall Abuse Criminal Enforcement Deterrence Act. 16:04.030 --> 16:10.550 It was passed by the Senate last May, passed by the House and signed into law in December of 2019. 16:10.550 --> 16:14.330 So I think it was like December 30th of 2019, it was signed into law. 16:14.370 --> 16:19.190 And what it did is gave a timeline that started at that point. 16:19.190 --> 16:28.790 So basically, you can think of the beginning of this year, it gives telecom companies 18 months to implement shaken and stir. 16:28.790 --> 16:33.430 And so you can think mid-2021 is kind of when the deadline for this is. 16:33.430 --> 16:44.370 A lot of bigger companies have been working on this for a while, but it's still going to start to enforce the deadline in mid-2021, assuming that everything goes as planned. 16:44.570 --> 16:48.110 So it also allows for a $10,000 fine for offenders. 16:48.110 --> 16:57.370 And so this does also add an additional fine on top of the existing Truth in Color ID Act. 16:58.170 --> 17:02.430 So the authentication requirements for the TRACED Act depend on the type of call. 17:02.430 --> 17:07.410 So if it's VOIP, the requirements there is that you have to implement shaken and stir. 17:07.450 --> 17:11.810 But they do acknowledge that there isn't really a good solution for non-VOIP calls yet. 17:11.810 --> 17:15.170 And there are a lot of non-VOIP calls that are on the PSTN. 17:15.490 --> 17:20.030 And so NuSTAR has a solution called Stir Out of Ban for non-VOIP authentication. 17:20.530 --> 17:27.630 If you are a company that is placing non-VOIP calls, there's things that you can look into here for you or your customers. 17:27.830 --> 17:35.050 But definitely, I think that's one of the challenges to getting this implemented, is not everything is just going to be able to implement shaken and stir. 17:36.190 --> 17:40.990 And that's kind of what I wanted to get into now, which is what are the limitations of this technology? 17:41.710 --> 17:50.010 First being, you know, according to my curmudgeonly coworker, Randy, who's been working in telecom for many, many years, the phone network is kind of an ungodly beast. 17:50.010 --> 17:57.330 And so it's, you know, a collection of wires that has been rapidly expanding for over 100 years. 17:57.330 --> 18:03.410 And so there is this kind of situation that we've run into where there isn't a standard technology that's being used for all the calls. 18:03.410 --> 18:07.970 And so we can't just flip the switch and change everything over to be suddenly authenticated. 18:07.970 --> 18:13.810 And part of that ungodly beast is this thing called time division multiplexing, or TDM. 18:13.810 --> 18:15.730 This is essentially the opposite of VOIP. 18:15.730 --> 18:18.370 It's old school hardware that's been around for 50 years. 18:18.370 --> 18:21.890 It's baked into a lot of enterprise private networks. 18:22.070 --> 18:28.690 And the TRACED Act explicitly acknowledges TDM as a potential burden to implementing shake and stir. 18:28.690 --> 18:38.330 So they said that the burdens are barriers to the implementation, including for providers of voice service to the extent the networks of such providers use time division multiplexing. 18:38.330 --> 18:41.170 Fancy language in the bill that basically says, we get it. 18:41.170 --> 18:44.050 This might be hard for people that aren't using VOIP. 18:44.850 --> 18:49.210 And then another challenge that we have is that there just is this long tail of service providers. 18:49.210 --> 18:55.990 Like this is something that companies like Twilio and Verizon, Comcast, other large companies have been working on for months. 18:55.990 --> 19:01.410 What happens when you're a smaller scale service provider that's running limited infrastructure? 19:01.410 --> 19:07.590 You might have different access points to the PSTN that aren't going to be VOIP, like I said. 19:07.590 --> 19:10.630 And so of the 4,000 service providers in the U.S. 19:10.630 --> 19:16.250 alone, I don't know what percentage of those is going to be compliant by mid-2021. 19:16.630 --> 19:23.930 So the requirements to comply with this law, it does require significant investment. 19:23.930 --> 19:28.890 And I don't know if we can reasonably expect that everybody will be able to make that investment in time. 19:29.870 --> 19:31.870 And then there's all these other problems. 19:31.870 --> 19:34.490 The biggest problem is in the U.S. 19:34.490 --> 19:35.130 right now. 19:35.130 --> 19:38.330 But this is also a problem in places like UK and Norway. 19:38.530 --> 19:42.910 And I haven't really heard of any initiatives outside of North America to address this. 19:42.910 --> 19:47.550 There are starting to be some initiatives to implement this in Canada. 19:47.990 --> 19:53.450 But maybe this is something that if your country has a solution for this, reach out. 19:53.450 --> 19:56.510 I'd love to hear about what you're doing for enforcement there. 19:56.510 --> 20:03.810 But there's other things that we have to think about, like what about ported numbers, the international side, like I mentioned, and also text messages. 20:03.810 --> 20:07.910 There's other communication channels that don't have the same type of authentication. 20:10.570 --> 20:18.890 So the FCC's number one complaint right now is robocalls, but the government is obviously a little distracted with other global pandemics right now. 20:19.010 --> 20:26.390 But I think in terms of that department, this is something that they have a priority and a motivation to fix. 20:26.430 --> 20:36.110 And so like I said, the timeline for enforcement here is that towards the end of 2020 or into 2021, we'll start to see more people start to implement this. 20:36.110 --> 20:43.550 And you might start to see calls coming through already on your phone that might have a checkmark or might have an indication that they're being signed. 20:44.310 --> 20:49.310 So what can you do in terms of implementing shake and stir for your business? 20:49.310 --> 20:52.930 Talk to your service provider, whoever is doing your telephony. 20:53.250 --> 20:57.210 Most businesses probably won't have to do much in terms of implementation. 20:57.210 --> 21:00.250 A lot of the onus is going to be on the service providers themselves. 21:00.290 --> 21:06.750 You might have to go through with some additional verifications and like KYC, know your customer type stuff with your service provider. 21:06.870 --> 21:16.470 So at Twilio, we'll need you to create a business profile that has some additional details about your account before we would give you and start signing your calls with the highest attestation. 21:19.220 --> 21:24.040 And then there's some precautions that you can take as just application security professionals. 21:24.160 --> 21:27.700 So you can protect your numbers from web scraping bots. 21:27.700 --> 21:30.440 Don't assign sequential numbers to your employees. 21:30.440 --> 21:37.140 That's a way that people can kind of guess which employees might have lines at your company. 21:37.420 --> 21:40.420 And then you can use actual authentication in your call centers. 21:40.420 --> 21:44.680 This is another way that you can protect your business from phishing. 21:44.880 --> 21:49.080 This is something that I could talk about for many, basically. 21:49.080 --> 21:54.620 We'll only ask for a consumer, you know, date of birth and email in order to verify the customer. 21:54.760 --> 21:59.420 And so there's a lot of other things you can do to actually authenticate people on either end of the call. 21:59.700 --> 22:06.860 And then if you know what a PBX is and you have one, you might look into installing the FCC blacklist database on that. 22:07.400 --> 22:10.240 Some controversy around whether or not you want to do that. 22:10.240 --> 22:13.180 It's hard to get off the blacklist database if you're on there. 22:13.480 --> 22:16.720 But this is something that you may or may not have to worry about. 22:17.660 --> 22:19.880 And then there is some ongoing legislation. 22:20.060 --> 22:22.800 But things have been pretty quiet from the FCC this year. 22:22.800 --> 22:31.360 They did recently, somewhat recently, like in the last year, give telcos the authority to block unwanted calls without explicit subscriber permission. 22:31.360 --> 22:44.060 And so, you know, AT&T, Verizon, T-Mobile in the U.S., they can now decide, hey, we're going to send this to basically like a spam folder without ever notifying you that the call came in and I don't need you, Kelly, to tell me that that's okay. 22:45.000 --> 22:50.400 And then like I mentioned, in terms of timeline for the Trace Stack, the enforcement will start to begin at the end of 2020. 22:51.260 --> 22:55.400 Last update from the FCC on this was March 31st. 22:55.400 --> 23:05.400 And this reaffirmed their call to implement Shaken and Stir, but it did already grant an exception for and an extension for small voice service providers. 23:05.400 --> 23:07.100 And I don't know what that means. 23:07.100 --> 23:16.960 I don't know exactly how they're going to decide who is a small voice service provider, but they are already thinking about, you know, this was three months after the bill was signed into law. 23:17.100 --> 23:20.540 They're already saying, hey, maybe this timeline isn't reasonable. 23:20.540 --> 23:38.020 So while I do think that a lot of larger telecom providers will start to sign calls within the end of this year, I do think that there is going to be an exception for that long tail of service providers and not everything is going to be a signed call before, 23:38.020 --> 23:40.040 you know, the end of 2021. 23:41.360 --> 23:45.540 There are a couple of things you can do as a consumer to protect yourself today. 23:46.040 --> 23:49.520 You can install one of these apps depending on how much you trust them. 23:49.520 --> 23:54.920 A lot of times you have to give them basically complete control over your phone, so your mileage may vary there. 23:54.920 --> 24:05.640 But things like NovoRobo, RoboKiller, CallApp, you know, companies like AT&T have a partnership with a company called Haya that does, you know, some protection against spam calls. 24:06.120 --> 24:16.600 Of course, a lot of consumer telecoms are starting to upsell spam detection services, so Verizon offers their CallFilter Plus for the low, low price of $3 a month. 24:16.600 --> 24:22.920 But, you know, these are things that you can look into installing on your phone if this is something that is a huge annoyance to you right now. 24:24.000 --> 24:38.320 So like I said, unfortunately, I don't think this is going to solve all problems right away, but I think people are really optimistic that Shaken and Stare will help restore trust in telephony, because not only is it going to help, you know, mitigate spam calls that are coming into your phone, 24:38.320 --> 24:49.080 but for those wanted calls for, you know, the calls that you want to see that might be from unknown numbers, there's going to be a renewed trust in some of those phone calls. 24:49.080 --> 24:54.780 And so there is that motivation from businesses to restore that type of trust so that people will answer the calls. 24:55.620 --> 25:00.520 Hopefully this is a good overview in terms of what you can expect from Shaken and Stare. 25:00.520 --> 25:02.740 If you have any questions, you can find me on Twitter. 25:02.740 --> 25:04.060 I'm also on Discord. 25:04.160 --> 25:07.780 Once again, my name is Kelly Robinson, and thank you for listening. 25:13.380 --> 25:15.380 All right, welcome back everybody. 25:15.380 --> 25:18.560 That was What If We Had TLS for Phone Numbers? 25:18.560 --> 25:21.700 An Introduction to Shaken and Stare by Kelly Robinson. 25:21.980 --> 25:25.120 We actually have Kelly with us here right now. 25:25.140 --> 25:33.240 If you have any questions, drop them in our Discord Q&A channel down linked in the description below. 25:34.760 --> 25:37.060 We've got some questions here. 25:38.320 --> 25:39.900 Hi Kelly, great talk. 25:39.900 --> 25:40.560 Thank you. 25:40.560 --> 25:46.440 Question, working hard to get Scandinavian governments and telcos to have an opinion on Shaken and Stare. 25:46.440 --> 25:58.020 A part of the feedback I've gotten is that unless all carriers all over the world implement this, and they all promise not to allow governments to mess with it for spooking purposes, it really won't work. 25:58.020 --> 26:05.920 I don't know it well enough yet to either accept that as an answer or tell them they're wrong, but at least I hope and I think that it will assist in reducing the problem. 26:05.940 --> 26:12.620 What's your take on this and do you have any solid arguments I can use in order to speed up their process of considering this? 26:13.500 --> 26:30.000 Yeah, so one of the things that we hear a lot from customers, and so like as somebody that like works at an originating service provider, this is something that our customers are actually like interested in us implementing, specifically because of like not the like consumer, 26:30.000 --> 26:33.220 like I'm sick of receiving spam calls side of things. 26:33.460 --> 26:38.880 I don't know like what the, you know, Scandinavian countries, like how many complaints you're getting about this. 26:38.880 --> 26:44.720 The reason like the FCC is motivated to do this is because they just get a lot of complaints about robocalling. 26:45.200 --> 26:55.040 But on the flip side of that, from the company side of things, there's a lot of motivation there to be like, hey, I want my customers to actually answer the calls that I'm like sending them. 26:55.040 --> 27:04.500 And so if we reduce calls for that are spam calls, then we might be able to get calls to get answered. 27:04.500 --> 27:12.520 And so there is that like, in America, capitalist, you know, type of motivation there to say, hey, this might actually be good for businesses. 27:12.540 --> 27:15.440 And so there's been like some lobbying on that side of it, too. 27:15.440 --> 27:28.460 So if there's like, a big reason for companies that you know, in the countries that you operate to do this, like, there obviously are going to be some of those network effects of like, hey, until everybody does this, it's not going to be a perfect solution. 27:28.460 --> 27:30.620 But I agree with you, I think it's going to help. 27:30.620 --> 27:47.540 And I think it might help with like , the, you know, we might get to a point where the terminating service providers decide, hey , like, I'm not going to like allow calls through, or maybe we'll have a point where the consumers get to say, hey, I'm only going to let you like ring calls through to my phone. 27:47.760 --> 27:52.320 If it has that like a level attestation, we might see this. 27:52.320 --> 27:54.340 And this is where like, we don't really know yet, right? 27:54.340 --> 28:09.060 Like, we might or couldn't see this get to the point where you have more fine grained control as a consumer, almost like you do on your email inbox of saying, like, maybe I have like a phone spam folder that I need to like, don't like look at unless I specifically go check the missed calls in that like, 28:09.060 --> 28:13.020 unsigned folder, like things that aren't signed by shaken. 28:14.640 --> 28:16.400 Yeah, very interesting. 28:16.400 --> 28:19.820 The next question is along those same lines. 28:19.820 --> 28:25.440 Biggest question for me is how do we solve the robocall scam problem globally? 28:25.700 --> 28:31.260 Privacy laws and even new tech that's only implemented in one country isn't going to do anything. 28:31.360 --> 28:37.420 Do you think maybe calls might be blocked from outside of the country if they're not signed? 28:37.880 --> 28:38.800 Yeah, I don't know. 28:38.800 --> 28:41.320 I mean, I think that's going to be one of those things. 28:41.320 --> 28:45.800 Like, I don't think right now there's going to be a ton of that happening. 28:45.880 --> 28:54.720 You know, obviously, my viewpoint on this is pretty US centric, since I, you know, I live in the US and have done the majority of research on this problem in the US. 28:55.060 --> 29:05.000 And this is something that I'm just like, not as familiar about, like, in the US, it's something where the majority of the calls that I get, the vast majority of the calls I get are from other US numbers. 29:05.000 --> 29:14.900 I know, obviously, that's not as true in other parts of the country where like, or other parts of the globe where there's like more countries that you would be receiving more calls from other like country codes. 29:14.900 --> 29:22.760 So yeah, I don't I don't think we're going to get to a point where like, it's just straight up blocking things because they're from another country. 29:22.760 --> 29:36.900 But you know, that might be something where things like I said, could flip to say, like the consumer can decide, hey, I want to, you know, allow these types of calls or, you know, maybe this is something that like carriers will come to an agreement with, 29:36.900 --> 29:44.420 like, there's already a lot of agreements between carriers as they switch calls between different networks to get them to other countries. 29:44.420 --> 29:53.000 Like, you know, that's all part of the PSTN that you have to have that those switches kind of in place to talk to other carriers and other parts of the globe. 29:53.000 --> 29:58.080 So yeah, there's just there, it's unfortunate, but there is just a lot that's unknown about how this is going to play out. 29:58.080 --> 29:59.300 But good question. 30:00.340 --> 30:01.820 Yeah, thank you. 30:02.140 --> 30:08.580 And then let's see, we've got another I was curious, who enforces fines under the TRACED Act? 30:08.600 --> 30:11.020 Do I need to take the spammer to court myself? 30:11.020 --> 30:13.000 Or will the government do that for me? 30:13.600 --> 30:14.880 That's a good question. 30:14.880 --> 30:17.500 I don't fully know the answer to that. 30:17.500 --> 30:20.880 But it might be something that the FCC would be involved in. 30:20.880 --> 30:27.420 And that's as much as I will speculate on that until I know more for sure. 30:29.500 --> 30:30.540 Cool. 30:30.880 --> 30:34.120 Well, there's some more questions here. 30:34.880 --> 30:36.220 Yeah, all right. 30:36.220 --> 30:39.700 What are potential attack vectors to protect against? 30:39.760 --> 30:46.840 Example for TLS and attack vectors getting a bad root certificate or bad root CA certificate in your trust store? 30:46.840 --> 30:48.600 Is there a similar problem? 30:49.980 --> 30:53.800 This is another one that I haven't thought too much about yet. 30:53.800 --> 31:00.420 But I'll definitely take that back to the team that's implementing this at Twilio and see if they have any thoughts about that. 31:00.420 --> 31:03.140 And maybe issue a follow up to you. 31:03.800 --> 31:04.940 Yeah, that's interesting. 31:04.940 --> 31:07.640 So depend on how it's implemented. 31:08.620 --> 31:23.900 Yeah, I know there was actually somebody that talked about this last year at the crypto privacy village in terms of like, and they focused on like a lot of the like the actual like the originating service provider has to set up like their own PKI and stuff around it. 31:23.900 --> 31:25.600 And they were like, that can be really hard. 31:25.600 --> 31:29.880 But that person was also like a PKI vendor of like, I can help you with this. 31:29.880 --> 31:33.240 So I'm not sure how hard that part actually is. 31:34.740 --> 31:35.560 All right. 31:35.560 --> 31:37.900 Well, thank you for joining us today. 31:37.900 --> 31:43.660 If anybody has any more questions, direct them to the Discord Q&A channel. 31:43.900 --> 31:46.880 And Kelly is there and she might be able to answer some of your questions. 31:46.880 --> 31:48.320 Thanks, everyone for joining us. 31:50.500 --> 31:51.960 And next up on the screen.